Conceptual changes to KScreen

[Andy Betts]

On November 24, 2018 at 12:43:00 PM, Nate Graham (nate at kde.org) wrote:
> [CCing visual-design at kde.org]
> 
> Hi Roman,
> Could you summarize for less technical people like me what the
> user-facing impact of this change would be? How would this change the
> experience of managing external screens for laptop users? Etc.
> 
> Nate
> 
> 
> 
> On 11/19/18 3:11 AM, Roman Gilg wrote:
> > Hi all,
> >
> > I've written over the last few days a patch series for KScreen, that
> > restructures part of the code, but more importantly introduces new
> > configuration concepts on a fundamental level.
> >
> > I write this mail to get some feedback on these concepts, if there are
> > aspects I overlooked when designing them, problems which might creep
> > up later.
> >
> > You can read the patch series starting at:
> > https://phabricator.kde.org/D16989
> >
> > Concepts
> > --------
> >
> > As a summary the two main new concepts are:
> > 1. Introduction of global output property files, which contain a
> > default state for display models (which are defined by their EDID
> > model). Core functionality for that is added between patches:
> > https://phabricator.kde.org/D16991
> > https://phabricator.kde.org/D16997
> > 2. Additional to the data sharing between KCM and KScreen daemon via
> > the windowing system a secondary one-way control channel is
> > introduced. This allows the KCM to share additional control
> > information with the daemon. This is mostly patch:
> > https://phabricator.kde.org/D16992
> >
> > For 1. the rationale was that a user in most cases want to change the
> > properties of a particular display model for all screen
> > setups/configurations and not only for the one currently in use. The
> > default behavior would therefore be with these patches that properties
> > are saved to the global output properties file, which gets read by
> > default for all new and existing configurations, should they get
> > activated.
> >
> > To offer some more flexibility there is a second "advanced" mode
> > allowing the user to specify configuration-specific values, which
> > won't get overridden by the global properties. In this second mode an
> > output in a certain configuration would therefore behave basically how
> > it is currently the case.
> >
> > For 2. the idea was, that there might be additional information about
> > a configuration or global output property file the KCM needs to share
> > with the daemon, but the detour through the windowing system is
> > unnecessary, because the information is not relevant for the windowing
> > system. The primary use case for such information is at the moment the
> > retention information, i.e. if the user specifies a configuration to
> > use individual output values instead of global output values.
> >
> > Other information shared through this channel in the future will be
> > presumably if the configured resolution, refresh rate and so on is the
> > result of manual user interaction or of an algorithm (i.e. "auto"
> > selected in the KCM). By this the daemon can decide to recalculate the
> > auto value on next output/configuration activation or just reapply the
> > stored fixed value. On the other side the KCM can read this
> > information to display the correct mode in its Ui.
> >
> > Challenges
> > ----------
> > I see with the current patch set three remaining issues:
> >
> > 1. Old property files of configurations get (partly) invalidated.
> > The files get moved, so old files won't get read out anymore. One
> > could write an update script, but with D17007 there is another
> > proposed patch to libkscreen, that changes the hash values of all
> > configurations with name based output hashes, i.e. afterwards these
> > configuration files are not found anyway.
> >
> > I would argue since the concept of configuration with this patch
> > series changes on a fundamental level, it is acceptable and to a
> > certain degree preferable to invalidate old configuration files. But
> > in this case the new concept must be right the first time, that's what
> > this email is for.
> >
> > 2. KCM data not yet refreshed on hot plug events.
> > While the KCM is opened, if a hot plug event occurs or if screens are
> > unified, I can't yet guarantee that the control values (i.e. at the
> > moment the retention) are updated in the Ui accordingly.
> >
> > I would like to tackle this by a larger rewrite of the KCM data logic,
> > by remembering a pending and current state and through that also
> > allowing the KCM to go back into the non-changed state when the user
> > roll-backs pending changes.
> >
> > 3. Global output properties resolution, scale, rotation influence the
> > position of screens.
> > Imagine a two screen configuration C with a 4k display D1 on the left
> > and scale factor 1 (using global properties) and some other display D2
> > on the right. D2 left top corner is aligned with D1 right top corner.
> > D1 is at coordinates (0, 0) and has logical size 3840x2160. D2 is
> > therefore at coordinates (3841, 0).
> >
> > Now user decides to change the global scale factor of D1 from 1 to 2
> > while a different configuration is active. Logical size of D1 is
> > reduced to 1920x1080 by that. Still D2 is at (3841,0) in configuration
> > C. So the next time the configuration is activated there is suddenly a
> > large gap between the screens. One can assume the user instead wanted
> > the screens to still be next to each other.
> >
> > My idea for solving this problem is compensation logic in the daemon.
> > Since the configuration file of C still features the old scale and
> > position values, the daemon can compare them with the different global
> > properties and then move the screens accordingly. Still this needs
> > some careful designing in order to deal with complex setups.
> >
> > So what are your thoughts about these proposed conceptual changes? In
> > any case thanks for reading.
> >
> > Cheers,
> > Roman
> >
> 
> 

It also seems that there will be a need for a new KCM that can control all these changes. I would love to help with that design, but I would love to get some ideas on what specific elements are needed for the KCM and I can turn them into something we can use.

Thank you,

Andy Betts 
KDE Board Member