On Tue, Aug 30, 2016 at 03:39:08PM +0200, Giulio Camuffo wrote: > 2016-08-30 15:22 GMT+02:00 Jonas Ådahl <jad...@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 <ofour...@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 <ofour...@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@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel