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

[Olivier Fourdan]

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.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: grab.c
Type: text/x-c++src
Size: 2655 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170421/2f063e0b/attachment.c>