[PATCH weston] input: don't send to clients key events eaten by bindings
spitzak at gmail.com
Wed Oct 8 15:23:35 PDT 2014
On 10/08/2014 11:58 AM, Giulio Camuffo wrote:
>> A key being held down on focus-in will not produce a "press" event, so I
>> don't see what the problem is.
> It produces a KeyPress in xwayland.
Okay that may be a problem. So you are saying the client cannot
distinguish between keys that were held down when it got the keyboard
focus, and ones that were pressed a very short time afterwards?
I was under the impression that what the client got was an xkb state
that showed that the keys were held down. Actual events caused by
pressing keys were different and distinguishable by the client.
>> If a client wants to check if X is held down I think the user expects it to
>> work even if it was held down as part of the command to switch windows.
>> Therefore I think the current behavior is correct.
> Why would it care about that? The compositor decided that the clients
> shouldn't know that one key was pressed, so the client's shouldn't
> know that. If some client gets to know that it's a bug.
> Or else you should say that key bindings should always let the events
> pass to clients. Are you saying that?
No. All I want is the client to know the current state of the device,
including the actual state of the keys. They should not see the keypress
any more than if the key was pressed in a different client and held down
until the focus switched to this one.
The most obvious one clients want are shift keys. If I type Alt+tab to
go to a different client and keep holding down Alt and type 'x', the
client should act like I typed Alt+x.
Yes I know this works because the modifier bits are being treated
differently than the key map. However I don't think that should be
special. What happens if everybody starts treating hold-down-space as a
modifier (this actually has some precedence in Photoshop and lots of 3D
More information about the wayland-devel