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

[Pekka Paalanen]

On Tue, 18 Nov 2014 18:54:04 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> 2014-11-13 13:30 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> > Hi,
> >
> > On Thursday, November 13, 2014, Giulio Camuffo <giuliocamuffo at gmail.com>
> > wrote:
> >>
> >> 2014-11-13 12:06 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> >> > But this is just a client issue, and nothing in sending the full keys
> >> > array
> >> > precludes this working.
> >> >
> >> > If Alt+X is a modifier (i.e. any time Alt+X is held, pressing Y triggers
> >> > the
> >> > shortcut), then the client can use the keys array to notice this, and
> >> > ensure
> >> > the shortcut is fired.
> >> >
> >> > If Alt+(X+Y) is a cumulative shortcut, then the client knows from seeing
> >> > X
> >> > in the enter array but not a key event, that it must wait for a release
> >> > on X
> >> > before it arms the shortcut for Y.
> >>
> >> 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.
> >
> >
> > 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.
> >
> > Alternately, we could bump the wl_keyboard version to just allow for
> > consecutive enter events and never send a leave in these temporal cases.
> 
> Do we really need to bump the version? The description of
> wl_keyboard.leave says " Notification that this seat's keyboard focus
> is on a certain surface.", it doesn't say the leave and enter events
> always go in pair, so it seems to me we can just send the new enters
> without changing anything.

We have lots of things we simply imply instead of having it written
down. But I also think we don't even need to consider this.

I don't see problem having the compositor itself steal the keyboard
focus when a hotkey goes down. It would cause a wl_keyboard.leave to
the client, and the keyboard focus would stay in the compositor as long
as the grab is active (hotkeys always install a grab to prevent key
events going to clients). When the grab ends, keyboard focus
can return, and we naturally get the wl_keyboard.enter with the list of
keys. I think this even allows both the compositor first handling the
hotkey-down, and then the app seeing the key already-down.

We even have one hotkey that won't release the grab on key-release: the
debug key. Instead, it will wait for another key to be pressed,
indefinitely IIRC.

Just like Jasper said, it is a mistake to use wl_keyboard focus for
window focus, xdg_shell has a separate mechanism for window focus.
Window focus is a shell concept IMO, anyway.

I would favor the proper keyboard focus transitions I described above,
rather than changing the protocol behaviour. It's easier and can be
done in compositor only, without fixing all toolkits.

That would be half of the fix, the other half being in Xwayland, right?


Thanks,
pq