Bugzilla – Bug 587
[XKB] Can't use the "Win" keys for PC104+ keyboards
Last modified: 2006-04-04 07:19:36 UTC
The modifier is not recognized and it can't be used in combinations with other
keys under KDE (maybe others).
The problem is discussed on the KDE Buglist (somewhere after the mouse
The patch is also linked there:
Is is reported for XFree4.4.0 but I seem to have the same problem for X.org
(test2 build from ArchLinux - http://www.archlinux.org).
I haven't compiled xkb with that patch to see that it works also on X.org.
*** Bug 588 has been marked as a duplicate of this bug. ***
I have been suffering the same problems on Fedora Core 2. The solution seems to add an
"XkbOptions" line to the Xorg's configuration file, inside the "InputDevice" section, as follows:
Option "XkbOptions" "altwin:meta_win"
This fixes the WinKey modifier problems for me.
The fix does work but that option should be *enabled by default* for the
(I haven't even asked myself if there is such an option when I used XFree86
4.3, because it worked out of the box)
Are you sure it should be meta_win - not alt_super_win or anything? It is not a
problem to add this option - but which of altwin options is correct for this
case? I'm just afraid different people can have different opinions here.
Is anyone investigating this issue currently?
http://freedesktop.org/bugzilla/show_bug.cgi?id=1136 appears to possibly
be a duplicate of this bug.
> Is anyone investigating this issue currently?
Some background explainations are written in
Please, read them first.
Regarding this report ...
It is a case where toolkits can't map correctly modifier keysyms to modifiers
with our complex keymaps. The Win keys set Mod4 well (it is visible in xev
output) and modifier mapping table provides needed information for
'modifier<->keysym' mapping (xmodmap shows it).
The Xlib's subroutine (non-public, unfortunately) _XKeysymToModifiers finds this
mapping correctly because it scans all keycodes of a modifier and all keysyms of
(On the other hand there is a danger that it can tie unneeded modifiers to the
keysym. But the 'fake keys' introducing was made exactly to prevent such
The corresponded routine in icewm firstly searches keycode with interesting
keysym, stops on the first occurrence and tries to find this keycode in the
'modifier to keycodes table'. Since it doesn't come to fake keys it takes wrong
keycode and can't find it in the modifiers mapping table.
The libkdecore routine is better. It firstly scans the modifier mapping table
and for each keycode there tries to find a modifier keysym. But it takes the
first keysym only whereas fale keysyms have NoSymbol there and the modifier
keysym itself in the second column. As a result it can't find the mapping too.
Of course, I don't consider these as bugs and I don't blame their developers.
They made those routines according to common sense and couldn't foresee that the
keymap can become so complicated.
But the worse thing is that I can't imagine how to make the keymap that could
satisfy all those approaches and would be consistent internaly.
I can offer patches for icewm and libkdecore and I think the only way is to
unify somehow such routines (in differnt toolkits) that search the
keysym_to_modifier mapping. At least it would garanty that we get the same
problem in all toolkits and could make needed changes in a keymap that would
solve the problem for all toolkits together.
Looks like a duplicate of:
*** This bug has been marked as a duplicate of 926 ***