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.
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
Ops... The workaround should be included in Fedora's xorg, not Fedora's KDE.
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.
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.
Well... if it happens on FreeBSD and I know it happens in SuSE and some other distros, this makes OS = All.
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
Maybe duplicate of bug 380861
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?
*** Bug 380861 has been marked as a duplicate of this bug. ***
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.
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).
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 :-)
*** Bug 234603 has been marked as a duplicate of this bug. ***
*** Bug 461563 has been marked as a duplicate of this bug. ***
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
It's really long time I've seen this bug in action, let it die quietly.
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.
Tried it again, looks working in F11.