Comment 155 for bug 1245473

The following comments were made by Peter Hutterer (an X.org input developer) on the corresponding bug in RedHat bugzilla ( https://bugzilla.redhat.com/show_bug.cgi?id=660254 ):
(In reply to comment #6)
> implementing this behaviour requires guesswork that I'm not sure is safe in a
> number of setups.
...
> afaict, the desired behaviour for a ctrl+shift groupchange is:
> ctrl down → set Control modifier
> shift down → set Shift modifier
> if (other key pressed)
> send event Contrl+Shift+<other key>
> else if (ctrl || shift released)
> change group
>
> The XKB map for left control in this case is:
> key <LCTL> { [ Control_L, ISO_Next_Group ] };
> So whenever ISO_Next_Group is pressed, you still need to know which modifier to
> set in case the group action isn't executed. The XkbSA_SetMod, XkbSA_LockMod,
> etc. actions provide the modifiers set for a given key, hence why it works
> currently. This information comes from the client when the xkb map is loaded
> and is used to trigger the modifier flags for a given key. The XkbSA_LockGroup
> behaviour (which is triggered at ISO_Next_Group) does not have this field
> (adding it would break ABI), so you need to guess which modifiers to set if you
> didn't trigger this action. This is the main stumbling point that I found and
> if you look at Ilya's patch that's where he needs the big hack that I'm not
> comfortable at all with it.
>
> Now, I don't know if there are layouts where the modifier mask would be
> different on the second level as opposed to the first (and Ilya's hack or a
> similar attempt would fail completely) but there's so many layouts that it'll
> take a while to get through them all.

Ilya - this is hardly my area of expertise, so if you can address these issues - either by commenting here, on the RedHat bugzilla or by changing the patch - I would greatly appreciate that.

Thanks to all the people who are involved, and lets keep the communication channels open :-)