[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