After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615804 - randr plugin auto-configs on randr event instead of restoring save config
randr plugin auto-configs on randr event instead of restoring save config
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: plugins
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks: randr-tracker
 
 
Reported: 2010-04-15 02:03 UTC by Gabriel Burt
Modified: 2010-09-08 16:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (2.40 KB, patch)
2010-05-12 01:28 UTC, Gabriel Burt
none Details | Review

Description Gabriel Burt 2010-04-15 02:03:14 UTC
In gsd-xrandr-manager.c in on_randr_event, it calls auto_configure_outputs instead of trying to load the user's saved configuration.  This code path is triggered when you plug in an external monitor and run `xrandr`, run 'Configure Display Settings', or click 'Detect Monitors' from the display-settings dialog.

There is a rationale for this in the code, but I believe it's wrong.  Here it is:

/* WHY THIS CODE IS DISABLED:
                 *
                 * The strategy of "on hotplug or unsuspend, restore a
                 * known-good configuration, and fall back to autoconfiguration"
                 * works fine as long as you don't happen to be running
                 * gnome-display-properties and click its "Detect displays"
                 * button.
                 *
                 * If you do that, the RANDR calls from g-d-p will cause the X
                 * server to re-probe the RANDR outputs.  The server will send
                 * us an event, we'll restore the configuration to something
                 * else... and you'll be weirded out, because "just detecting
                 * your monitors" should not change the current configuration,
                 * right?

I think this is wrong.  As it stands, the user's display configuration changes anyway, just to the 'auto' setting, instead of the one they might have saved.
Comment 1 Federico Mena Quintero 2010-04-30 18:58:17 UTC
The reasoning is that (at least for now) it's better to turn on everything that we can and turn off everything that doesn't make sense.  If we restore a configuration blindly, the monitor that has the gnome-display-properties window may end up off (if that is what was saved), and you'll have to find that window in another monitor.

That's not *too* bad, but it certainly felt jarring when I tried it.

I think the right way to avoid this abrupt transition is to have g-d-p fade out everything to black, *then* do the switch to the saved configuration, *then* fade back in to normal.  We should do that whenever we change video modes or display configurations.

Other modules have code to do the fadeout/fadein thing - would you have time to pull out this code and put it in the RANDR plugin?  Then we can totally make it use the saved configuration when it gets a RANDR event (as when you click on Detect Displays).
Comment 2 Gabriel Burt 2010-05-12 01:28:17 UTC
Created attachment 160884 [details] [review]
patch

This patch tries to restore the config on randr event, falling back to auto-configing if there is no suitable saved config.  It fixes a bug in the commented out code.  I didn't have time to add the fading in yet.
Comment 3 Federico Mena Quintero 2010-09-08 16:31:01 UTC
I just pushed this to gnome-2-32 and master.  Sorry that it took so long to merge it in!