From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko) Description of problem: On Xorg the Win keys are not recongnized as modifiers anymore. The ouput of xmodmap clearly states that mod3 is not defined. xmodmap: up to 2 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) mod2 Num_Lock (0x4d) mod3 mod4 mod5 Scroll_Lock (0x4e) I tried searching this problem on Google and indeed I found it mentioned by other people but the patch that supposed to fix does not work for me. The bug (and the patch) is listed on: http://freedesktop.org/pipermail/xorg-bugzilla-noise/2004-May/000443.html Version-Release number of selected component (if applicable): xorg-x11-6.7.0-2 How reproducible: Always Steps to Reproduce: 1. run xmodmap Actual Results: See that there is no mod3 key defined.
Created attachment 100324 [details] Patch /etc/X11/Xmodmap to set Win keys as modifiers (mod4)
Correction, I meant mod4 in the previous message not mod3. Anyways I put up a patch (see the attachement above) for /etc/X11/Xmodmap that enables the Win keys. I know that /etc/X11/Xmodmap belongs to xinitrc and not xorg but I still believe that the bug comes from the xorg-x11 package. So, all Fedora Core 2 users who want to use Win keys as modifiers are encouraged to patch /etc/X11/Xmodmap as a workaround until another fix is available for xorg.
I have a similar problem - but the initial xmodmap output is different: This is what I get after login: [jtl@coltrane jtl]$ xmodmap 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) funny thing is the 0x7f == 127, while xev tells me when pressing the "Windows key": KeyPress event, serial 25, synthetic NO, window 0x2c00001, root 0x48, subw 0x2c00002, time 2125506, (53,41), root:(58,88), state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Note the 115 == 0x73 Now, if I just do only this: [jtl@coltrane jtl]$ xmodmap -e "add mod4 = Super_L" everything starts to work, as can be seen from xmodmap output below: [jtl@coltrane jtl]$ xmodmap 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), Super_L (0x73) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Note the double Super_L key for mod4 now!
Just ran: xmodmap -e "add mod3 = Super_L" And my Win key is available again. Finally, I can switch Desktops the way I meant them to be switched!
Travis, could you please provide us the output of "xmodmap" before and after running your fix ?
This is from another computer sufferring from the same problem: 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) After running xmodmap: 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 Super_L (0x73), Super_L (0x7f) mod4 Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Now, you want a real kick in the butt? I got the same results - mod3 was mapped to Super_L on my home computer and I could map it to a shortcut via KDE Control Center. With the shortcut mapped, it wouldn't work though. Here at the office, I just went through the same procedure and my shortcut works. Hmm... go figure.
I have the same problem in FC2: xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_L (0x42), 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) In FC1, there used to be 0x73 instead of 0x7f and I could use the Win key for mapping. Here is the output from FC1: xmodmap: up to 3 keys per modifier, (keycodes in parentheses) shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x6d), Control_L (0x42) mod1 Alt_L (0x40), Alt_R (0x71) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_R (0x74) mod5 What is the meaning of the 0x7f in FC2 (where does it come from)? Probably whoever sets it should set it to 0x73.
Created attachment 100534 [details] Enable win keys as modifiers If you apply this patch to /etc/X11/xkb/symbols/pc/pc you will be able to use the Win keys as modifiers exactly as in Fedora Core 1. What this patch does: - removes the old keysyms : Super_L (0x7f), Hyper_L (0x80) - adds the right keysyms as Mod4: Super_L (0x73), Super_R (0x74) I am really curious why setting the default values for Mod4 to 0x7f and 0x80. Anyone has any use for them this way ?
Please, see http://freedesktop.org/bugzilla/show_bug.cgi?id=587 for an alternative solution I'm using to fix this annoying problem on Fedora Core 2 with a pc105 keyboard.
The freedesktop.org bugzilla seems to be currently unavailable, at least from my system. I'll try again later.
Ok, I've CC'd myself on the upstream report and will track this in the freedesktop bugzilla. Thanks for the URL. Setting tracking state to 'UPSTREAM'