Comment 203 for bug 36812

As far as I can tell, it is already clear that XKB specifications needs to be extended for this to be cleanly solved. While Ilya's hack works for many people, and as much as I would like to see this fixed, I understand why it is unacceptable to the developers. So, trying to delve into XKB specs now; this page seems to be a good starting point to me:

https://wiki.archlinux.org/index.php/X_KeyBoard_extension

Also (as suggested by the author), copying info here from https://bugzilla.redhat.com/show_bug.cgi?id=660254

Peter Hutterer 2011-01-05 22:07:57 EST

there is two problems with the "tiny" patch you mentioned. one, it's an _explicit_ violation of the XKB specification (see section 4.4). two, implementing this behaviour requires guesswork that I'm not sure is safe in a number of setups.

Peter Hutterer 2011-01-06 17:12:05 EST

(In reply to comment #4)
> But: doesn't fixing of a huge problem have a priority over preservation of a
> "holy spec"?

it's a matter of figuring out the side-effects. a specification is a behaviour promise, in this case in place for 15 years or so. a lot of users and apps rely on the promised behaviour (in general, not necessarily this specific issue) and breaking it is a dangerous thing because you may not know what else you break.
this is why we're hesitant to break the behaviour on purpose.

note that i'm not claiming that there is no problem, i'm just saying it's the balance between a known problem and introducing new bugs that potentially break current applications.

> > two,
> > implementing this behaviour requires guesswork that I'm not sure is safe in a
> > number of setups.
>
> What guesswork do you mean? Which setups can present problems?
> BTW, I'm 100% sure that Ilya Murav'jev (patch author) will be glad to
> cooperate.

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.

> And leaving the design bug because of purist reason looks really strange...

there's two-ish ppl working on input at them moment, both are badly overloaded because there's a lot of bugs and plenty new features that ppl cry out for. so this bug has less to do with purist reasons, it's more along the lines of "i've got so many things to do that don't break the spec, they get priority".