Description of problem: in a deviation from old behavior, the windows key cannot be used for modified keystrokes in the window manager's "preferences -> keyboard shortcuts" dialog. I used to successfully set Windows-F1 to switch to workspace 1 (etc) but it no longer works. 'xmodmap -pm' reports that super_l is <mod4> and so why is it being treated as a normal keystroke instead of the modifier that it is? Also, I check the bottom radio button in the "preferences -> windows" dialog (Super is also used as the movement modifier for mouse actions)... This does seem to be a change from relatively recent behavior. Version-Release number of selected component (if applicable): Steps to Reproduce: preferences -> windows -> check super is movement modifier preferences -> keyboard shortcuts -> move window to workspace 1 -> Super-F1 Actual results: the modified keystroke will not register. Expected results: I expect "<mod4>F1" instead of "Super_L" as the keybinding. Additional info:
I don't know of a GNOME change, it could be an X change. What is the full output of "xmodmap" and what is the output from "xev" if you type only the windows key, and the windows key plus F1. control-center maintainers may know of a relevant gnome change.
I'm seeing this same problem in FC4t1, but I'll supply the requested information to help anyway. :o) 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_L (0x7d), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) xev windows key only: KeyPress event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159802320, (-7,-67), root:(782,616), state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159802539, (-7,-67), root:(782,616), state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: Windows + F1: KeyPress event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159804390, (-7,-67), root:(782,616), state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159804560, (-7,-67), root:(782,616), state 0x40, keycode 67 (keysym 0xffbe, F1), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159804654, (-7,-67), root:(782,616), state 0x40, keycode 67 (keysym 0xffbe, F1), same_screen YES, XLookupString gives 0 bytes: KeyRelease event, serial 29, synthetic NO, window 0x2800001, root 0x58, subw 0x0, time 159804905, (-7,-67), root:(782,616), state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes:
*** Bug 153260 has been marked as a duplicate of this bug. ***
Some additional info: - the same seems to be happening also with FC4 - one problem seems to be that X/gnome thinks Super_L is on 0x7f when it is on 0x73 (see 115 in xev output above) - adding 0x73 works in the sense that it shows up in xmodmap output but for some reason it is ignored when I try to use it. More specifically, when I try to bind it using "keyboard shortcuts", it gets added in the display but when I try to use the key combination nothing happens. Similarly, trying to use the modifier key in emacs has no effect. - I tried using mod3 instead, which helps with emacs, where the key seems to be interpreted as super (I get "s-a" etc. when testing with ctrl-h). It does not make any difference when trying to modify gnome shortcuts, i.e. it shows up in the list as e.g. "<Mod3>l" but when I press the keys nothing happens.
I am experiencing this same thing for FC5T2.
Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you!
(Reporter moved bug to FC5. Thanks!)
(Clearing needinfo bit.)
I think this is a duplicate of Bug #139167, though I'm not sure that control-center is the root of the problem. I sometimes get the same behavior while using just Fluxbox, and othertimes (just by logging out, then logging in again) it works correctly. I used xbindkeys to show my keystrokes when it was broken, and when it was working correctly. Here's what happened when I pressed Mod4+z: When it was working: "NoCommand" m:0x40 + c:52 Mod4 + z "NoCommand" m:0x40 + c:115 Mod4 + Super_L When it was broken: "NoCommand" m:0x0 + c:52 z "NoCommand" m:0x0 + c:115 Super_L
when the HELL is this EVER going to get FIXED? There's bickering and workaround and patch and whatnot galore at http://bugzilla.gnome.org/show_bug.cgi?id=165343 and seemingly no end of people that care about this issue. On fedora/ubuntu/gnome/usability bugzillas it's been reported over and over as evidenced by the many duplicate bug pointers. I created this instance of the bug report nearly TWO YEARS AGO and it's assigned and I keep getting mail about it and where is the progress? What's the point, really, of reporting bugs when they never get fixed?
*** This bug has been marked as a duplicate of 139167 ***