[PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Kristian Høgsberg]

On Fri, Apr 21, 2017 at 5:50 AM Olivier Fourdan <ofourdan at redhat.com> wrote:

>
> Hi Jonas,
>
> > > [...]
> > > For that last point, I'd rather use:
> > >
> > >     * does not guarantee that events sent to this client are
> continuous,
> > >       a compositor may change and reroute keyboard events while the
> grab
> > >       is nominally active.
> > >
> > > > hmm, and thinking about the last point: do we need to specify what
> the
> > > > focus
> > > > behaviour is if a grab is active? I'm assuming 'no' because there is
> no
> > > > notification whatsoever whether it ever activates anyway, but...
> > >
> > > No, indeed, that's precisely the main difference with the shortcuts
> > > inhibitor logic for the wayland native apps.
> > >
> > > Here, keyboards events are routed to the surface regardless of the
> focus,
> > > just like an X11 grab.
> >
> > Should this part really be respected though? In what circumstances does
> > it make sense to route input events to Xwayland when a Wayland client is
> > the one focused?
>
> Yes, that's precisely the whole point of this protocol (and grabs in
> general) :)
>
> Take the attached sample code for example, it maps a single override
> redirect window (one that no X11 window manager would focus, because it's
> an O-R) and issues an active keyboard grab to get all keyboard events.
>

What is the use case that this is trying to support though? Which Xwayland
apps are you trying to support with this?


> While that works fine in X11 native, that won't work in Wayland/Xwayland
> without this protocol and the ability to route keyboard events even when
> the surface is not focused.
>
> > > > Last question: how will you deal with XGrabKeyboard() requests on
> already
> > > > grabbed keyboards? I can send that request twice with different grab
> > > > windows
> > > > and it'll change the grab over (iirc). Xwayland will destroy the
> current
> > > > grab and request a new one?
> > >
> > > Yeap, good point, "XGrabKeyboard overrides any active keyboard grab by
> the
> > > client" so Xwayland needs to destroy any current grab before setting a
> new
> > > one in this case.
> > >
> >
> > FWIW, this will create a minor race, where any key presses between the
> > .destroy and .grab requests will be ungrabbed.
>
> Yeah, you're right, but I reckon it's acceptable.
>
> Cheers,
> Olivier
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170424/59b8e10f/attachment-0001.html>