[PATCH weston v3] input: don't send to clients key events eaten by bindings
ppaalanen at gmail.com
Wed Nov 12 23:35:28 PST 2014
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
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
> 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
More information about the wayland-devel