Bug 7430

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.