Quoting a Debian bug report (#409612): The modifier mappings in stock keyboard layouts are broken. For details, I'll just attach the Ion FAQ entry below from <http://iki.fi/tuomov/ion/faq/entries/Modifier_releases.html>. (I have not myself experienced that problem, though -- I don't use Xkb crud at all, because customisation of Xkb based layouts is too laboursome, difficult, undocumented etc. -- but users have experienced it on various systems, and this seems the easiest channel to report the problem.) --- _Ion doesn't notice that a modifier has been released (in actions that use like `kpress_wait`, such as META+C, or in “grabmenus”)._ This is most likely to be an X bug/keyboard misconfiguration, when you have changed the “META” key of Ion to Mod4, or something else that supposed has one of the Win-keys bound to it. For some reason, some Xorg comes with some totally broken stock keyboard layouts that define multiple keycodes for the `Super_L` and such “keysyms”, one of them spurious. However, various part of X or Xlib can not handle that, and report the wrong keycode when queried.<sup>1</sup> To check if this is the case, first run `xmodmap` to check what key is bound to the Mod4 (or perhaps Mod3 depending on the configuration) modifier. You may see a line like this: mod4 Super_L (0x7f), Hyper_L (0x80) The number 0x7f=127 is the keycode, and this is highly likely the wrong keycode. Check with `xmodmap -pke|grep Super_L` to see what keycodes have `Super_L` bound to them. If you see something like this, your keymap is misconfigured: keycode 115 = Super_L keycode 127 = NoSymbol Super_L The keycode 115 is the keycode for the real left Win key, and 127 is spurious. However, the modifier subsystem only seems to see the latter. Putting the following commands in `~/.Xmodmap` and runnning `xmodmap ~/.Xmodmap` should fix the issue. You may also want/need to repeat for the other Win keys (`Hyper_L` and 0x80=127 in our example case). remove mod4 = Super_L keycode 127 = NoSymbol add mod4 = Super_L (The `remove` command is needed for some reason to not confuse X.) Unless your system configuration is totally weird (and I wouldn't put it past systems built to run Gnome), next time you start X, `~/.Xmodmap` should be loaded automatically. On a working modifier configuration running `xmodmap` should display a line like below (0x73 following `Super_L` being the important part). mod4 Super_L (0x73) --- <sup>1</sup> `XKeysymToKeycode` in particular can only return one keycode. However, `XGetModifierMapping` should be able to report more, but for some reason doesn't. Maybe it uses the former.
Try commenting the lines key <SUPR> { [ NoSymbol, Super_L ] }; modifier_map Mod4 { <SUPR> }; in symbols/pc
I have tried to comment this line but it does exactly thing as before. Any other idea?
What do you see in xmodmap now? xmodmap -pke|grep Super_L
(In reply to comment #3) > What do you see in xmodmap now? > > xmodmap -pke|grep Super_L > keycode 115 = Super_L keycode 127 = NoSymbol Super_L
That is very odd. The keycode 127 is SUPR and once you commented it out, it should be gone. Could you please do xkbcomp :0 -xkb out.xkb and attach out.xkb here?
Commenting out those from my symbols/pc file does correct the output of 'xmodmap -pke | grep Super_L' so that it only has the 'keycode 115 = Super_L' entry but it also removes Super_L from the mod4 line in the output of 'xmodmap'. Which makes sense since I assume that is what the modifier_map line I commented out is about, but that leaves me with a mod4 entry of "mod4 Hyper_L (0x80)" which is slightly less than desired. Sergey: Anything else you want me to try or need me to do? Also, do you not have this happening on the machines you have access to? Or is this a debian only issue somehow? For reference an xkb.out generated from the command you suggested has in it a "<SUPR> = 127;" line in it but does not have a "modifier_map Mod4 { <SUPR> };" line in it.
What if you add (after those two commented out lines) modifier_map Mod4 { Super_L };
Bugzilla Upgrade Mass Bug Change NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO. - benjsc fd.o Wrangler
I just tried commenting out those two lines and adding the line modifier_map Mod4 { Super_L }; With xmodmap I get mod4 Super_L (0x73), Hyper_L (0x80) and $ xmodmap -pke | grep Super_L keycode 115 = Super_L This is on a fully updated Debian unstable.
I should probably add that before I had exactly the same output as the previous reporter (i.e. two lines with xmodmap -pke | grep Super_L).
> $ xmodmap -pke | grep Super_L > keycode 115 = Super_L So, this is what's expected isn't it? Is this the behaviour you want?
As per the Ion FAQ entry, I guess so. I came into this because I've had problems after I updated my Debian unstable system recently. I've configured GNOME/Metacity to use Windows key + F1 to switch desktop, and sometimes when I switch desktop with that combination, X or something in X gets to a state where it thinks the Windows key is depressed all the time. Hitting or holding the Windows key doesn't help it out of the mess. This means that the system is completely broken. I can't use the keyboard because everything I press is interpreted as a keystroke beginning with Super, and I can't use the mouse because Super + mouse click means "move window" so the application underneath never gets the click. I've found no way out other than to kill and restart X. Really annoying, as you might imagine. It never happened before the update. I hope it's caused by this bug. After I patched the symbols/pc file, I've not experienced any trouble. But that's only a couple of hours of testing. I'll test it some more and report back if the problem occurs again.
Another idea. Could you please try returning symbols/pc to original state - and using XkbOptions altwin:super_win and altwin:alt_super_win. They should have similar effect. I would be very interested in your results.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/5.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.