Comment 33 for bug 36812

--- Introduction

I'd like to discuss this problem in more detail and hopefully add some ideas. For the sake of concreteness, I'm mostly discussing the "Alt+Shift bound to layout switch and preventing other Alt+Shift keyboard shortcuts" case.

After some research, I have the feeling that the problem is in the XKB protocol itself and not in its implementation, which just correctly adheres to a deficient specification. It is the XKB protocol that needs to be extended to properly cover the requested behaviour. Seems to me that currently one can bind actions only to keypresses (please correct me if I'm wrong).

Admittedly, the fix is non-trivial. But it would be worth it; the current behaviour is clumsy and limiting and (as has been said before) e.g. disallows the use of "Alt+Shift+Tab" shortcut, commonly used to switch among open windows, when "Alt+Shift" is used to switch between layouts (that's actually how I found this bug - searching why Alt+Shift+Tab doesn't work).

--- Definition of "multi-key-press-release sequence"

Definition: A "multi-key-press-release sequence" (MKPR seq. for short) is a sequence of key presses and key releases occuring on a keyboard. It begins and ends with all keys on keyboard up. During the sequence, there must always be at least one key down.

--- The desired behaviour - the simple case with two layouts

Initial state: no key is pressed on the keyboard, two layouts are set in the X server (us,cz), layout "us" selected (locked)

The user's intention: to select (lock) the "cz" layout

Action taken - a four step MKPR sequence:
1) press (and hold) Alt 2) press Shift 3) release Shift 4) release Alt

The expected behaviour/response: The release of all keys (i.e. step 4) would trigger the selection (and locking) of "cz" layout.

Current behaviour/response: The layout gets changed after step 2). Moreover, XKB then somehow forgets that Shift is still held down and acts as if only Alt was held down. This precludes even the reachability of any shortcut containing "Alt+Shift" combination.

Note on expected behaviour/response: If any key other than Alt or Shift is pressed during the time when Alt was held down, no layout change should occur. In other words, pressing any other key than "Shift" or "Alt" would completely disqualify the MKPR sequence being formed from being a candidate for layout switching.

--- Slight extension

Consider this MKPR seq.:
1) press and hold Alt 2) press Shift 3) release Alt 4) release Shift

That should switch the layout too, as well as this other two possibilities:

1) press and hold Shift 2) press Alt 3) release Alt 4) release Shift

1) press and hold Shift 2) press Alt 3) release Shift 4) release Alt

Unsure: What about the following MKPR seq?

1) press and hold Alt 2) press Shift 3) release Alt 4) press Alt 5) release Shift 6) release Alt

Should this do something special? (probably not, maybe it should not do anything at all)

--- What if there are more than two layouts (e.g. 4 layouts?)

It would be IMHO practical, if the switching among layouts with Alt+Shift could work similarly as Alt+Tab switching between windows in XFCE/GNOME/KDE etc., i.e. there would be some internal recency list, enabling to quickly switch between two most recently used layouts. I.e. press and hold Alt and then press/release Shift multiple times to walk through the possible layouts list, ordered by the time they were last used (more recent first). Release of Alt would then mean "switch to the selected layout". Pressing Esc (or any other key) during the hold of Alt would mean "cancel the switching, leave the current layout".

How would the user be notified about the currently selected "candidate" for switching to during the selection? One possibility is e.g. showing the "layout candidate" in notification area (interaction with desktop environment required).

--- Conclusion

To sum things up, it would be great if the XKB could be extended to cover the notion of "multi-key-press-release" sequence and its use as a trigger for (e.g.) changing keyboard layout.

The "recency-aware" layout switching among more than two layouts seems to me as a good idea also.

--- REFERENCES, some starting points for XKB hacking

http://www.xfree86.org/current/XKBproto.pdf - The XKB Extension: Protocol Specification
http://www.xfree86.org/current/XKB-Config.html - How to configure XKB

/usr/share/X11/xkb/symbols/group - this is the file where e.g. "Alt+Shift" layout switching is defined, namely this part

** beginning of excerpt

partial modifier_keys
xkb_symbols "alt_shift_toggle" {
    virtual_modifiers Alt;
    key <LALT> {
 symbols[Group1]= [ NoSymbol, ISO_Prev_Group ],
 virtualMods= Alt
    };
    key <RALT> {
 symbols[Group1]= [ NoSymbol, ISO_Next_Group ],
 virtualMods= Alt
    };
    key <LFSH> {
 type[Group1]="PC_ALT_LEVEL2",
 symbols[Group1]= [ Shift_L, ISO_Prev_Group ]
    };
    key <RTSH> {
 type[Group1]="PC_ALT_LEVEL2",
 symbols[Group1]= [ Shift_R, ISO_Next_Group ]
    };
};

** end of excerpt

Some useful commands:

"setxkbmap -option" clears all options
"setxkbmap -v 10 -layout us,cz -option grp:alt_shift_toggle" - setup two layouts, with alt+shift switching between them
"setxkbmap -print -v 10" - print current XKB settings

Try to change e.g. "Shift_R" to "A" in the above mentioned part of /usr/share/X11/xkb/symbols/group, save and then run "setxkbmap us,cz -option grp:alt_shift_toggle" - right shift then should produce the letter "A".