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

[Daniel Stone]

Hi,

On 21 November 2014 08:57, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 20 Nov 2014 10:31:18 +0200
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> > 2014-11-20 10:05 GMT+02:00 Daniel Stone <daniel at fooishbar.org>:
> > > On 19 November 2014 21:05, Bill Spitzak <spitzak at gmail.com> wrote:
>
> >> You also mentioned an "enter debug mode" shortcut. That must NOT send a
> > >> focus-out event, as it could change the state of the client being
> debugged!
>
> By the very same reasoning, nothing about the debug key combo should be
> sent to any client - except that's not possible. Right now the debug
> key works by first hitting Mod+Shift+Space, then hitting the actual
> debug key (a letter key usually). At least the Mod and Shift will
> somehow end up in some client.


Shrug, so be it. Not a lot we can do about it, and this is also the case on
other OSes.


> > > Heh. To be fair, these debug shortcuts are pretty ephemeral - things
> like
> > > screenshots,
>
> Our debug things include tinting all GL-composited stuff green, drawing
> the triangle mesh edges, toggling cursor and overlay planes of DRM, etc.


I know, I use them all the time. :) I mean ephemeral in terms of keyboard
focus - the grab is active for one press, and focus then reverts to the
client - rather than ephemeral in terms of effect.


> > > I agree 100%. Again, think of nesting compositors: why should our
> compositor
> > > behave completely different if it's nested? The more difficult we make
> it to
> > > sensibly nest compositors, the more we're shooting ourselves in the
> foot.
> >
> > Ok, now you got me confused. Wasn't this what you said would be the
> > correct way to handle bindings?
>
> Yeah, I'm confused too.
>
> I tried to think of a stack of:
>         evdev <- Weston <- nested (compositor) <- app
> and the different cases of how Weston behaves towards nested vs. OS
> (e.g. VT-switching) behaves towards Weston, and I'm not sure I see what
> nested would need to do differently from weston with what I thought.
>

I tried to write out the case that made me nervous in my head, but
couldn't. I'm not sure if that's because it's not actually a real problem,
or I'm just far too tired.


> So how should it work?
>
> I would still assume, that if I press Mod+s to take a screenshot, I
> wouldn't want the 's' to appear on the terminal that happened to have
> the keyboard focus when Mod went down. If the terminal had a Mod+s
> shortcut too, should it run or not?
>
> That is, if all of Weston, nested, and app happened to have the same
> shortcut, should all three fire, or only Weston's?
>

Only Weston.

All three need to obey the same rule:
  - when triggering a hotkey, steal the focus and do _not_ send key events
  - when the grab is ended, send the focus back to the client with the
true, correct, and full keyboard state in enter
  - on an enter event, update internal state but do _not_ trigger actions
or hotkeys because of it

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141121/953a2d14/attachment.html>