GNOME Bugzilla – Bug 635564
don't need to confirm configuration change if we can verify mode was set
Last modified: 2018-09-21 16:30:45 UTC
Currently we prompt the user to confirm every configuration change. If the confirmation is not made then the configuration reverts to the last used.
This is somewhat annoying for the normal case where things work. Not only are the settings explicit apply instead of instant apply (something I think we should move towards) it makes me click a second time to keep them.
This is not even an elegant way to handle the case where the mode was not set correctly since the user most likely cannot see or select the "Restore Previous Configuration" button (especially since it isn't the default). And worse the display will be broken for 30 seconds without the user being able to see the apology/confirmation dialog.
It sounds like theoretically we should be able to query the device to determine whether the requested mode was actually used. This should allow us to not require the confirmation in the cases where it is set correctly.
The confirmation isn't needed for arrangement because if you see the settings window now you should still see it after arrangement (modulo compositor bugs). Except when arrangement also changes resolution and that should be covered by the mode verification already.
In cases where we can't tell, we can still display a confirmation dialog but we can change the wording to make it clear that automatic detection failed for this hardware.
When we can positively detect that a mode was not set correctly we can more immediately return to the working configuration and present an appropriate message to the user.
Much better all around I think.
Thanks to Adam Jackson for suggesting this.
<mccann> so if we can do that verification we can drop the prompt I think
<ajax> we can do it sometimes, but i can tell you whether or not i can do it.
<mccann> how can I tell?
<ajax> one sec, checking the docs again
<ajax> so this is all under the ddc control interface, which is optional
<ajax> and even if you support it you might not support all possible controls
<ajax> but you do have to give a list of which controls you do support, and two of them are the display's idea of the horizontal and vertical frequency of the signal, with an out-of-band marker for "can't tell or out of range"
<ajax> there aren't really good tools for this yet
<ajax> ddccontrol kind of works but it's really a kms output property
That all sounds theoretically nice, but how do we actually implement the "it worked" in gnome-desktop?
The gnome-settings-daemon changes are trivial (return a "needs confirmation" boolean from the GnomeRR function of gnome-desktop), but how would we implement this in gnome-desktop itself?
Moving to gnome-desktop, as that's where the feature would need to be implemented.
This is rather messy right now. Originally we didn't have confirmation at all. We absolutely had to put it in, since drivers were too unreliable, monitors too mendacious, and things generally collapsed quite often.
One thing I didn't think about when putting in the confirmation code, was to *first* inform the user that there would be a grace period for confirmation, *then* do the RANDR switch and the confirmation - this would at least let the user know that something was going to happen for the next 30 seconds (... and at first we only had 10 seconds, but it was too short, because some displays or drivers were just too slow in resyncing / unblackening).
The idea then was to always do confirmation, because the only way to trigger RANDR changes was from gnome-display-properties: it saved the new configuration file, called the D-Bus method, and in turn g-s-d read the config file, made the RANDR change, and asked the user if things were OK.
I think later we added the rotation options to the tray icon from g-s-d. I don't remember why they don't save the configuration file; they just rotate things directly. Since they don't do the save-the-file-and-call-D-Bus dance, they don't go through confirmation.
Even later, we made it so that g-s-d won't try to restore your saved configuration if you hit the XF86Display hotkey, as that produces seemingly unpredictable behavior; instead, it will only restore your saved configuration during login. (You can see a problem now - save your configuration from gnome-display-properties, then rotate through the tray icon, then reboot - you'll get the unrotated configuration back.)
It would indeed be perfect to know if the configuration worked, by asking the monitors about what they are really showing right now. I don't know if we can completely trust them, however.
My laptop has a VGA output, and I normally plug an external Acer monitor to it.
The monitor happily says that it can handle it highest resolution at 60 Hz or 75 Hz (at least that is what xrandr *and* gnome-display-properties report). The 60 Hz mode indeed works fine, but if I choose 75 Hz, the monitor bounces a box that says, "mode not supported", while displaying a seemingly valid image.
And that is only if I use the laptop's display *and* the monitor simultaneously. If I tell xrandr or gnome-display-properties to *only* use the external monitor, but not the built-in LVDS, the monitor shows snow even when used at 60 Hz. I don't know if the video card is stupid, or if the driver is.
In summary, I don't know if we can trust things as much as needed to be able to remove the confirmation dialog :(
(It *has* been a while since I last got a totally unreadable image in a monitor, though.)
Just observed a few users completely confused by this confirmation dialog. At minimum, we should definitely not show this confirmation when only changing the layout of displays. We don't show this when using fn-f7 and we shouldn't show it when changing the layout from the settings panel.
Agreed. I'd like to disable the confirmation dialog, but not rip out the code entirely just yet - the code to save the known-good configuration and restore it is a bit delicate to just throw it out.
Brainstorming - is there a way we could implement this:
- user switches RANDR modes
- screen bcomes unreadable, user hits the reset button
- we detect an unclean shutdown and go back to the known-good mode
(Or it may be overkill. I haven't had unreadable screens for a long while - but I haven't tested anything outside my home hardware, either.)
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-desktop/issues/34.