[PATCH] Introduce keyboard grabbing protocol

[Giulio Camuffo]

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. 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?


>
>
> 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