<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Apr 21, 2017 at 5:50 AM Olivier Fourdan <<a href="mailto:ofourdan@redhat.com">ofourdan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Jonas,<br>
<br>
> > [...]<br>
> > For that last point, I'd rather use:<br>
> ><br>
> >     * does not guarantee that events sent to this client are continuous,<br>
> >       a compositor may change and reroute keyboard events while the grab<br>
> >       is nominally active.<br>
> ><br>
> > > hmm, and thinking about the last point: do we need to specify what the<br>
> > > focus<br>
> > > behaviour is if a grab is active? I'm assuming 'no' because there is no<br>
> > > notification whatsoever whether it ever activates anyway, but...<br>
> ><br>
> > No, indeed, that's precisely the main difference with the shortcuts<br>
> > inhibitor logic for the wayland native apps.<br>
> ><br>
> > Here, keyboards events are routed to the surface regardless of the focus,<br>
> > just like an X11 grab.<br>
><br>
> Should this part really be respected though? In what circumstances does<br>
> it make sense to route input events to Xwayland when a Wayland client is<br>
> the one focused?<br>
<br>
Yes, that's precisely the whole point of this protocol (and grabs in general) :)<br>
<br>
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.<br></blockquote><div><br></div><div>What is the use case that this is trying to support though? Which Xwayland apps are you trying to support with this?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
> > > Last question: how will you deal with XGrabKeyboard() requests on already<br>
> > > grabbed keyboards? I can send that request twice with different grab<br>
> > > windows<br>
> > > and it'll change the grab over (iirc). Xwayland will destroy the current<br>
> > > grab and request a new one?<br>
> ><br>
> > Yeap, good point, "XGrabKeyboard overrides any active keyboard grab by the<br>
> > client" so Xwayland needs to destroy any current grab before setting a new<br>
> > one in this case.<br>
> ><br>
><br>
> FWIW, this will create a minor race, where any key presses between the<br>
> .destroy and .grab requests will be ungrabbed.<br>
<br>
Yeah, you're right, but I reckon it's acceptable.<br>
<br>
Cheers,<br>
Olivier<br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div></div>