Bugzilla – Bug 381139
[multiscreen]: Need to recheck configuration after coming back from suspend
Last modified: 2010-03-11 23:55:01 UTC
Before suspend; Was setup with a CRT 1024x768 to the left, Builtin 1450x1050 to the right During suspend; Unplugged CRT, plugged in LCD 1680x1050 After suspend; Out of sync on LCD as it tried to use screen resoultion/refresh from the CRT We need to recheck the monitor setup when coming back from a suspend as this would happen frequently when people move between office and home etc. Perhaps just disable xinerama if monitor have changed would do it for now.
Federico: no idea if this can be moved upstream, nor where it should be moved upstream, so I just assign it to you :-)
I think I've seen Apple do this (they rescan the outputs when the machine unsuspends). I'll take care of this (no idea how, for now) :)
Note to self: look at pm-utils for how to define unsuspend hooks.
Note to self: pm-utils may be for root only. Look for notifications from gnome-power-manager.
Note to self: look at how NetworkManager does this.
Just checking, should this work with RC5/GMC?
Not yet, sorry. Let me see if this is an easy fix which we can release as an online update. (Reassigning to openSUSE 11.1; this won't be fixed for 11.0)
Ajax thinks userspace should not need to do anything about this; instead, the X server should re-probe the monitors when it notices that it came back from suspend. However, currently "unsuspended" is indistinguishable from "switched VTs" to X, so... (01:59:36 PM) federico: ajax: do you know where in the X sources I could put the "unsuspended, now rescan!" bit? (02:00:06 PM) ajax: randr would need to wrap the EnterVT call chain (02:00:24 PM) ajax: so uh, **/xf86RandR12.c
Note to self: gsd-xrandr-manager.c has this: static void on_randr_event (GnomeRRScreen *screen, gpointer data) { GsdXrandrManager *manager = GSD_XRANDR_MANAGER (data); if (!manager->priv->running) return; /* FIXME: Set up any new screens here */ } ... which is not terribly functional :) We may be able to simply refresh the current screen configuration, and see if any of the stored configurations match that one --- if so, use the stored configuration. Alternatively, we can turn on all the connected outputs like "xrandr --auto" does. [Hmmm, we then also need to check the timestamp of the RANDR event, so that we don't loop while g-s-d *itself* is changing the RANDR configuration.]
I've filed https://bugs.freedesktop.org/show_bug.cgi?id=21554 upstream for the X server.
Created attachment 289864 [details] xorg-x11-server-bnc381139-randr-reprobe-on-unsuspend.diff Patch in progress; this is for the current xorg. I need to backport it for our version.
Created attachment 290245 [details] xorg-x11-server-bnc381139-randr-reprobe-on-unsuspend.diff This is for xorg-x11-server as shipped on openSUSE 11.1.
Created attachment 290250 [details] xorg-x11-server-bnc381139-randr-reprobe-on-unsuspend.diff Better version of the patch, with the private fields in the right place.
This was committed upstream in xserver's commit e08c6a0752772745f35f7afcf6c2b1c927b91cc0
New bug in the X server --- it does not update RANDR timestamps correctly: https://bugs.freedesktop.org/show_bug.cgi?id=21987 I am fixing that so that gnome-settings-daemon can distinguish between these two events: - "the RANDR configuration changed because of hotplug/unplug/etc" - "the RANDR configuration changed because gnome-settings-daemon itself requested the change"
Created attachment 295340 [details] xorg-x11-server-bnc381139-randr-fix-timestamps.diff Fix the management of RANDR timestamps in the X server.
Created attachment 295388 [details] gnome-desktop-bnc381139-handle-hotplug-and-unsuspend.diff Patch for gnome-desktop; adds API to fetch the RANDR timestamps and fixes the handling of RANDR events.
Created attachment 295390 [details] gnome-settings-daemon-bnc381139-handle-hotplug-and-unsuspend.diff Patch for gnome-settings-daemon. This makes it re-probe and autoconfigure the RANDR outputs. The opening comment in this bug mentions that we should handle the case where you unsuspend and have a *different* monitor. This patch doesn't handle that case yet; outputs which remain connected and activated will retain their current modeline. We may have to steal the logic from gnome_rr_config_apply_from_filename() to see when a monitor changes.
Federico - The original report/request was to allow a laptop that has both a internal display and external display (attached to a port replicator) to recover from a power save operation where the active display has changed since. In my case, I have a laptop with an internal display that works perfectly fine (power save recovery included) If booted int the port replicator the external display works fine as well (power save included) However, when I connect the laptop to the port replicator after putting it in power save outside of the port replicator and attempt to power it up to the external display, I get no video (on any of the TTYs) This is the issue I was hoping to get fixed. Thanks, Jason
(In reply to comment #20) > In my case, I have a laptop with an internal display that works perfectly fine > (power save recovery included) If booted int the port replicator the external > display works fine as well (power save included) However, when I connect the > laptop to the port replicator after putting it in power save outside of the > port replicator and attempt to power it up to the external display, I get no > video (on any of the TTYs) This *may* work with those patches, but I am not sure yet --- I don't have a port replicator to test this. I'll build test packages in my build service repository and point you to them. What I meant is that if you do this: 1. plug a monitor and make it work 2. suspend 3. unplug that monitor 4. plug another monitor with different capabilities 5. unsuspend ... that *may* leave the new monitor running with the old monitor's frequency, which could be wrong. That is, we don't detect when a monitor is switched for another one.
Created attachment 295545 [details] gnome-desktop-bnc381139-handle-hotplug-and-unsuspend.diff Updated patch that does not break the API/ABI.
Created attachment 295547 [details] gnome-settings-daemon-bnc381139-handle-hotplug-and-unsuspend.diff Updated patch that depends on the extended API.
Federico: as far as I can tell, those patches are upstream now. Do you intend to release an update for 11.1, or should we close the bug?
Update released for: gnome-desktop, gnome-desktop-debuginfo, gnome-desktop-debuginfo-32bit, gnome-desktop-debuginfo-x86, gnome-desktop-debugsource, gnome-desktop-devel, gnome-desktop-doc, gnome-desktop-lang, libgnome-desktop-2-7, libgnome-desktop-2-7-32bit, libgnome-desktop-2-7-x86 Products: SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11 (i386, x86_64) SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64) SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)
Update released for: gdm, gdm-branding-upstream, gdm-debuginfo, gdm-debugsource, gdm-lang Products: SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11 (i386, x86_64) SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)
This got merged upstream.