[PATCH] xkb: Do not use base group as an array index.
Peter Hutterer
peter.hutterer at who-t.net
Thu Dec 20 19:03:14 PST 2012
On Thu, Dec 20, 2012 at 11:47:32AM +0100, Andreas Wettstein wrote:
> > 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.
thanks, verified (didn't crash, but out of bounds for sure)
> > 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.
I suspect the reason is to avoid triggering passive grabs when caps lock is
on. If you have a grab that should trigger on, say, shift W said grab should
probably not trigger if you have caps lock on and hit W.
merged the patch, thanks.
Cheers,
Peter
More information about the xorg-devel
mailing list