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

[Bill Spitzak]

On 11/13/2014 03:30 AM, Daniel Stone wrote:

>     But no, because, when the focus isn't switched, there is no enter
>     event and no keys array. The client has no idea X was pressed, so it
>     can't possibly trigger the binding.
>     So without the patch this is not consistent. Depending on whether the
>     compositor binding switches the focus, the client binding works or it
>     doesn't work.

I agree it is not consistent, but the proposed patch fixes the 
consistency "backwards". It must be fixed instead by changing the 
behavior when the focus does not change. The behavior when the focus 
does change is correct.

> A problem we can solve by switching the focus. ;) I agree that it's
> annoying to always do this for every hotkey, so we could introduce a new
> wl_keyboard::leave_temporary which would inform the client that it's
> about to get another enter event very shortly, but shouldn't redraw
> itself insensitive or anything.

I don't think it has to be anywhere near as complicated. Instead the 
compositor sends an extra focus-in event after handling the shortcut.

In the Alt+X compositor shortcut example:

When Alt is pushed the compositor records this in it's own keymap, but 
also sends the event to the focus client, which records it too.

When X is pushed, the compositor updates it's map with the X down and 
realizes that it got it's shortcut. It then handles it and does *not* 
send the key-down event to the client. Instead it sends an extra 
focus-in event to the client, with it's current keymap. The client then 
updates it's keymap and knows that Alt and X are held down.

If Alt or X are released, the key-up events are sent to the client so it 
can remove them from it's key map.