GNOME Bugzilla – Bug 697116
Super_R doesn't bring up Activities
Last modified: 2016-11-07 13:46:10 UTC
My Kinesis keyboard has a "Windows" key on it. Pressing it doesn't bring up the Activities menu. (Pressing the "Penguin" key on my laptop's built-in keyboard does.) It seems that the Kinesis keyboard is generating keycode 134 (Super_R), and this isn't being treated the same way as Super_L. Here's the output of xmodmap: $ xmodmap xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69) mod1 Alt_L (0x40), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) Just for fun, I thought I would try to remap keycode 134 to generate Super_L and see if that helped. $ xmodmap xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69) mod1 Alt_L (0x40), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x85), Super_L (0x86), Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) But still nothing. All the other GNOME shortcuts that I can find to try, work fine with the button on the Kinesis keyboard. Super_R + M brings up the messages area, and Super_R plus left mouse can move windows around.
(In reply to comment #0) > But still nothing. All the other GNOME shortcuts that I can find to try, work > fine with the button on the Kinesis keyboard. Super_R + M brings up the > messages area, and Super_R plus left mouse can move windows around. Yes, those shortcuts (or rather: all shortcuts except for the overview key) use Super as a modifier and not Super_R/Super_L as specific keys. Also see gsettings get org.gnome.mutter overlay-key
Hmm, with the gsettings command, I can set overlay-key to Super_R, which makes it work on my Kinesis keyboard but not my laptop's built-in keyboard. But if I use xmodmap to change key 133 to also generate Super_R, then it stops working on my Kinesis keyboard (and starts working on my laptop's built-in keyboard). Thanks for the workaround, but is there any way for mutter to listen to all the keys that generate Super_R, or alternately to both Super_R and Super_L?
Having a solution for this would be appreciated. My laptop also has only a single Windows key which is generating the keycode for Super_R (although it is on the left side). One can use xmodmap to switch Super_L and Super_R, which will enable me to use the key to open the activities: xmodmap -e "keycode 133 = Super_R NoSymbol Super_R" xmodmap -e "keycode 134 = Super_L NoSymbol Super_L" But I also frequently attach an external keyboard, which only has Super_L and which won't work in that case. I think gnome-shell should listen to both Super keys here.
its not about the symbol, its about the modifier thats bound to the key. if you run xmodmap, does it list both Super_L and Super_R for Mod4 ? (Mod4 normally plays the role of Super modifier)
oh, actually, I guess you are right. For the special super-release binding, we can't be looking at modifiers
Yes, it does: xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x69) mod1 Alt_L (0x40), Meta_L (0xcd) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb) But nevertheless the gnome shell activities view opens only when I press Super_L and my remapping workaround above allows me to use Super_R instead (but not both). For me this looks like gnome shell is explicitely binding to the keycode of Super_L.
(In reply to comment #6) > But nevertheless the gnome shell activities view opens only when I press > Super_L and my remapping workaround above allows me to use Super_R instead (but > not both). For me this looks like gnome shell is explicitely binding to the > keycode of Super_L. Yes. We are jumping through some (quite ugly) hoops to make a modifier behave like a normal key. I'll also repeat my note from comment #1: you don't have to remap your keys with xmodmap, you can use gsettings set org.gnome.mutter overlay-key '"Super_R"' to set a different key.
I guess the question is: can we use that key to make both Super_L and Super_R work as overlay key ?
(In reply to comment #8) > I guess the question is: can we use that key to make both Super_L and Super_R > work as overlay key ? Sure. We can't just turn the key into an array without breaking user settings, but we could start interpreting the key as a comma-separated list of key symbols. The main issue is that treating a modifier as normal key is already tricky enough (see bug 660922 for instance), so adding fun stuff like (1) press overlay-1 (2) press overlay-2 (3) release overlay-2 (4) press overlay-3 to the mix is not going to make it prettier ...
(In reply to comment #9) > (In reply to comment #8) > > I guess the question is: can we use that key to make both Super_L and Super_R > > work as overlay key ? > > Sure. We can't just turn the key into an array without breaking user settings, > but we could start interpreting the key as a comma-separated list of key > symbols. The main issue is that treating a modifier as normal key is already > tricky enough (see bug 660922 for instance), so adding fun stuff like > (1) press overlay-1 > (2) press overlay-2 > (3) release overlay-2 > (4) press overlay-3 > to the mix is not going to make it prettier ... Does that need any special-casing at all ? This will give you Super-Super_R or Super-Super_L depending on which one gets pressed first, so you can easily filter it out just like you currently filter out Alt-Super_L (I assume)
*** Bug 724691 has been marked as a duplicate of this bug. ***
Moving to general, keyboard is for the on-screen keyboard.
I have another case where listening to both is needed, Microsoft's new mice (and possibly other vendors). They've started adding a thumb Super_R button. It would be sooooo sweet to be able to quickly open the overview using the mouse and quickly switching windows or launching something new. :)
sounds like you would be much better off binding that thumb button to a different keysym and bind that to the overview, than interfering with the extra complications of the Super key
I don't think the user should need to fiddle around with key bindings, IMHO having Super_R behave like Super_L in this case should just be the default. From an outside view it's also hard to understand why it is so difficult having one button do the same what another, similar button, already does.
Yeah, fiddling with keymaps is hardly a good end user experience. Unless you're planning on making a decent UI for it? ;) Besides, it has a Windows logo on it so Super is a reasonable mapping. And it is a right handed mouse, so _R also seems proper. :P I understand that this is a technical challenge. But that doesn't mean it shouldn't be done. Just that it might not be at the top of the priority queue.
This has also been reported on https://bbs.archlinux.org/viewtopic.php?pid=1601504#p1601504 I really don't understand why supporting both keys should be so difficult. Or why, whoever implemented this in the first case, did not think it would make sense to support both Super_L AND Super_R. Even on keyboards with both keys present having one open the overview and the other not is pretty unexpected behaviour.
(In reply to Philipp Wolfer from comment #17) > This has also been reported on > https://bbs.archlinux.org/viewtopic.php?pid=1601504#p1601504 > > I really don't understand why supporting both keys should be so difficult. Feel free to read the state machine in https://git.gnome.org/browse/mutter/tree/src/core/keybindings.c#n1722 and extend the logic to handle multiple overlay keys yourself.
*** This bug has been marked as a duplicate of bug 610987 ***