Re: [PATCH] Introduce keyboard grabbing protocol

[Yong Bakos]

Hi,

> On Dec 1, 2016, at 3:07 AM, Olivier Fourdan  wrote:
> 
> Hey,
> 
> - Original Message -
>> On 30 August 2016 at 14:05, Olivier Fourdan  wrote:
 Xwayland should probably use a private protocol, like EGL, ideally
 completely hidden and pid-restricted.
>>> 
>>> That's the point, I initially thought of a private protocol, but then
>>> realized it could be useful outside of the Xwayland use case as well.
>>> 
>>> If not, I'd be happy to drop this patch and return to the private approach
>>> :)
>>> 
>>> Speaking of which, that was the idea behind those patches:
>>> 
>>> https://patchwork.freedesktop.org/patch/105319/
>>> https://patchwork.freedesktop.org/patch/103815/
>>> https://patchwork.freedesktop.org/patch/105421/
>> 
>> H. I really, desperately, want to avoid keyboard grabs as much as
>> possible. But I guess Alt-Tab in a VM is the one usecase which can't
>> route around this. Out of interest, do you know if that works on
>> VMWare/VirtualBox/etc on OS X and Windows? If they don't, then we
>> don't have to either, and we can just make this private to XWayland.
>> If they do, then I guess we probably need to follow suit as well.
> 
> According to VMWare docs available online, it has this feature on Windows, it 
> uses a special key combo to release the mouse and keyboard input when needed.
> 
> And according to Virtualbox manual, Virtualbox has that too: 
> https://www.virtualbox.org/manual/ch01.html#keyb_mouse_normal

FWIW, just chiming in to assert that this is true on all platforms. For
example, punching ctrl-super (command) from within the guest vm will
release input control to the host.

yong


> 
>> If we do though, I'd prefer to see two protocols: one for native
>> clients which demands a matching wl_seat serial, and another for
>> XWayland which doesn't have that restriction.
> 
> This has an additional benefit, we can work on a "private" protocol for 
> Xwayland (to keep backward compatibility with existing X11 applications) and 
> decide later to do the same for native clients, if needed.
> 
>> Note that this is basically just about the concept; I haven't looked
>> at the exact detail of the wording yet.
> 
> 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

Re: [PATCH] Introduce keyboard grabbing protocol

[Olivier Fourdan]

Hey,

- Original Message -
> On 30 August 2016 at 14:05, Olivier Fourdan  wrote:
> >> Xwayland should probably use a private protocol, like EGL, ideally
> >> completely hidden and pid-restricted.
> >
> > That's the point, I initially thought of a private protocol, but then
> > realized it could be useful outside of the Xwayland use case as well.
> >
> > If not, I'd be happy to drop this patch and return to the private approach
> > :)
> >
> > Speaking of which, that was the idea behind those patches:
> >
> > https://patchwork.freedesktop.org/patch/105319/
> > https://patchwork.freedesktop.org/patch/103815/
> > https://patchwork.freedesktop.org/patch/105421/
> 
> H. I really, desperately, want to avoid keyboard grabs as much as
> possible. But I guess Alt-Tab in a VM is the one usecase which can't
> route around this. Out of interest, do you know if that works on
> VMWare/VirtualBox/etc on OS X and Windows? If they don't, then we
> don't have to either, and we can just make this private to XWayland.
> If they do, then I guess we probably need to follow suit as well.

According to VMWare docs available online, it has this feature on Windows, it 
uses a special key combo to release the mouse and keyboard input when needed.

And according to Virtualbox manual, Virtualbox has that too: 
https://www.virtualbox.org/manual/ch01.html#keyb_mouse_normal

> If we do though, I'd prefer to see two protocols: one for native
> clients which demands a matching wl_seat serial, and another for
> XWayland which doesn't have that restriction.

This has an additional benefit, we can work on a "private" protocol for 
Xwayland (to keep backward compatibility with existing X11 applications) and 
decide later to do the same for native clients, if needed.
 
> Note that this is basically just about the concept; I haven't looked
> at the exact detail of the wording yet.

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce keyboard grabbing protocol

[Daniel Stone]

Hi,

On 30 August 2016 at 14:05, Olivier Fourdan  wrote:
>> Xwayland should probably use a private protocol, like EGL, ideally
>> completely hidden and pid-restricted.
>
> That's the point, I initially thought of a private protocol, but then 
> realized it could be useful outside of the Xwayland use case as well.
>
> If not, I'd be happy to drop this patch and return to the private approach :)
>
> Speaking of which, that was the idea behind those patches:
>
> https://patchwork.freedesktop.org/patch/105319/
> https://patchwork.freedesktop.org/patch/103815/
> https://patchwork.freedesktop.org/patch/105421/

H. I really, desperately, want to avoid keyboard grabs as much as
possible. But I guess Alt-Tab in a VM is the one usecase which can't
route around this. Out of interest, do you know if that works on
VMWare/VirtualBox/etc on OS X and Windows? If they don't, then we
don't have to either, and we can just make this private to XWayland.
If they do, then I guess we probably need to follow suit as well.

If we do though, I'd prefer to see two protocols: one for native
clients which demands a matching wl_seat serial, and another for
XWayland which doesn't have that restriction.

Note that this is basically just about the concept; I haven't looked
at the exact detail of the wording yet.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce keyboard grabbing protocol

[Constantine Kharlamov]

01.09.2016, 02:22, "Carsten Haitzler (The Rasterman)" :
> if the vm decides that as a result of the grab error it will exit... who do
> you blame? compositor that is saying "no" and tell it to always say yes... or
> the app that chooses to take this as a fatal condition and exit? :)

I understand, it was a rhetoric question, but anyway… VM just shouldn't know
that it couldn't grab keys of a compositor. The user would know that because of
notification, so it's fine.

Alternatively, it's possible to leave keys working in a compositor and pass
them to VM at the same time. I.e. this is how it worked in the ancient
Awesome-3.4.14, which I mentioned: upon pressing "Super+1" I was, both,
switched to 1-st desktop, and getting a popup of Start menu in the VM with XP.
Though it was annoying a bit either, so I end up disabling Super key in the
guest system, but it's a viable alternative.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce keyboard grabbing protocol

[The Rasterman]

On Tue, 30 Aug 2016 19:33:17 +0300 Constantine Kharlamov  said:

> 2016-08-30 15:22 GMT+02:00 Jonas Ådahl :
> > 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.
> 
> Hello, coming here from the news.
> 
> I'm having the opposite use-case: at office I need to work with WinXP in
> VirtualBox, and it is annoying as hell that I have to press an additional key
> to switch desktop/window in the host system. It is annoying enough, that the
> fact that an ancient version of Awesome WM didn't allow to grab its keys
> become a show stopper for upgrading Awesome, for migrating to i3, and now to
> upgrading whole system.
> 
> If one really wants some apps to grub Compositor's keys, I think the
> compositors should offer the user to (dis)allow it.

that's the point. use a compositor that lets you enable or disable this. or
provide patches. compositors are now in charge of this policy. (likely they
should allow disabling on a per-window basis and be able to re-identify the
window/surface again next time it's created so it can re-apply the ban). just
because there is a protocol does not mean compositor have to slavishly
implemented it globally for everything. they can choose not to  as they see fit
and of course you are left with the consequences. if the vm decides that as a
result of the grab error it will exit... who do you blame? compositor that is
saying "no" and tell it to always say yes... or the app that chooses to take
this as a fatal condition and exit? :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [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 :
> > On Tue, Aug 30, 2016 at 02:12:29PM +0200, Giulio Camuffo wrote:
> >> 2016-08-30 13:58 GMT+02:00 Olivier Fourdan :
> >> > 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 :
> >> >> > [...]
> >> >>
> >> >> 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

Re: [PATCH] Introduce keyboard grabbing protocol

[Giulio Camuffo]

2016-08-30 15:22 GMT+02:00 Jonas Ådahl :
> On Tue, Aug 30, 2016 at 02:12:29PM +0200, Giulio Camuffo wrote:
>> 2016-08-30 13:58 GMT+02:00 Olivier Fourdan :
>> > 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 :
>> >> > [...]
>> >>
>> >> 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@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

Re: [PATCH] Introduce keyboard grabbing protocol

[Jonas Ådahl]

On Tue, Aug 30, 2016 at 02:12:29PM +0200, Giulio Camuffo wrote:
> 2016-08-30 13:58 GMT+02:00 Olivier Fourdan :
> > 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 :
> >> > [...]
> >>
> >> 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?


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

Re: [PATCH] Introduce keyboard grabbing protocol

[Olivier Fourdan]

Hi

> Xwayland should probably use a private protocol, like EGL, ideally
> completely hidden and pid-restricted.

That's the point, I initially thought of a private protocol, but then realized 
it could be useful outside of the Xwayland use case as well.

If not, I'd be happy to drop this patch and return to the private approach :)

Speaking of which, that was the idea behind those patches:

https://patchwork.freedesktop.org/patch/105319/
https://patchwork.freedesktop.org/patch/103815/
https://patchwork.freedesktop.org/patch/105421/

Cheers,
Olivier

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce keyboard grabbing protocol

[Quentin Glidic]

On 30/08/2016 12:18, Giulio Camuffo wrote:

Hi,

i have a couple of comments below

2016-08-30 11:54 GMT+02:00 Olivier Fourdan :



>> [snip]

+  
+   This protocol specifies a way for a client to request all keyboard
+   events to be forwarded to a surface.
+
+   A possible use case for this is a virtual machine or a remote
+   connection viewer where all key events must be sent to the specific
+   surface, ignoring the compositor own's shortcuts.
+
+   Another use case is Xwayland. Unlike the X11 protocol, Wayland
+   doesn't have the notion of active grab on the keyboard. When an
+   X11 client acquires an active grab on the keyboard, all key events
+   are reported only to the grabbing X11 client.
+   When running in Xwayland, X11 applications may acquire an active
+   grab but that cannot be translated to the Wayland compositor who
+   may set the input focus to some other surface, thus breaking the
+   X11 client assumption that all key events are reported.


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


I agree. The VM use case should use the pointer constraint protocol, and 
get relative events and all that stuff.


If you use VMs often enough, you probably want to configure them to 
avoid keybinding collisions.


Xwayland should probably use a private protocol, like EGL, ideally 
completely hidden and pid-restricted.



Cheers,



[snip]


--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Introduce keyboard grabbing protocol

[Giulio Camuffo]

2016-08-30 13:58 GMT+02:00 Olivier Fourdan :
> 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 :
>> > [...]
>>
>> 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.

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

Re: [PATCH] Introduce keyboard grabbing protocol

[Olivier Fourdan]

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 :
> > [...]
> 
> 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.

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

Re: [PATCH] Introduce keyboard grabbing protocol

[Giulio Camuffo]

Hi,

i have a couple of comments below

2016-08-30 11:54 GMT+02:00 Olivier Fourdan :
> This patch introduces a new protocol for grabbing a keyboard.
>
> Signed-off-by: Olivier Fourdan 
> ---
>  Makefile.am|   1 +
>  configure.ac   |   2 +-
>  unstable/keyboard-grab/README  |   4 +
>  .../keyboard-grab/keyboard-grab-unstable-v1.xml| 136 
> +
>  4 files changed, 142 insertions(+), 1 deletion(-)
>  create mode 100644 unstable/keyboard-grab/README
>  create mode 100644 unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index e693afa..9ab5dc7 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -12,6 +12,7 @@ unstable_protocols =
>   \
> unstable/tablet/tablet-unstable-v2.xml
>   \
> unstable/xdg-foreign/xdg-foreign-unstable-v1.xml  
>   \
> unstable/idle-inhibit/idle-inhibit-unstable-v1.xml
>   \
> +   unstable/keyboard-grab/keyboard-grab-unstable-v1.xml  
>   \
> $(NULL)
>
>  stable_protocols =   
>   \
> diff --git a/configure.ac b/configure.ac
> index 4c43daa..cae4a56 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,7 +1,7 @@
>  AC_PREREQ([2.64])
>
>  m4_define([wayland_protocols_major_version], [1])
> -m4_define([wayland_protocols_minor_version], [7])
> +m4_define([wayland_protocols_minor_version], [8])
>  m4_define([wayland_protocols_version],
>[wayland_protocols_major_version.wayland_protocols_minor_version])
>
> diff --git a/unstable/keyboard-grab/README b/unstable/keyboard-grab/README
> new file mode 100644
> index 000..1a6529f
> --- /dev/null
> +++ b/unstable/keyboard-grab/README
> @@ -0,0 +1,4 @@
> +keyboard grabbing protocol
> +
> +Maintainers:
> +Olivier Fourdan 
> diff --git a/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml 
> b/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
> new file mode 100644
> index 000..31d5a6a
> --- /dev/null
> +++ b/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
> @@ -0,0 +1,136 @@
> +
> +
> +
> +  
> +Copyright © 2016 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +   This protocol specifies a way for a client to request all keyboard
> +   events to be forwarded to a surface.
> +
> +   A possible use case for this is a virtual machine or a remote
> +   connection viewer where all key events must be sent to the specific
> +   surface, ignoring the compositor own's shortcuts.
> +
> +   Another use case is Xwayland. Unlike the X11 protocol, Wayland
> +   doesn't have the notion of active grab on the keyboard. When an
> +   X11 client acquires an active grab on the keyboard, all key events
> +   are reported only to the grabbing X11 client.
> +   When running in Xwayland, X11 applications may acquire an active
> +   grab but that cannot be translated to the Wayland compositor who
> +   may set the input focus to some other surface, thus breaking the
> +   X11 client assumption that all key events are reported.

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

> +
> +   When a client requests a keyboard grab, the Wayland compositor may
> +   either inform 

[RFC PATCH] Introduce keyboard grabbing protocol

[Olivier Fourdan]

Hi all,

I think we need a way for client to request a keyboard grab in Wayland.

Use case for this can be a virtual machine or remote connection viewer,
or even Xwayland itself who cannot tell the compositor when an X client
issues a XGrabKeyboard [1]

I would like to keep this protocol as simple as possible, the client asks
for a keyboard grab, the compositor may deny it, or may not even issue it.

The compositor may inform and ask the user if (s)he agrees with a given
applications grabbing the keyboard, might put in place a visual indication
that a grab is in effect, even allow the user to terminate the grab whenever
(s)he wants, etc. This is all up to the compositor and the user to decide.

I modelled this protocol after the keyboard locking mechanism but did not
keep the lifetime parameter, to keep things as simple as possible.

Cheers,
Olivier

Olivier Fourdan (1):
  Introduce keyboard grabbing protocol

 Makefile.am|   1 +
 configure.ac   |   2 +-
 unstable/keyboard-grab/README  |   4 +
 .../keyboard-grab/keyboard-grab-unstable-v1.xml| 136 +
 4 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 unstable/keyboard-grab/README
 create mode 100644 unstable/keyboard-grab/keyboard-grab-unstable-v1.xml

-- 
2.7.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Introduce keyboard grabbing protocol

[Olivier Fourdan]

This patch introduces a new protocol for grabbing a keyboard.

Signed-off-by: Olivier Fourdan 
---
 Makefile.am|   1 +
 configure.ac   |   2 +-
 unstable/keyboard-grab/README  |   4 +
 .../keyboard-grab/keyboard-grab-unstable-v1.xml| 136 +
 4 files changed, 142 insertions(+), 1 deletion(-)
 create mode 100644 unstable/keyboard-grab/README
 create mode 100644 unstable/keyboard-grab/keyboard-grab-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..9ab5dc7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols =  
\
unstable/tablet/tablet-unstable-v2.xml  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
+   unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/configure.ac b/configure.ac
index 4c43daa..cae4a56 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
 AC_PREREQ([2.64])
 
 m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [7])
+m4_define([wayland_protocols_minor_version], [8])
 m4_define([wayland_protocols_version],
   [wayland_protocols_major_version.wayland_protocols_minor_version])
 
diff --git a/unstable/keyboard-grab/README b/unstable/keyboard-grab/README
new file mode 100644
index 000..1a6529f
--- /dev/null
+++ b/unstable/keyboard-grab/README
@@ -0,0 +1,4 @@
+keyboard grabbing protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git a/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml 
b/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
new file mode 100644
index 000..31d5a6a
--- /dev/null
+++ b/unstable/keyboard-grab/keyboard-grab-unstable-v1.xml
@@ -0,0 +1,136 @@
+
+
+
+  
+Copyright ?? 2016 Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+   This protocol specifies a way for a client to request all keyboard
+   events to be forwarded to a surface.
+
+   A possible use case for this is a virtual machine or a remote
+   connection viewer where all key events must be sent to the specific
+   surface, ignoring the compositor own's shortcuts.
+
+   Another use case is Xwayland. Unlike the X11 protocol, Wayland
+   doesn't have the notion of active grab on the keyboard. When an
+   X11 client acquires an active grab on the keyboard, all key events
+   are reported only to the grabbing X11 client.
+   When running in Xwayland, X11 applications may acquire an active
+   grab but that cannot be translated to the Wayland compositor who
+   may set the input focus to some other surface, thus breaking the
+   X11 client assumption that all key events are reported.
+
+   When a client requests a keyboard grab, the Wayland compositor may
+   either inform or ask the user for the right to forward all key
+   events to the given client surface.
+
+   Warning! The protocol described in this file is experimental and
+   backward incompatible changes may be made. Backward compatible
+   changes may be added together with the corresponding interface
+   version bump.
+   Backward incompatible changes are done by bumping the version
+   number in the protocol and interface names and resetting the
+   interface version. Once the protocol is to be declared stable, the
+   'z' prefix and the version number in the protocol and interface
+   names are removed and the interface version number is reset.