First of all I am running Debian sarge 3.1 with following XFree86 version: XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-10 20041215174925 fabbione@fabbione.net) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.26 i686 [ELF] Build Date: 15 December 2004 I ran into trouble with Xfwm4 4.0.6 because my so called windows key (Super_L) doesn't work. I used several hours and tracked the problem down to keyboard.c function "void initModifiers (Display * dpy)". The problem is that function "XKeysymToKeycode" returns keycode values that are only valid on US keyboard and I'm using Finnish keyboard layout. So at least modifier key Super is pretty much useless. I upgraded to Xfce4 4.1.99.3 newest release candidate (Xfce 4.2 RC3) and can fully reproduce the problem. In addition to that, the Window Manager preferences in the new version don't work the right way. If I want to bind a key to ie. changing of workspace and the dialog window opens, when I press my Super_L button the dialog immediately closes and I don't even have time to press another button in addition to the modifier! This is probably also because of wrong SuperMask in keyboard.c (the mask is 0 because the modifier key is not found). Now, other window managers I've used use Mod1, Mod2, Mod3, Mod4 and Mod5 for binding the modifiers and I don't understand why Xfwm is working differently. I'm sorry if it sounds rude but I think it's stupid to just ignore xmodmap settings for modifiers. I've also tried to fix it the other way using XKeycodeToKeysym and compare keys in keyboard.c initModifiers function but my X server still uses US keyboard variables to make the conversion and I very much believe they are hardcoded to the X server. (Haven't checked yet) Now I could make a patch that removes all references to current AltMask, SuperMask etc. and changes them to use Mod1Mask, Mod2Mask, Mod3Mask etc. However before I do any work I would like to hear developers' opinion about this whole situation. Right now I'm using the following patch which you can find from the URL section and edit the modifiers to the keythemerc manually. I think this bug is critical enough to be included in the final Xfce 4.2 version and I hope you could at least include my quick fix. Also I believe the bugs 288 (http://bugzilla.xfce.org/show_bug.cgi?id=288) and 520 (http://bugzilla.xfce.org/show_bug.cgi?id=520) are related to this bug. Notice that upgrading to the latest version doesn't fix this problem. I'm eagerly waiting for comments, this is a good piece of software and this kind of bugs are really annoying. I also don't want to patch myself every time there's a new release of Xfce. Juho Vähä-Herttua
Created attachment 143 Quick fix for Mod-keys on Finnish keyboard Added my quick fix as an attachment as it should be and not an url as earlier.
Your patch is not correct. Removing keynames is not the way to go. Your problem comes from the fact that the Super_L and Super_R aren't set as modifiers. Create a $HOME/.Xmodmap file and put this keycode 115 = Super_L add Mod4 = Super_L keycode 116 = Super_R add Mod5 = Super_R Then load it with "xmodmap $HOME/.Xmodmap" and use Super_L and Super_R as keynames in your keyboardrc definition. That should work. The problem with other bug reports is that GTK seems to report Mod4 and Mod5 even if keynames are set to Super_L and Super_R, and the keyboard shortcut editor does not report the correct keyname. In a nutshell, I'm yet to be convinced it's a bug with xfwm4.
I forgot to attach my xmodmap output in the first post. Before doing anything (when it doesn't work) my xmodmap output is following: juhovh@enlightened:~$ 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) After adding the .Xmodmap you suggest the xmodmap output is following (as suspected): juhovh@enlightened:~$ 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), Super_R (0x74) And third one after the second one: juhovh@enlightened:~$ setxkbmap fi juhovh@enlightened:~$ 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) Ok, I admit I should've realized from the beginning that adding an additional Super_L with keycode 0x73 to the xmodmap will do the job, because after this the XGetModifierMapping will report 0x73 as mod4 and then mod4 will be marked as SuperMask. However I definitely don't agree this is a right solution, because as you can see, setting the modmap to Finnish keyboard layout brings us back to the problem that Super_L is 0x7f. In bug 288 the last message he seems to get it work with 0x7f, I don't have explanation why this works with him and not with me, I just know the XKeysymToKeycode returns wrong keycode for my keyboard. Also I believe my patch is correct. I've understood that the Mod4 has always the modifiermask 0x40, because the modifiermask is a 8-bit mask where bits are in order: Mod5, Mod4, Mod3, Mod2, Mod1, Control, Lock, Shift. Anyway, I see no point in first modifying my xmodmap to map keycode 0x73 to Shift_L, then include Shift_L to Mod4, after that let xfwm4 read keycodes of Mod4 and compare them to Shift_L hardcoded in X server (0x73) and decide that SuperMask is the same as Mod4Mask (1<<6) and then read Mod4 from keythemerc and then set it to SuperMask. When it can set the Mod4 directly to Mod4Mask and I don't have to mess up my xmodmap. Now to conclude this all, I agree that your solution fixes the problem (but only if I put 'xmodmap /home/juhovh/.Xmodmap' to .xinitrc before 'xfce4-session' because otherwise Finnish layout overrides it), but I don't agree that it's not a problem of xfwm4. Thanks for your time and let me know if I have some facts wrong, I just want a satisfying explanation. ;) HTH, Juho
Sorry, I indeed misread your patch. It's clear that it shoudln't hurt so I have no objection in including it.
The problem I see (not related with your patch) is that the shortcut editor (using GTK+) gives keynames taht don't match. For example, the shortcut editor doesn't see Super_L and Super_R as modifiers while the WM correctly treat them as modifiers. I don't know if that problem lies in gtk.
Did you try with xev to get the keycode? Here the windows key gives : KeyPress event, serial 31, synthetic NO, window 0x1c00001, root 0x8f, subw 0x0, time 9526644, (59,131), root:(63,183), state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False And 0x73 = 115, not 7F. Therefore the Windows key is 0x73 definitely not 0x7F.
Now this starts to get more clear, xev actually tells me it's 0x73 so it's the debian keymap that is a problem in the Super_L case, I thought I already checked this but apparently not, sorry for that. I still don't quite understand why default keymap for Finnish keyboard is using wrong keycodes in debian and why Shift_L was correctly marked as Mod4 in events although the keycode wasn't the same as in xev. Also I'm very curious to know where that XKeysymToKeycode gets its mappings if it's not the keymap loaded with setxkbmap, but it's not related to this bug any more and I'll find it out myself. My earlier window managers have just used ModX modifiers so I haven't had problems with this, I also used Gnome for a while and it worked well so I'm not sure how it handles the keys. I'll install the newest version of Xfce4 permanently tomorrow and check how it acts with correct modmap in the shortcut editor. I still think the patch is ok since I think it's a good idea that Mod4 really is modifier 4 as in events from the server and not the modifier number of Super_L or Super_R. And it seems you already included it in the CVS. But otherwise this looks very promising, I'll keep xfce as my default desktop and see if something else comes up. Thank you for very fast reply and great help in solving this. Good luck with year 2005 and Xfce 4.2. Juho
Default to 0x7F for French keyboard on Fedora too, so it's not a Debian/Finnish issue. Please note that fix won't be in 4.2.0 unless you can convince Benny to move the tag.
Today I finally sent mail to Benny and he moved the tag so it's now included in 4.2.