Bug 12526 - wrong mod4 mapping
Summary: wrong mod4 mapping
Alias: None
Product: xkeyboard-config
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: xkb
QA Contact:
URL: http://bugs.debian.org/cgi-bin/bugrep...
Keywords: NEEDINFO
Depends on:
Reported: 2007-09-22 18:12 UTC by Mohammed Adnène Trojette
Modified: 2008-05-03 14:39 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Mohammed Adnène Trojette 2007-09-22 18:12:20 UTC
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
(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

    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.
Comment 1 Sergey V. Udaltsov 2007-09-23 03:25:58 UTC
Try commenting the lines

    key <SUPR> {        [ NoSymbol, Super_L     ]       };
    modifier_map Mod4   { <SUPR> };

in symbols/pc
Comment 2 Arnaud Fontaine 2007-09-24 16:48:55 UTC
I have tried to comment this line but it does exactly thing as before. Any other idea?
Comment 3 Sergey V. Udaltsov 2007-09-24 16:58:11 UTC
What do you see in xmodmap now?

xmodmap -pke|grep Super_L
Comment 4 Arnaud Fontaine 2007-10-01 13:20:43 UTC
(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
Comment 5 Sergey V. Udaltsov 2007-10-01 13:25:51 UTC
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?

Comment 6 Etan Reisner 2007-10-20 19:20:46 UTC
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.
Comment 7 Sergey V. Udaltsov 2007-10-21 05:52:56 UTC
What if you add (after those two commented out lines)

modifier_map Mod4   { Super_L };
Comment 8 Benjamin Close 2008-01-11 02:39:06 UTC
Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler
Comment 9 Ole Laursen 2008-03-02 13:56:16 UTC
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)


  $ xmodmap -pke | grep Super_L
  keycode 115 = Super_L

This is on a fully updated Debian unstable.
Comment 10 Ole Laursen 2008-03-02 13:57:29 UTC
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).
Comment 11 Sergey V. Udaltsov 2008-03-02 15:08:51 UTC
>   $ xmodmap -pke | grep Super_L
>   keycode 115 = Super_L
So, this is what's expected isn't it? Is this the behaviour you want?
Comment 12 Ole Laursen 2008-03-03 01:17:35 UTC
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.
Comment 13 Sergey V. Udaltsov 2008-05-03 14:39:20 UTC
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.

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.