GNOME Bugzilla – Bug 561583
Some gtk apps don't behave properly after xrandr dual-screen modifications
Last modified: 2009-02-22 07:02:05 UTC
Please describe the problem: When adding or removing a display output with xrandr, some running gtk applications (thunderbird, for example) do not function correctly after the resolution change. Note: the situation has improved a bit lately. With firefox, for example Previously all menus would be rendered in the wrong location. Specifically, some menus would be appear shifted from their correct location (that is, if I added a screen to the left of my main display, menus would appear shifted to the left of their correct location). Then (with Ubuntu 8.10) most firefox menus would work correctly (except for some right-click menus). Now, (as of the past few weeks, running the latest xul) firefox seems to be content. Thunderbird, on the other hand, loses most functionality - it does not respond to the mouse in most cases. The menus/buttons at the top of the screen would work, but clicking anywhere else would not function. Previously, restarting the the malfunctioning application was the only way to fix the issue. Now (very recently), unmaximizing/minimizing/restoring thunderbird makes it happy again. For me, it's convenient to be able to disable/enable the svideo output from my graphics card (ati radeon 9250, using the opensource drivers) in order to watch movies on my tv screen. Disabling the screen when I am not using it is nice, as it's the only sure-fire way to prevent windows from opening on the tv screen (which is across the room and turned off) when I'm using the computer for anything else. Steps to reproduce: 1. start X with one screen enabled 2. start thunderbird, maximize the screen 3. add another display using xrandr. eg: xrandr --output S-video --mode 800x600 --rate 60 --above DVI-0 4. attempt to read a message in thunderbird. 5. unmaximize, minimize, and restore thunderbird Actual results: thunderbird does not work after changing using xrandr to add another display output. Expected results: Does this happen every time? yes. Other information: see here for the ubuntu launchpad bug: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/162212
Firefox and Thunderbird are not actually Gtk+ based. They use merely as much as to look like Gtk+ applications. Would you please check if the problem applies to real Gtk+ applications? Otherwise we would need to find out if something Mozilla applications are using is coming from Gtk and rename the bug accordingly.
I can confirm the same (or very similar, related) behavior when using GTK 2.14.7 while using xfce4 (4.4.3). Upon activating a second monitor, xfce will refuse to allow windows to be moved (my mouse or any other placement method) across an invisible boundry on the second monitor. The second monitor was activated using XRandR similarly to the original bug report. Reverting to GTK 2.12.11 immediately solves this problem. Rebuilding GTK 2.14.7 brings the problem back. This is repeatable and we have seen this is different hardware and X drivers. We are also using FreeBSD, so limited GTK releases are available through the Ports system. No intermediates between 2.12.11 and 2.14.7 are available, though I can manually test one if requested.
I should add that the boundary seems to be between the primary and secondary monitor. It *will* render windows on the second screen, but not allow a window to be bound to it (you can drag a window to the right of the primary monitor and see it on the second screen, but it seems to be just rendering the "offscreen" buffer.)
I've fixed this. The patch is attached. Between GTK 2.14.4 and 2.14.5 this change is what caused the broken behavior: 2008-10-22 Matthias Clasen <mclasen@redhat.com> Merged from trunk: * gdk/x11/gdkscreen-x11.c: Only emit size-changed if the screen size actually changed. The way you are checking to see if the screen size changed does *not* account for how the screen changes when a monitor is added or removed. As I am not an X or GTK developer I cannot, at this point, suggest a better way to do this other than to change the ordering so that _gdk_x11_screen_process_monitors_change() still gets called, while not emitting size-changed. There should be a more correct way to detect if the overall screen size (incl. virtual) has changed. The attached patch fixes this bug.
Created attachment 129012 [details] [review] Patch fixes Bug 561583, behavior described in comment #2 - patch/fix described in Comment #4
I don't think this should be necessary with current svn. We simply forgot to register xrandr events, so we never got the RRNotify that is sent on such changes.