Re: Conceptual changes to KScreen
On Sun, 25 Nov 2018 04:47:39 -0700 Roman Gilg wrote > From a user-facing standpoint there is not much change. Certain > display property a user manipulates manually via the KCM are now per > default persistent over all possible configurations of displays (i.e. > which displays are connected) he might change to in the future. > > It is assumed this is what most users want for following (per-)display > properties: > * resolution > * scale factor > * rotation > * refresh rate. Thanks Roman. For those properties, I can see quite a few cases where a user would want per-display configuration, most of them relating to laptops plugged into external screens or projectors. Those external screens will typically differ in their resolution, optimal scale factor, and refresh rate from both the laptop screen as well as other external screens that the laptops could use. How would this proposal handle those cases, or are they unaffected or even improved? Or am I misunderstanding the proposal? > In certain rare scenarios user might be interested in saving > properties for one specific configuration only though. Changing the > retention value from the KCM allows that. Also this can be used as a > fallback to current behavior. It is assumed though that only very few > users if at all choose to do that. So this new feature would require users to manually mark their display configurations as needing to be remembered? Nate
Re: Conceptual changes to KScreen
On Sat, Nov 24, 2018 at 8:42 PM Nate Graham wrote: > [CCing visual-des...@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. >From a user-facing standpoint there is not much change. Certain display property a user manipulates manually via the KCM are now per default persistent over all possible configurations of displays (i.e. which displays are connected) he might change to in the future. It is assumed this is what most users want for following (per-)display properties: * resolution * scale factor * rotation * refresh rate. In certain rare scenarios user might be interested in saving properties for one specific configuration only though. Changing the retention value from the KCM allows that. Also this can be used as a fallback to current behavior. It is assumed though that only very few users if at all choose to do that. Judging by that the current design in https://phabricator.kde.org/D16997 with the two radio buttons is sub-optimal. It should be made more clear what the default behavior is and that changing that is not necessary and probably not desirable in most use cases. Another special case is when multiple displays of the same (brand+)model are connected. Choosing different properties on them (for example having one rotated and another one not) makes it necessary to decide if one of them and if so which one should override the global property values of this model. My current idea would be to just disallow influencing the global value in case more than one display of same model are connected and falling back to old / configuration specific values. But maybe there might be a better solution, for example such that exactly one of the displays of identical model type overrides the global values.
Re: Conceptual changes to KScreen
On November 24, 2018 at 12:43:00 PM, Nate Graham (n...@kde.org) wrote: > [CCing visual-des...@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 > >
Re: Conceptual changes to KScreen
[CCing visual-des...@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
Re: Conceptual changes to KScreen
On Mon, Nov 19, 2018 at 11:56 AM David Edmundson wrote: > > The concept of the global values makes sense. But I think you've over > complicated it. > > I don't think we should retroactively apply global changes to setups. > The UX is super confusing, and we have all these state problems that require > more and more code on top. > > All I think is needed is: > - we save the last user set refresh/rotation/scale to an output config file > as well as the current config file > > - kded/generator.cpp, when we get a new setup, looks for a global value and > uses that instead of automatically generating it. > That should be the only user of the global values. > > Bam, done. Unfortunately it's not that easy. Simple example: * Imagine user has active two-display setup/configuration with displays D1 and D2. * User decides to change the scale factor of D1 to two. * Now user disconnects D2. * User decides that scale factor two is too large after all and goes back to one. * One month later user reconnects D2, the scale factor of D1 suddenly changes back to the old value read from the configuration file.
Re: Conceptual changes to KScreen
On Mon, Nov 19, 2018 at 3:00 PM Christoph Feck wrote: > > On 19.11.2018 11:11, Roman Gilg wrote: > > D1 is at coordinates (0, 0) and has logical size 3840x2160. D2 is > > therefore at coordinates (3841, 0). > > Is the single-pixel gap intended, or should that read (3840, 0)? > It should be indeed (3840, 0). Thanks for point it out.
Re: Conceptual changes to KScreen
On 19.11.2018 11:11, Roman Gilg wrote: D1 is at coordinates (0, 0) and has logical size 3840x2160. D2 is therefore at coordinates (3841, 0). Is the single-pixel gap intended, or should that read (3840, 0)?
Re: Conceptual changes to KScreen
The concept of the global values makes sense. But I think you've over complicated it. I don't think we should retroactively apply global changes to setups. The UX is super confusing, and we have all these state problems that require more and more code on top. All I think is needed is: - we save the last user set refresh/rotation/scale to an output config file as well as the current config file - kded/generator.cpp, when we get a new setup, looks for a global value and uses that instead of automatically generating it. That should be the only user of the global values. Bam, done. David
