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

[Bill Spitzak]

On 10/10/2014 11:41 AM, Giulio Camuffo wrote:

> Ok, so let's change the example. Space doesn't switch the active
> window, but toggles the speaker mute. So hitting space will not send a
> key event to the client, which will not know space is pressed, so your
> nice space+x shortcut won't work.

Yes this is what I am trying to fix. These is a much better example 
because it does not confuse things with focus changes, and also makes it 
more obvious where the error is.

The desired result is that the user presses space and the speaker turns 
off. If they continue to hold down space and type 'x' then the client 
should act exactly like it is supposed to for the space+x shortcut. If 
it acts like 'x' without the space this is a serious failure to deliver 
expected results for the user.

The client will do some kind of check to see if the space key is down. 
This should resemble as much as possible a round trip to actually see if 
the key is pressed on the hardware. I figured this involved peeking into 
the xkb structure to see what keys are held down.

But with the current design of the xkb interface this is going to return 
false, as changing the key-down map apparently is tied directly to key 
press/release events and to the focus changing events. There is no way 
to send changes to the key map without also sending one of these events. 
This needs to be fixed.

I now think what happened is that somebody realized that a focus-change 
would fix this bug (since it sends the updated key pressed map to the 
client as a side-effect). However the patch is exactly backwards, it is 
trying to break it in the one case where it works correctly!