GNOME Bugzilla – Bug 590188
Keyboard grab prevents XF86Display hotkey from reaching gnome-settings-daemon
Last modified: 2014-08-19 21:00:55 UTC
1. Have two monitors plugged in. 2. Lock the screen with gnome-screensaver. 3. Hit a key to have the password dialog appear in one of the monitors. 4. Disconnect the monitor with the password dialog. 5. Hit XF86Display hotkey (Fn-F7 on Thinkpads, for example). You would expect gnome-settings-daemon to reset the RANDR configuration, and then gnome-screensaver would move the password dialog to the remaining monitor. However, gnome-screensaver grabs the keyboard. This makes the XF86Display hotkey not reach gnome-settings-daemon at all, so you can't unlock your screen. This is a corner case, because in an ideal world we should get hotplug/unplug events from the graphics hardware, but that does not happen for old connector types like VGA. However, it's pretty bad that "save-my-butt" hotkeys like XF86Display are not passed through... what should we do about this? Gnome-screensaver could do this if it receives an XF86Display key: 1. Call XRRGetScreenResources(...) 2. This will make the X server reprobe the monitor outputs. If something got disconnected, it will emit a RANDR event. 3. Gnome-settings-daemon will catch that RANDR event, reconfigure the outputs, and gnome-screensaver will then move its password dialog to the right monitor as usual.
This is a problem for volume keys, too. I wonder if we should make gnome-screensaver load a subset of the g-s-d plugins itself, or something. Of course, maybe that's going overboard and just doing the XRRGetScreenResources () call is good enough.
also wanted to add that if we ever turn on factory mode for gdm and switch screensaver to use gdm for the lock dialog then this problem will go away.
Seems reasonable. Patch?
Created attachment 142648 [details] [review] gnome-screensaver-xf86display.diff Sorry for the sloppiness; this is an untested, uncompiled patch. I don't really have time right now to do it properly, but it should have all the meat in place. This makes gnome-screensaver capture the XF86Display hotkey and re-probe the RANDR outputs in that case. That will in turn cause gnome-settings-daemon to reconfigure the displays when it gets a RANDR event from the X server.
Created attachment 177695 [details] [review] bgo#590188 - Capture the GDK_Display (XF86Display) key to do a video-mode change We use gnome-settings-daemon's D-Bus interface for changing the RANDR mode.
The previous patch is a bit more involved, but doesn't use any RANDR calls explicitly. Rather, it calls out via D-Bus to gnome-settings-daemon to do the right thing. This came from https://bugzilla.novell.com/show_bug.cgi?id=660227 - it is the patch we are using for Suse.
Federico, would you say attachment 177695 [details] [review] is good as-is to go in?
for the record, bug 422390 is the volume keys bug alluded to in comment 1 Note if we go with attachment 177695 [details] [review] we probably need to handle the super-p shenangins of certain windows-centric laptops as well. It might be a good idea to somehow reuse/share the messy key grabbing logic with g-s-d.
Review of attachment 177695 [details] [review]: That's the wrong way to do things. You're reimplementing bits of gnome-settings-daemon in gnome-screensaver. You should have a list of hardcoded keysyms (such as GDK_Display, etc.) which you would pass down to the root window. gnome-settings-daemon could then handle those. Trying to handle those keys yourself means that you will start being in a whole world of pain reimplementing the volume keys (which would bring us yet another place where the code to interact with PulseAudio lives).
(In reply to comment #9) > Review of attachment 177695 [details] [review]: > > That's the wrong way to do things. You're reimplementing bits of > gnome-settings-daemon in gnome-screensaver. Well, it's just seeing if GDK_Display was pressed, and in that case it calls the D-Bus method from g-s-d's randr plugin. That's pretty much the same thing that g-s-d's media-keys does, although the latter also handles Super-P and XF86RotateWindows via acme.h. Other than that, I'd like someone to double-check the D-bus stuff in the patch to see if it is as small as it could be - but I think it's good to go. > You should have a list of hardcoded keysyms (such as GDK_Display, etc.) which > you would pass down to the root window. gnome-settings-daemon could then handle > those. > > Trying to handle those keys yourself means that you will start being in a whole > world of pain reimplementing the volume keys (which would bring us yet another > place where the code to interact with PulseAudio lives). Forwarding keys to the root window is certainly an option. Does gnome-screensaver depend on g-s-d? If so, it would be nice to have g-s-d say *which* keys it wants forwarded, to avoid having to change both when we fiddle with the keys. Maybe just store a gsettings key with the keysym names...
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 422390 ***