Conceptual changes to KScreen

[Roman Gilg]

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