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

[Pekka Paalanen]

On Wed, 19 Nov 2014 14:31:35 +0200
Giulio Camuffo <giuliocamuffo at gmail.com> wrote:

> 2014-11-19 13:42 GMT+02:00 Pekka Paalanen <ppaalanen at gmail.com>:
> > 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.
> 
> The only problem with that is that apps using wl_shell can only use
> the keyboard focus as the window focus. Do we just say "too bad,
> wl_shell is broken"?

Yup. I think that's a reasonable thing to do. It's meant to be phased
out even though we can "never" drop it completely. (except mutter
already did, IIRC).

It's not *that* bad. At worst, it's a flicker. At best, might not even
be visible.

And it doesn't work at all if you don't have a physical keyboard to
begin with.

> >
> > 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?
> 
> Well, there is also the part about triggering the binding on key
> release instead of press, only if no other key was pressed in the mean
> time. I hope to send the patch(es) for that one of these days.

That's a thing I didn't quite get yet... oh, wait, maybe I do now.
Yeah. A bit of extra events to send, but shouldn't hurt at all.

Mod down -> send key Mod down
's' down -> oooh, hotkey, steal kbd focus, send kbd.leave

Then either

's' up -> do screenshot, restore kbd focus, send kbd.enter with Mod
down.

or

'x' down -> not our hotkey after all, restore kbd focus, send kbd.enter
with Mod down, send key 'x' down

Something like this, is it?


Thanks,
pq