[PATCH weston] input: don't send to clients key events eaten by bindings

[Bill Spitzak]

On 10/08/2014 11:58 AM, Giulio Camuffo wrote:

>> A key being held down on focus-in will not produce a "press" event, so I
>> don't see what the problem is.
>
> It produces a KeyPress in xwayland.

Okay that may be a problem. So you are saying the client cannot 
distinguish between keys that were held down when it got the keyboard 
focus, and ones that were pressed a very short time afterwards?

I was under the impression that what the client got was an xkb state 
that showed that the keys were held down. Actual events caused by 
pressing keys were different and distinguishable by the client.

>> If a client wants to check if X is held down I think the user expects it to
>> work even if it was held down as part of the command to switch windows.
>> Therefore I think the current behavior is correct.
>
> Why would it care about that? The compositor decided that the clients
> shouldn't know that one key was pressed, so the client's shouldn't
> know that. If some client gets to know that it's a bug.
> Or else you should say that key bindings should always let the events
> pass to clients. Are you saying that?

No. All I want is the client to know the current state of the device, 
including the actual state of the keys. They should not see the keypress 
any more than if the key was pressed in a different client and held down 
until the focus switched to this one.

The most obvious one clients want are shift keys. If I type Alt+tab to 
go to a different client and keep holding down Alt and type 'x', the 
client should act like I typed Alt+x.

Yes I know this works because the modifier bits are being treated 
differently than the key map. However I don't think that should be 
special. What happens if everybody starts treating hold-down-space as a 
modifier (this actually has some precedence in Photoshop and lots of 3D 
software)?