Bug 103051 - WinKey modifier doesn't work in XFree86-4.3.0-22.1
WinKey modifier doesn't work in XFree86-4.3.0-22.1
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-25 17:26 EDT by Felipe Alfaro Solana
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version: 4.3.0-26
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-05-28 04:15:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Felipe Alfaro Solana 2003-08-25 17:26:17 EDT
Description of problem: 
----------------------- 
Starting with XFree86-4.3.0-22.1 from Raw Hide, I have been experiencing 
problems when trying to assign global shortcuts in KDE that use the Windows 
key (WinKey) as a modifier. 
 
In previous releases of XFree86, I could assign "WinKey+s" combination to 
perform a shutdown of the system, or use "WinKey+k" to invoke xkill and kill a 
window. However, since XFree86-4.3.0-22.1, KDE doesn't recognize the Windows 
key as a valid modifier. It recognizes any combination using Alt, Ctrl or 
Shift, but the Windows key is completely ignored. 
 
What is really strange about this issue is that "xev" recognizes the Window 
key. For example, this is what "xev" dumps when pressing and releasing the 
Windows key on my keyboard: 
 
KeyPress event, serial 21, synthetic NO, window 0x2400001, 
    root 0x40, subw 0x0, time 575098, (106,363), root:(529,682), 
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, 
    XLookupString gives 0 bytes:  "" 
 
KeyRelease event, serial 24, synthetic NO, window 0x2400001, 
    root 0x40, subw 0x0, time 575132, (106,363), root:(529,682), 
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, 
    XLookupString gives 0 bytes:  "" 
 
However, if I go to KDE's Control Panel -> Regional & Accesibility -> Keyboard 
Shorcuts and then try to define a custom shortcut for any event that uses the 
Windows key, KDE refuses to recognize the Windows key modifier. For example, 
pressing "WinKey+s" is recognized only as "s" (the WinKey modifier is 
completely ignored) and thus, Control Panel complains about that. However, I 
can use "Alt+s", "Ctrl+s" or any other combination of modifiers, except the 
Windows key. In previous releases of XFree86, I have been using combinations 
like WinKey+s, WinKey+h and so on. 
 
This problem is reproducible on several machines running XFree86-4.3.0-22.1 or 
XFree86-4.3.0-22. One of the systems is running Red Hat Linux Severn 9.0.93 
updated with the latest packages from Raw Hide using a "yum" repository. 
 
Version-Release number of selected component (if applicable): 
XFree86-4.3.0-22.1 
kdebase-3.1.3-2 
 
How reproducible: 
----------------- 
Always 
 
Steps to Reproduce: 
1. Upgrade to XFree86-4.3.0-22.1 
2. Launch KDE's Control Panel 
3. Navigate to Regional & Accesibility -> Keyboard Shortcuts 
4. Try assigning a custom shortcut using the Windows key. 
     
Actual results: 
--------------- 
Although it seems some X11 programs do recognize the Windows key, it seems 
that KDE is unable to recognize the Windows key as a modifier. 
 
Expected results: 
----------------- 
The Windows key should be recognized as a valid modifier, as it was in 
previous releases of XFree86. 
 
Additional info:
Comment 1 Mike A. Harris 2003-08-25 21:08:11 EDT
What version of XFree86 did you have installed previously?
Comment 2 Felipe Alfaro Solana 2003-08-26 04:40:51 EDT
Previously, I have installed XFree86-4.3.0-17, the one that is installed by 
default with Red Hat Linux Severn 9.0.93. In fact, I have reverted to 
XFree86-4.3.0-17 in one of the systems I'm experiencing this problem on and 
now, KDE recognizes the Windows key as a valid modifier. 
Comment 3 Mike A. Harris 2003-09-04 21:20:20 EDT
Should be fixed in 4.3.0-26
Comment 4 Tim Keeler 2004-03-12 17:54:57 EST
hello, I just upgraded to XFree86-4.4.0 and I'm experiencing this same
problem! It worked fine when I was using the default XFree86 (4.3.0)
in Fedora, but when I upgraded to 4.4.0 my windows key isn't
recognized in KDE (although xev show's it fine as Super_L).

Any help?? Thanks!
Comment 5 Dunnigan Pierce 2004-03-29 18:49:39 EST
i think the new versions of xfree must have changed the default way
they handle the windows keys.  i had the same problem upgrading from
4.3 to 4.4  i was able to fix it by having my keygrabber(bbkeys) look
for a different modifier(mod4 - it used to look for Super) 
unfortunately, that's not going to help you with KDE :(  you might try
adding the windows keys to the mod3 modifier and see if that
helps(xmodmap -e 'add mod3 = Super_L Super_R')
Comment 6 Igor Bukanov 2004-05-27 15:23:31 EDT
After upgrating to Fedora 2 I got exactly the same problem: WinKey in
KDE is not recognized as a modifier so all my mappings with it are
useless...

Should this bug be reopenned?
Comment 7 Felipe Alfaro Solana 2004-05-27 16:56:34 EDT
This can be easily solved by adding the following line to the "InputDevice" 
section of the Xorg's configuration file: 
 
    Section "InputDevice" 
        Identifier      "Keyboard0" 
        . 
        . 
        . 
        Option          "XkbOptions" "altwin:meta_win" 
    EndSection 
 
Comment 8 Mike A. Harris 2004-05-28 04:15:41 EDT
Fedora Core 2 does not ship with XFree86.  I strongly recommend
reporting xkb related bugs directly to the XFree86 project for
OS releases in which XFree86 is included, by reporting the issue
to:  http://bugs.xfree86.org"

For OS releases which ship X.Org X11, such as Fedora Core 2, I
recommend reporting the bugs directly to the X.Org project in their
bugzilla located at http://bugzilla.freedesktop.org in the "xorg"
component.

The upstream xkb maintainer is very active and usually responds
to issues within a week or less, often with fixes.  Red Hat will
generally follow the upstream resolution on a given xkb issue,
as keeping closely in line with upstream for Xkb is very important.

Closing issue as WONTFIX, however if you do report this upstream,
please reopen this report and add the upstream bug URL if you would
like Red Hat to track the issue.  We can then set it to UPSTREAM
for tracking purposes, and monitor Ivan's resolution in the upstream
bugzilla.

Thanks in advance.

Note You need to log in before you can comment on or make changes to this bug.