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

[Bill Spitzak]

On 11/21/2014 10:30 AM, Daniel Stone wrote:

> As in the first quoted section, I think it's not really reasonable to
> guard against the possibility of Mod+S taking a screenshot in the
> compositor, but the client having a shortcut for Mod+S+X. So I think we
> can take the easy way out of saying:
>    - for any hotkeys which are _solely_ combinations of modifiers and
> _not_ non-modifier keys (e.g. Exposay as it is today), then we only take
> action on release

I did think of one annoying conflict. My initial worry seems to be ok 
provided clients are well-behaved, but a more obscure problem with key 
release order does exist. I will try to describe it:

Imagine the server has Shift+Alt as a shortcut, and a client just has 
Shift as a shortcut. Both of these adhere to convention and do not 
trigger the event unless they see the *up* event.

Then the following happens:

1. Shift down -> sent to client
2. Alt down -> sent to client
3. Alt up -> triggers shortcut, send updated keymap to client
4. Shift up -> ??? this should not trigger event in client

At first I thought this might be a big problem, but I now think it is ok 
if the shift-up is sent to the client. This should not trigger the shift 
event because the Alt key was pressed and the client saw that. If the 
client did respond to the shift-up then it can be considered a client bug.

Then I realized that steps 3 and 4 above (the release events) could be 
swapped. This should still trigger the server shortcut and avoid 
triggering the client shortcut. This is only going to happen if 
everybody agrees on which up event is the triggering one. Unfortunately 
there are different implementations:

1. The first up is the trigger
2. The up corresponding to the last down is the trigger
3. The last up (ie when all modifiers are released) is the trigger
4. others I did not think of...

It looks like all wayland clients are going to have to agree on the 
rules. Otherwise the compositor will not "eat" the event that the client 
uses as the trigger. I get the impression that #2 is the only scheme 
that will work, but I have not been able to convince myself of this yet. 
It may also be useful to try existing software, especially on Windows 
where this use of modifiers as triggers is more common, to see if there 
is any standard.