> is there some sort of test-case that triggers this issue reliable?
I found it when I tried:
key <FK07> {
type= "ONE_LEVEL",
symbols[Group1]= [ NoSymbol ],
actions[Group1]= [ LatchGroup(group=-1, clearLocks) ]
};
and then hit F7. Using SetGroup(group=-1) should "work" equally well.
> also, why do we ignore locked groups here? It'd be great to have some
> explanation, this is code that hardly anyone knows inside-out, so having
> this in the commit message would help a lot.
Actually, at first I fixed the crash using the effective group. But
then I found in section 2.3.1 of the X Keyboard Extension Protocol
Specification:
If the IgnoreGroupLock control is set, the locked state of the
keyboard group is not considered when activating passive grabs.
I believe that this is what this piece of code is about, and I think my
choice is as close as possible to this description.
And what is the idea behind the specification? Probably, the idea is
that users switching between two distinct two-level layouts (such as us
and ru) using a lock can have that lock partially ignored, while users
using a single three level layout implemented using two groups (for core
protocol compatibility) will not get Mode_switch ignored, which makes
sense, as it actually selects symbols of the same layout.
Regards,
Andreas
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
