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