Bug 239409 - Win key does not (always) work as modifier
Win key does not (always) work as modifier
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-keyboard (Show other bugs)
All All
medium Severity medium
: ---
: ---
Assigned To: Peter Hutterer
David Lawrence
: 234603 380861 461563 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-05-08 05:25 EDT by Doncho N. Gunchev
Modified: 2009-07-11 11:14 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-11 11:14:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Broken state (49.56 KB, text/plain)
2008-08-22 07:59 EDT, Stefan Becker
no flags Details
Working state (49.59 KB, text/plain)
2008-08-22 08:01 EDT, Stefan Becker
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 7008 None None None Never

  None (edit)
Description Doncho N. Gunchev 2007-05-08 05:25:25 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Log in to GNOME/KDE/XFCE
2. Try setting up a key combilation like Win+X
Actual results:
One only gets X, not Win+X

Expected results:
Win should work as modifier

Additional info:
There's a (partial) workarounds for this:

Option          "XkbOptions" "altwin:left_meta_win" (xorg config)


add mod4 = Super_L (xmodmap)

With the second workaround I got amarok's global shortcuts working, haven't
tried the first one.
Comment 1 Marcelo 2007-05-25 20:54:34 EDT
Confirmed here. The workaround which adds:
Option          "XkbOptions" "altwin:left_meta_win"
to xorg.conf works partially, because only the left win key works if this is
used. If I use instead:
Option          "XkbOptions" "altwin:meta_win"
then both winkeys work, but then the right ALT does not work as ALT Gr anymore.
There are bugs opened in freedesktop's bugzilla about this:
However, it's old news but no one has picked it up yet. I would suggest that
some workaround is included in Fedora's KDE while the bug isn't solved upstream
Comment 2 Marcelo 2007-05-25 20:55:58 EDT
Ops... The workaround should be included in Fedora's xorg, not Fedora's KDE.
Comment 3 Doncho N. Gunchev 2008-02-24 18:23:28 EST
It would be nice if this is fixed or workarounded, because some applications 
(VirtualBox for example) are starting to rely on the buggy behaviour... 
Currently, if I workaround it VirtualBox looses it's ability to send the key 
to the guest OS.
Comment 4 Scott Robbins 2008-03-04 19:19:43 EST
This bug has been around for awhile--I'm sure it's an xorg, rather than Linux 
or Fedora issue, because it also happens in FreeBSD.  

I've been using the .xmodmaprc fix, but I found I also had to include the line
keycode 115 = Super_L

What makes it more interesting is that now, in Rawhide, there has apparently 
been a change and it's now keycode 133.  I've run into another oddity (I don't 
expect help here, as I've never heard of anyone else with the issue, and I can 
only reproduce it on one machine, but what the heck)

I boot into runlevel 3 and usually use fluxbox, started with startx and using 
an .xinitrc.  Until recent upgrades and the change in keycode, I simply had 
xmodmap ~/.xmodmaprc in my .xinitrc and it worked.

After that, now, although it will work, both the shift and control keys don't 
work. That is, if I start X with an .xinitrc that has it read ~/.xmodmaprc, I 
can't use the shift or ctl key. 
However, if I start X, and THEN run xmodmap ~/.xmodmaprc, all is fine.  

I've seen no mention of it when googling, nor have I seen it on the fedora-test 
list, so I assume I'm just lucky.  :)

Anyway, the Windows key sometimes not working has been a problem for awhile, I 
think.  I think I first ran into it when FreeBSD updated to xorg 7 something.  

However, if I use the other workaround, the XkbOptions in xorg, then the 
problem doesn't occur.  The Windows key works as Mod4, ctl works and shift 
works.  I'd always used the xmodmap workaround until this problem occurred, 
which is when I googled a bit more and found the xorg.conf fix.  
Comment 5 Doncho N. Gunchev 2008-03-04 19:39:35 EST
Well... if it happens on FreeBSD and I know it happens in SuSE and some other
distros, this makes OS = All.
Comment 6 Bug Zapper 2008-05-13 22:52:22 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 7 Matěj Cepl 2008-06-06 04:48:46 EDT
Maybe duplicate of bug 380861
Comment 8 Stefan Becker 2008-08-19 03:25:34 EDT
Definitely the same problem as bug 380861 and the ones reported on freedesktop.org.

Verified that problem still exists on Fedora 9 with


Two workarounds confirmed on my machine:

a)   xorg.conf: Option "XkbOptions" "altwin:left_meta_win"

This makes Super_L work as modifier immediately at X server startup.

b)   xmodmap -e 'clear mod4' -e 'add mod4 = Super_L Hyper_L'

That deletes & recreates the original contents for mod4. After that Super_L works correctly as modifier.

IMHO workaround b) points out that the root cause is a problem with Xkb keymap loading in the X server. It loads the keycodes correctly (i.e. Super_L is assigned to the correct key [105] on the keyboard) but it is not marked as modifier. Maybe the ordering of keycode vs. modifier setup is wrong or worse random?

As this also has been reported on bugs.freedesktop.org for other systems I don't think this is a Fedora bug but a generic X (server?) bug. Can Fedora push Xorg to fix it?
Comment 9 Peter Hutterer 2008-08-22 01:51:53 EDT
*** Bug 380861 has been marked as a duplicate of this bug. ***
Comment 10 Peter Hutterer 2008-08-22 03:12:31 EDT
I just tried this with the rawhide X server, and I cannot reproduce it, despite restarting the server about 50 times. Neither with GNOME, nor with a blank server.

Can you please run xkbcomp :0 working.xkb and xkbcomp :0 busted.xkb when it is working and broken, respectivly, and attach both files.
Of course, if you can try rawhide and verify if the bug still exists there that'd be perfect.

(In reply to comment #4)
> What makes it more interesting is that now, in Rawhide, there has apparently 
> been a change and it's now keycode 133.

caused by the switch to evdev

> After that, now, although it will work, both the shift and control keys don't 
> work. That is, if I start X with an .xinitrc that has it read ~/.xmodmaprc, I 
> can't use the shift or ctl key. 
> However, if I start X, and THEN run xmodmap ~/.xmodmaprc, all is fine.

This is probably Bug 447252.
Comment 11 Stefan Becker 2008-08-22 07:59:08 EDT
Created attachment 314791 [details]
Broken state

Of course when I tried to force the issue to generate the files I couldn't reproduce it :-(

But then I did the following on my machine:

 - Left X session -> back in GDM
 - CTRL-ALT-F1 -> VT1
 - CTRL-ALT-F7 -> GDM screen
 - login

Now the SUPER_L was busted (see attached file).
Comment 12 Stefan Becker 2008-08-22 08:01:11 EDT
Created attachment 314792 [details]
Working state

Here is the state after executing the xmodmap workaround.

Only difference to broken state:

$ diff -u busted.xkb working.xkb
--- busted.xkb  2008-08-22 14:54:01.000000000 +0300
+++ working.xkb 2008-08-22 14:54:36.000000000 +0300
@@ -1576,6 +1576,7 @@
     modifier_map Mod5 { <MDSW> };
     modifier_map Control { <RCTL> };
     modifier_map Mod5 { <RALT> };
+    modifier_map Mod4 { <LWIN> };
     modifier_map Mod5 { <LVL3> };
     modifier_map Mod4 { <SUPR> };
     modifier_map Mod4 { <HYPR> };

But I guess that was obvious that Left-Win key didn't work as modifier :-)
Comment 13 Peter Hutterer 2008-09-08 04:57:53 EDT
*** Bug 234603 has been marked as a duplicate of this bug. ***
Comment 14 Michal Nowak 2008-09-09 04:36:12 EDT
*** Bug 461563 has been marked as a duplicate of this bug. ***
Comment 15 Bug Zapper 2009-06-09 18:35:40 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 16 Michal Nowak 2009-06-10 04:07:33 EDT
It's really long time I've seen this bug in action, let it die quietly.
Comment 17 Jason Farrell 2009-06-10 09:07:47 EDT
I haven't been able to reproduce this in quite a while either. Not since F9 iirc. Amarok *used* to be a pain to use because of it.
Comment 18 Doncho N. Gunchev 2009-07-11 11:14:43 EDT
Tried it again, looks working in F11.

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