[PATCH] Introduce keyboard grabbing protocol

[Jonas Ådahl]

On Tue, Aug 30, 2016 at 03:39:08PM +0200, Giulio Camuffo wrote:
> 2016-08-30 15:22 GMT+02:00 Jonas Ådahl <jadahl at gmail.com>:
> > On Tue, Aug 30, 2016 at 02:12:29PM +0200, Giulio Camuffo wrote:
> >> 2016-08-30 13:58 GMT+02:00 Olivier Fourdan <ofourdan at redhat.com>:
> >> > Hi Giulio,
> >> >
> >> >> i have a couple of comments below
> >> >
> >> > Thanks a lot for your quick reply!
> >> >
> >> >> 2016-08-30 11:54 GMT+02:00 Olivier Fourdan <ofourdan at redhat.com>:
> >> >> > [...]
> >> >>
> >> >> I can understand the Xwayland use, but not the VM one. If i'm using a
> >> >> VM i expect it to receive key events when focused, not otherwise. If
> >> >> the point of this is just to inhibit the compositor's shortcuts than i
> >> >> think the protocol should just do that, and not do an actual grab.
> >> >> Additionally, as a user i'm not sure i would want my shortcuts to stop
> >> >> working, ever...
> >> >
> >> > On X11, some VM viewer will grab the keyboard and pointer so that all input events are set to the window, with one special shortcut to release those grabs - Using the grab keyboard protocol drafted here would allow to do that in Wayland as well.
> >>
> >> I know they do, but while i understand the use of mouse grabbing to
> >> avoid going outside the window, i don't understand the use of keyboard
> >> grabbing. If the window is focused it will receive key events, if it's
> >> not focused as a user i would be surprised to see it still receiving
> >> events. But that doesn't happen, because to focus another window you
> >> need first to break the grab (and i assume an implementation of your
> >> protocol would break the grab when a surface from another client is
> >> focused). So, I can't see what key events would the grab actually
> >> intercept, besides the compositor's shortcuts.
> >
> > I think having a grab would mean one is focused. Though the point of
> > having a key grabbing protocol is simply to override the compositors
> > keybindings. A virtual machine will be very annoying to work with if
> > you can't have the VM or remote desktop client override those. For
> > example I want to Alt-Tab inside the VM or inside the remotely
> > controlled desktop; I wouldn't want to be forced to reconfigure all
> > remotely controlled desktops or virtual machines to use Ctrl-Tab.
> >
> > For this we need a way to steal input normally meant for the compositor.
> > Maybe "keyboard grab" is the wrong thing to call such a protocol, since
> > it shouldn't grab anything when its not in focus, it should only
> > override compositor bindings while already having keyboard focus (would
> > the compositor and user allow it).
> >
> > If we leave Xwayland out for a bit, are you saying this should be on a
> > per key combination override instead? If so, how would a remote desktop
> > client, or virtual machine viewer know what bindings to override? It
> > won't know a thing about that is on the other side. Or what is it that
> > you suggest?
> 
> Well, i didn't suggest anything yet, i was simply trying to understand
> what this is for.
> So it's only for compositor shortcuts, ok.

That is my understanding of it.

> If the fullscreen client
> taking the grab is stuck, or broken, and alt+tab won't work anymore,
> how am i supposed to close it? Are the keys used to break the grab
> defined by the client or the compositor?

I consider that a user interface detail, but I think a sane compositor
would have special key binding for breaking such a grab. For example
when the user is about to grant the grab, the compositor can show a hint
of how to break it, like a special key binding that is still not
overridden (like Ctrl-Alt, or Ctrl-Shift or whatever).

Though of course nothing would stop a client from breaking the grab for
whatever reason.


Jonas

> 
> 
> >
> >
> > Jonas
> >
> >>
> >> >
> >> > Besides, reducing the use of the keyboard grab to Xwayland only might be a tad restrictive.
> >> >
> >> >> [...]
> >> >>
> >> >> I don't think it makes sense to send errors for those, it seems like
> >> >> both cases are out of the client's direct control and as such the
> >> >> client cannot be sure to avoid them, so it should survive when they
> >> >> happen.
> >> >
> >> > Oh absolutely, good point!
> >> >
> >> > Cheers,
> >> > Olivier
> >> _______________________________________________
> >> wayland-devel mailing list
> >> wayland-devel at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel