Comment 156 for bug 1245473

(In reply to comment #80)

Ok, I try to answer here, but I should note that I don't remember full details
(because it was more than half a year ago).

> 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.

I do not agree. You do not need to know/guess which modifiers to set - whenever
ISO_Next_Group is pressed I just don't execute it immediately but delay it till a key release (by the means of _XkbNextFreeFilter()/_XkbApplyFilters() ). Btw, that trick was suggested by Daniel Stone (somewhere on the mail list).

And I want to note that where I comment ":KLUDGE:" I mean a different thing: in theory that branch of code should do the same thing as the switch in XkbHandleActions() ; but, in practice I see (and want) only XkbSA_SetMods action (so kludge here is copy-n-paste from XkbHandleActions() ).

> >
> > 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.

(do not understand properly the above, sorry) The only situation the patch fails
(just behaves old way, and nothing more!) is when switching is set up as just one key like "Right Alt". That is because of the line
   fake_state.mods = 0;
, mods here is 0 anyway => we can't block XkbSA_LockGroup .

Anyway, nobody wants more,- but only (de facto standard) Ctrl+Shift and Alt+Shift on release. I think this is the situation where the practice begins and the theory ends.