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 problems): http://bugs.kde.org/show_bug.cgi?id=78467 The patch is also linked there: http://bugs.kde.org/attachment.cgi?id=5740&action=view 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: Section "InputDevice" Identifier "Keyboard0" . . . Option "XkbOptions" "altwin:meta_win" EndSection This fixes the WinKey modifier problems for me.
The fix does work but that option should be *enabled by default* for the PC104+ keyboards. (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? OK. Some background explainations are written in https://freedesktop.org/bugzilla/show_bug.cgi?id=926 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 these keycodes. (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 collisions.) 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: https://bugs.freedesktop.org/show_bug.cgi?id=926
*** This bug has been marked as a duplicate of 926 ***
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.