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

[Pekka Paalanen]

On Wed, 12 Nov 2014 12:06:16 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> The important point is that in both your and my case the client that has 
> just received focus sees the 'd' as being held down. The 'd' is on in 
> the key-down array attached to the focus-in event!!!!

Correct. Apparently X apps interpret a "key already down" the same way
as a "key goes down" event. That is not a Wayland issue at all.

> Apparently if Ctrl+D was a "compositor shortcut" to close a window, then 
> this patch will cause the 'd' to not be there. But since Ctrl+D is 
> handled by a client to close the window, the client with the new focus 
> *does* see it. WHY IS THIS DIFFERENT??????

Because when you hit a compositor hotkey, that final key-press in the
combination must not be sent to any client at all. Otherwise there
would be two consumers of the same event: the compositor and a client.
This would lead to duplicate action, which is not wanted for obvious
reasons.

If a key combination is not a compositor hotkey, also the final
key-press event is directed to exactly the one client with the keyboard
focus.

> IMHO they should not be different, therefore this patch is wrong. There 
> are two possible solutions:
> 
> 1. Revert it. The actual bug is that a client that already has focus 
> before a "compositor shortcut" will not get any changes to the keymap. 
> Add something to fix this instead. I recommend a redundant focus-in event.
> 
> 2. Always send a blank key-down array in the focus-in event, since it is 
> possible that any key held down was the "shortcut" that caused the 
> focus-in event.

No, we are not going to break the Wayland core protocol. Also, I do not
see a problem with the current behaviour.

We are not going to screw up Wayland just so that X apps in Xwayland
would work "better" for some cornercases.

Instead, we fixed Weston to act consistently, which corrected the
original problem.


Thanks,
pq