This is a copy of a bug that I originally reported against gnome-keyboard-properties, but I was told to report it here instead: http://bugzilla.gnome.org/show_bug.cgi?id=346029 Sorry for taking so long to repost it here. Short summary: - Adding a new keyboard layout in the Keyboard Preferences (g-k-properties) automatically activates the option "Both Alt keys together change group" without notifying the user. - An unwanted side-effect of this option is that it breaks the "Alt" keys. The KeyPress events are sent correctly, but the KeyRelease events for Alt are mapped to the wrong key. As a result, many applications do not detect that Alt has been released. Similar problems occur if the options "Both Shift..." or "Both Ctrl keys together..." are selected. However, these options have to be activated explicitely so they are probably not affecting many users. System information: - Laptop (HP/Compaq nc8000) running current Debian testing ("etch") - GNOME 2.14.2 - X.Org 7.0 - The problem occurs with the built-in keyboard (US layout) as well as any external keyboard. - Keyboard model in g-k-p: Generic 104-key PC. - Selected layouts in g-k-p: U.S. English, Belgium, Sweden. Steps to reproduce: - If possible, start with a new user account or a clean session. - Run "xev" or a similar X event monitoring application and verify that pressing and releasing the left Alt key generates KeyPress and KeyRelease events associated with the Alt_L key. - In "Layout Options", "Group Shift/Lock behavior", check the option "Both Alt keys together change group" (this is activated automatically after adding a new keyboard layout). - Run "xev" again and see that KeyPress still reports the Alt_L key, but KeyRelease reports another key (in my case, ISO_Prev_Group). - This affects several applications that will be unable to detect that Alt has been released: GIMP (http://bugzilla.gnome.org/show_bug.cgi?id=345726), Inkscape, ... Aggravating factor: the option "Both Alt keys together..." is silently activated automatically after adding a second keyboard layout. Removing the additional keyboard layout(s) does not solve the issue because the option is not unchecked. It was very difficult for me to find the source of this problem because I never looked at the "Layout Options" tab after adding the second and third keyboard layouts and I did not see (for several weeks) that some option had changed there. When I tried to track down this problem, I saw that the bug was still there even after removing the additional keyboard layouts (and thinking incorrectly that I went back to the original state), so I wasted some hours investigating other potential sources for this problem. I am glad that I eventually found it by creating new user accounts, adding panel applets and changing options until the bug appeared again for these clean accounts. Here is some additional details about what I get WITHOUT the option "Both Alt keys together change group": > xmodmap -pke | grep Alt keycode 64 = Alt_L Meta_L keycode 113 = Alt_R Meta_R ISO_Level3_Shift NoSymbol ISO_Level3_Shift keycode 125 = NoSymbol Alt_L > xev [pressing and releasing Alt] KeyPress event, serial 29, synthetic NO, window 0x2e00001, root 0x76, subw 0x0, time 365926274, (162,59), root:(171,454), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2e00001, root 0x76, subw 0x0, time 365926863, (162,59), root:(171,454), state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: And here is what I get later, WITH the option activated: > xmodmap -pke | grep Alt keycode 64 = Alt_L ISO_Prev_Group ISO_Prev_Group NoSymbol ISO_Prev_Group keycode 125 = NoSymbol Alt_L > xev KeyPress event, serial 29, synthetic NO, window 0x2e00001, root 0x76, subw 0x0, time 366201299, (162,54), root:(171,449), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x2e00001, root 0x76, subw 0x0, time 366201775, (162,54), root:(171,449), state 0x8, keycode 64 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES, XLookupString gives 0 bytes: Note that this also breaks the right Alt key, but fortunately I am not using it as much as the left Alt key.
I personally use as default the Alt-Shift combination to switch layouts (untick Alt-Alt, tick Alt-Shift). With this key combination I did not notice any usability issues. Since this issue is being mentioned, should there be a switch for the default key combination (file another report)?
I don't understand the last sentence. What do you mean by "a switch for the default key combination"? Note that with the modern desktops having good panel applets that can both display the current keyboard layout and switch to a different one with a mouse click, I do not think that it is useful to activate any magic key combination automatically, especially not without informing the user. I would not have been hit by this bug if the addition of a second keyboard layout had not caused the automatic activation of the Alt-Alt combination (without informing me about it). But I guess that this should be reported against gnome-keyboard-properties in bugzilla.gnome.org, not here.
(In reply to comment #2) > I don't understand the last sentence. What do you mean by "a switch for the > default key combination"? I mean to "change (to switch) the default combination (Alt-Alt) to Alt-Shift". Windows users have the Alt-Shift key combination as well, so they are bound to be able to press it when they try GNOME for the first time. In addition, some laptop keyboards do not have a second Alt (AltGr) key. > Note that with the modern desktops having good panel applets that can both > display the current keyboard layout and switch to a different one with a > mouse click, I do not think that it is useful to activate any magic key > combination automatically, especially not without informing the user. I > would not have been hit by this bug if the addition of a second keyboard > layout had not caused the automatic activation of the Alt-Alt combination > (without informing me about it). But I guess that this should be reported > against gnome-keyboard-properties in bugzilla.gnome.org, not here. I am not aware of a substantial number of people using the default Alt-Alt combination. Indeed, as you mention, it requires a bug report on GNOME to change this default value. Are there any good reasons to use Alt-Alt instead of Alt-Shift?
(In reply to comment #3) > I mean to "change (to switch) the default combination (Alt-Alt) to Alt-Shift". > Windows users have the Alt-Shift key combination as well, so they are bound to > be able to press it when they try GNOME for the first time. I would also prefer the Alt+Shift combination, although it caused some usability problems because some applications already use Alt+Shift+key shortcuts. See http://bugzilla.gnome.org/show_bug.cgi?id=137428 > I am not aware of a substantial number of people using the default Alt-Alt > combination. Indeed, as you mention, it requires a bug report on GNOME to > change this default value. I just submitted this: http://bugzilla.gnome.org/show_bug.cgi?id=346752 If that bug is fixed, then we would still have the problem described in this bug report: those who choose to activate the Alt+Alt combination would suffer from a broken KeyRelease event, causing problems in some applications.
The problem is that the "Both Alt keys together change group" rule doesn't actually say "the Left Alt key generates ISO_Prev_Group when the Right Alt key is pressed" and vice versa. It says "the Left Alt key generates ISO_Prev_Group when *EITHER* Alt key is pressed", and since the Left Alt key is pressed at the time when you release it, it's interpreted as being ISO_Prev_Group rather than Alt_L. It seems like this ought to be fixable by defining separate virtual modifiers for the left and right alt keys (and similarly in the "Both Control keys..." and "Both Shift keys..." cases), and creating keytypes using those virtual modifiers and having the ISO_Prev_Group/ISO_Next_Group bindings depend on those virtual modifiers rather than the real Alt modifier. I don't understand xkb rulesets well enough to try to test this though.
I just got bitten by this bug, which manifests easily in the GIMP (see the last comments to http://bugzilla.gnome.org/show_bug.cgi?id=457288). I have "Both Ctrl keys together change layout" turned on in gnome-keyboard-properties. As a result, releasing Ctrl doesn't give a keycode of Control_L, but rather ISO_Prev_Group --- thus the GIMP doesn't detect that Ctrl was released, and causes trouble. Raising severity, since this can cause totally obscure bugs like the one above.
Well, I think Dan is right - the only way is to define separate modifiers for left and right alt. But this can raise a hell... I'll try to play with it.
Thanks Sergey! I really don't know enough about XKB to debug this.
Created attachment 11262 [details] [review] Trying to fix alts_toggle by using separate vmods Since alts_toggle is somewhat more important, could please anyone try the attached patch? At the same time, I'll look at the ctrls_toggle.
Created attachment 11276 [details] [review] Updated patch This version of patch have some types renamed. Also, trying to fix Control handling
Created attachment 11313 [details] [review] Updated patch I committed renamed types, so now the patch is much shorter. Could please anyone try it?
One essential note: because of #4927, setxkbmap does not work properly with this configuration. You should use setxkbmap ... -print | xkbcomp - :0. So I cannot commit that patch before that one is fixed (otherwise it breaks alts_toggle switching altogether).
Note that the same problem is with the grp:shifts_toggle setting. If this is enabled the left shift even when pressed alone starts to send ISO_Prev_Group keysym.
Is the workaround in comment #12 (setxkbmap ... -print | xkbcomp - :0) sufficient to fix KeyRelease events? With xorg-server-1.9.0, xkeyboard-config-1.9, libxkbfile-1.0.6, setxkbmap-1.1.0, xkbcomp-1.1.1 I am trying to use grp:ctrls_toggle. The following command does not work, as described in the bug #4927: setxkbmap -layout us,ru -option '' -option grp:ctrls_toggle (left and right Ctrl keys just work as Control, no group switching). Then I try to use the suggested workaround: setxkbmap -layout us,ru -option '' -option grp:ctrls_toggle -print | \ xkbcomp - :0 Now group switching on pressing both Ctrl keys works, but I still have the mismatch between KeyPress and KeyRelease events: KeyPress event, serial 35, synthetic NO, window 0x4000001, root 0x1ad, subw 0x0, time 14483958, (-261,-17), root:(772,789), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 35, synthetic NO, window 0x4000001, root 0x1ad, subw 0x0, time 14484038, (-261,-17), root:(772,789), state 0x4, keycode 37 (keysym 0xfe0a, ISO_Prev_Group), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False Comparing the "xkbcomp :0 -xkb -a" outputs between these setups gives: --- server-0.xkb.bad 2010-09-02 16:47:23.000000000 +0400 +++ server-0.xkb.workaround 2010-09-02 16:48:24.000000000 +0400 @@ -295,7 +295,7 @@ xkb_types "complete" { - virtual_modifiers NumLock/* = Mod2 */,Alt/* = Mod1 */,LevelThree/* = Mod5 */,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr/* = Mod5 */,Meta/* = Mod1 */,Super/* = Mod4 */,Hyper/* = Mod4 */; + virtual_modifiers NumLock/* = Mod2 */,Alt/* = Mod1 */,LevelThree/* = Mod5 */,LAlt,RAlt,RControl/* = Control */,LControl/* = Control */,ScrollLock,LevelFive,AltGr/* = Mod5 */,Meta/* = Mod1 */,Super/* = Mod4 */,Hyper/* = Mod4 */; type "ONE_LEVEL" { modifiers= none; @@ -586,7 +586,7 @@ xkb_compatibility "complete" { - virtual_modifiers NumLock/* = Mod2 */,Alt/* = Mod1 */,LevelThree/* = Mod5 */,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr/* = Mod5 */,Meta/* = Mod1 */,Super/* = Mod4 */,Hyper/* = Mod4 */; + virtual_modifiers NumLock/* = Mod2 */,Alt/* = Mod1 */,LevelThree/* = Mod5 */,LAlt,RAlt,RControl/* = Control */,LControl/* = Control */,ScrollLock,LevelFive,AltGr/* = Mod5 */,Meta/* = Mod1 */,Super/* = Mod4 */,Hyper/* = Mod4 */; interpret.useModMapMods= AnyLevel; interpret.repeat= False; @@ -1206,6 +1206,7 @@ }; key <LCTL> { type= "PC_RCONTROL_LEVEL2", + virtualMods= LControl, symbols[Group1]= [ Control_L, ISO_Prev_Group ], actions[Group1]= [ SetMods(modifiers=modMapMods,clearLocks), LockGroup(group=-1) ] }; @@ -1534,6 +1535,7 @@ }; key <RCTL> { type= "PC_LCONTROL_LEVEL2", + virtualMods= RControl, symbols[Group1]= [ Control_R, ISO_Next_Group ], actions[Group1]= [ SetMods(modifiers=modMapMods,clearLocks), LockGroup(group=+1) ] }; Apparently both LControl and RControl virtual modifiers are mapped to the Control real modifier, and the keysym lookup for the PC_RCONTROL_LEVEL2 and PC_LCONTROL_LEVEL2 types accepts any Control, not just a particular one, even though the same "xkbcomp :0 -xkb -a" output contains: type "PC_LCONTROL_LEVEL2" { modifiers= LControl; map[LControl]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "LControl"; }; type "PC_RCONTROL_LEVEL2" { modifiers= RControl; map[RControl]= Level2; level_name[Level1]= "Base"; level_name[Level2]= "RControl"; }; Should the keysym lookup really work with virtual modifiers this way?
It seems that the bug is still here, but for shifts_toggle, as mentioned on comment #13. Steps to reproduce (tested on Ubuntu 14.04.1, Xorg 1.15.1): 1) Enable shifts_toggle: setxkbmap -option '' -option grp_shifts_toggle 2) Run xev -event keyboard 3) Move the mouse over the xev window 4) Press and release Left Shift: you will get 0xffe1,Shift_L when pressing, and 0xfe0a,Shift_R when releasing. The two keysym codes does not match.
Typo fix: Please read step 4 as: 4) Press and release Left Shift: you will get 0xffe1,Shift_L when pressing, and 0xfe0a,ISO_Prev_Group when releasing. The two keysym codes does not match.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/122.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.