|Summary:||Super key (left Windows key) functioning erratically|
|Product:||[Fedora] Fedora||Reporter:||Patrick Higgins <patrick133t>|
|Component:||xorg-x11||Assignee:||Peter Hutterer <peter.hutterer>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-14 18:14:44 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Patrick Higgins 2008-07-21 03:17:00 UTC
Description of problem: I like to configure my left Windows key to Super_L, which I noticed was the default in Fedora 9 (as reported by xev), so I didn't set the GNOME System->Preferences->Hardware->Keyboard->Layouts->Layout Options->Alt/Win key behavior->Super is mapped to the Win-keys option. I then set my System->Preferences->Look and Feel->Windows->Movement Key->Super option because that's how I like to move my windows around. The problem is that sometimes the super key just doesn't work. I see this in emacs as well, where I use super as a prefix for many commands. For example, emacs doesn't see s-r (super and r together) but instead just sees r. It's as if the super key isn't being pressed at all. Using super to drag windows around also doesn't work when this happens, and this happens more often than not. If I change the keyboard model in the keyboard layouts screen, it generally starts to work again, though for how long, I am not certain. It seems fairly sporadic. I just discovered that setting the "Super is mapped to the Win-keys" option seems to fix my problem, though I have not used it long enough to verify that the problem will not reappear. Here is what I see with xmodmap: Default layout options (except that Compose key position is set to "Right Win-key is Compose)" [phiggins@xeno ~]$ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_R (0x71), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) [phiggins@xeno ~]$ xmodmap -pke | grep Super keycode 115 = Super_L keycode 127 = NoSymbol Super_L Here's the xmodmap output when I set the "Super is mapped to the Win-keys" option: [phiggins@xeno ~]$ xmodmap -pm xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Alt_R (0x71), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) [phiggins@xeno ~]$ xmodmap -pke | grep Super keycode 115 = Super_L keycode 127 = NoSymbol Super_L I think the difference must be attributable to the "mod4 Super_L (0x73)" bit that is missing when it fails to work. Why are there two numeric values for Super_L? Of course, now that I've been fiddling with it, I have gone back to the default setting that was problematic and it is working again, even with the above modmap values. This is making me crazy! I have been having this problem with previous Fedora releases, too. I cannot remember when I first started having the problem, but I have always upgraded by formatting everything but my home partition, and then I have tended to delete my .gnome and .gconf directories whenever I upgrade, but I may have missed something and am carrying around some old configuration value that is causing problems.
Comment 1 Patrick Higgins 2008-07-22 12:57:16 UTC
Ok, right now the problem is happening and the xmodmap output is slightly different: [phiggins@xeno ~]$ xmodmap -pke | grep Super keycode 115 = Super_L keycode 116 = Super_R keycode 127 = NoSymbol Super_L The xmodmap -pm output is the same. Maybe the problem is the Super_R on keycode 116?
Comment 2 Bug Zapper 2009-06-10 02:09: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 3 Bug Zapper 2009-07-14 18:14:44 UTC
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.