[PATCH weston] input: don't send to clients key events eaten by bindings
daniel at fooishbar.org
Fri Nov 21 10:34:32 PST 2014
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
> 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
> > > Heh. To be fair, these debug shortcuts are pretty ephemeral - things
> > > 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
> > > 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
> > 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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel