Bug 239409 - Win key does not (always) work as modifier
Summary: Win key does not (always) work as modifier
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-keyboard
Version: 9
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: David Lawrence
URL:
Whiteboard:
: 234603 380861 461563 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-08 09:25 UTC by Doncho Gunchev
Modified: 2018-04-11 15:39 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-11 15:14:43 UTC
Type: ---
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 7008 0 None None None Never

Description Doncho Gunchev 2007-05-08 09:25:25 UTC
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)

or

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-26 00:54:34 UTC
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:
http://bugs.freedesktop.org/show_bug.cgi?id=7008
http://bugs.freedesktop.org/show_bug.cgi?id=8815
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-26 00:55:58 UTC
Ops... The workaround should be included in Fedora's xorg, not Fedora's KDE.

Comment 3 Doncho Gunchev 2008-02-24 23:23:28 UTC
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-05 00:19:43 UTC
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 Gunchev 2008-03-05 00:39:35 UTC
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-14 02:52:22 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 7 Matěj Cepl 2008-06-06 08:48:46 UTC
Maybe duplicate of bug 380861

Comment 8 Stefan Becker 2008-08-19 07:25:34 UTC
Definitely the same problem as bug 380861 and the ones reported on freedesktop.org.


Verified that problem still exists on Fedora 9 with

  xorg-x11-server-Xorg-1.4.99.905-2.20080702.fc9.i386


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 05:51:53 UTC
*** Bug 380861 has been marked as a duplicate of this bug. ***

Comment 10 Peter Hutterer 2008-08-22 07:12:31 UTC
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 11:59:08 UTC
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 12:01:11 UTC
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 08:57:53 UTC
*** Bug 234603 has been marked as a duplicate of this bug. ***

Comment 14 Michal Nowak 2008-09-09 08:36:12 UTC
*** Bug 461563 has been marked as a duplicate of this bug. ***

Comment 15 Bug Zapper 2009-06-09 22:35:40 UTC
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Michal Nowak 2009-06-10 08:07:33 UTC
It's really long time I've seen this bug in action, let it die quietly.

Comment 17 Jason Farrell 2009-06-10 13:07:47 UTC
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 Gunchev 2009-07-11 15:14:43 UTC
Tried it again, looks working in F11.


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