Recently, I believe after upgrading my Xlibs package to 4.3.0.dfsg.1-4 (I think this is the version which exposed the problem), my keythemerc has been acting very strange, and I've had to turn it off because the way the bug happens is very frustrating. My keythemerc is set up so that I can switch workspaces and exec programs using either super (windows key) or alt as modifiers.. For example, if Super+l is set to run xflock4, and I type an L at any time, my xflock4 will be run, regardless of the status of Super. I've tried messing with xmodmap to fix this, here is how I'd tried: $ for i in `seq 1 5`; do xmodmap -e "clear mod$i" ; done $ xmodmap ~/.xmodmap $ cat .xmodmap add Mod1 = Alt_L Alt_R add Mod4 = Super_L Super_R !keycode 0x73 = Super_L !keycode 0x74 = Super_R here is a keythemerc snippet which seems to show the problem. note that if one were to switch Super for Mod4 (which happens to work in xbindkeys and windowmaker for the same function), the behavior would still be present. workspace_1_key=Super+1 ... shortcut_2_key=Super+Return shortcut_2_exec=xfrun4 I love your WM, but this is very frustrating, and I just don't know how to approach fixing it, so any insight you can provide would be appreciated. Thanks!
Additional information: Debian Sid ii xlibs 4.3.0.dfsg.1-6 ii xfwm4 4.0.6-1 xmodmap: shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), BadKey (0x7d), BadKey (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 BadKey (0x7f), BadKey (0x80) mod5 Mode_switch (0x5d), ISO_Level3_Shift (0x7c)
I'm getting the same behaviour on my Gentoo box after having upgraded from 4.0.6 to 4.1.99. It rules out external libraries as a cause, then.
That's odd. From GTK apps (either xfwm4 shortcut editor or gnome-keybindings-properties), my "windows" key is seen as Super_L or Super_R. It is not seen as a modifier. If I edit the keythemrc by hand and specify "Mod4", then the windows keys works just as expected. 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)
Well, it seems sort of like xfwm 4.1 fixes the problem somehow -- I upgraded from the version that was in debian when I reported the bug to the packages available from http://www.os-cillation.de/debian -- they seem to be working just fine, and I'm really loving the xinerama support. So, I'm not sure if you should mark this fixed or what, but it worksforme. I mostly just wanted someone to be aware of the problem, in case it was a more common problem than just affecting me. See comment #1 for my original xmodmap output. This is xmodmap from today. I'm not sure if it was a bug in X that only affected xfwm (I think I had noted that wmaker still worked okay). In any event, it now matches Oliver's. I just tested, and everything is fine. I had switched to using xbindkeys for a while, and I think I'll leave it that way, since if I ever decide to quit using xfwm, heaven forbid, I'll keep my global keybindings. 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) Worksforme? Leave this open and see if it's affected anyone else? I dunno.
Original reporter declared this fixed 8 months and two major revisions ago. Closing