Conceptual changes to KScreen

[Nate Graham]

[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
>