GNOME Bugzilla – Bug 790627
[mutter] Super key not ignored by shortcut inhibitor as it should
Last modified: 2017-12-21 08:10:28 UTC
Description: When a Wayland client issue a Shortcut inhibition request which is granted by the user, all key shortcuts should reach the client, including the "overview" key. How reproducible: 100% Steps to reproduce: 1. log on GNOME on Wayland 2. run virt-manager or gnome-boxes 3. start a vm running gnome-shell 4. click into the guest VM window, grant the shortcut inhibition 5. press "Super" actual result: The overview shows up on the host expected results: The overview shows in the guest VM Additional data: The "Super" key is special, it's handled in process_overlay_key() which is called from process_key_event(), whereas the shortcut inhibition is checked after in process_event()
Created attachment 364060 [details] [review] [PATCH] keybindings: Super should be inhibitable Possible patch. Note: process_iso_next_group() is another special case, yet I think this other one should not be inhibited because this is how it works with X11 I reckon, the change group shortcut is handled in the Xserver regardless of the client grabs.
Humble ping, anyone to do a review of this patch please?
Someone to review this please? This is preventing using gnome-shell's Super key within a VM in gnome-shell...
Review of attachment 364060 [details] [review]: ::: src/core/keybindings.c @@ +1955,3 @@ + if (meta_window_shortcuts_inhibited (display->focus_window, source)) + return FALSE; + } I'm not familiar with how the super key works here, but I'll give it a try: This means that that the "overlay_key_only_pressed" may never being set. If so, do Super keybindings (e.g. the uninhibit keybinding still get triggered via the regular path? This may also mean the "overlay_key_only_pressed" might get stuck, if a client inhibits shortcuts while the Super key is pressed. Looks like we must handle that some how.
(In reply to Jonas Ådahl from comment #4) > I'm not familiar with how the super key works here, but I'll give it a try: Yeah, neither am I unfortunately... > This means that that the "overlay_key_only_pressed" may never being set. If > so, do Super keybindings (e.g. the uninhibit keybinding still get triggered > via the regular path? Yes, because precisely this is not an “overlay only” key press (it's a combo), so the specific key-combo to “uninhibit keybindings” works even with that patch. > This may also mean the "overlay_key_only_pressed" might get stuck, if a > client inhibits shortcuts while the Super key is pressed. Looks like we must > handle that some how. True, we can simply get away with it by simply setting “keys->overlay_key_only_pressed” to FALSE in that case (being Wayland, we do not care about X11 event processing with XIAllowEvents())
Created attachment 365795 [details] [review] [PATCH] keybindings: Super should be inhibitable Updated patch. I think it's safe to just check for “overlay_key_only_pressed” when checking for the shortcuts inhibitted, because on Wayland we don't care about blocking/releasing events in the Xserver (and shortcuts inhibitor is purely Wayland). I tested with a test client that issues a delayed shortcut inhibitor request so I could quickly switch to the overview window prior to the request to be received, and the Suprt key was stil lworking to return to the “normal” view. And when in the normal view, the Super key is inhibited as expected. I also tested that the keyboard shortcuts to release the shrotcut inhibitor involving Suprt (“Super+Escape” by default) still works with the patch.
Review of attachment 365795 [details] [review]: looks good to me now
Comment on attachment 365795 [details] [review] [PATCH] keybindings: Super should be inhibitable attachment 365795 [details] [review] pushed to git master as commit 49f0295 - keybindings: Super should be inhibitable
Thanks!