Keyboard Grabbing Protocol Proposed For Wayland

[phoronix]

Phoronix: Keyboard Grabbing Protocol Proposed For Wayland

Red Hat developer Olivier Fourdan has proposed adding a keyboard grabbing protocol to Wayland...

http://www.phoronix.com/scan.php?pag...ard-Grab-Proto

[Hi-Angel]

I hope Compositor implementations will figure out to leave a setting to disable that thing. Because it's one of most annoying things in X11 protocol, when something like VirtualBox intercepts hotkeys of WM every time you switch there.

[Trevelyan]

I note on the mailing list there was similar comment. However if you have a VM with the same hotkeys as the Host/Client system, how do you access the functions in that VM.
It always annoyed me that the X11 Grab did not also capture Alt+F#, so if I want to change console on the VM I end up changing console on my desktop..

I can't think of a better solution than full grab, with stacked release.

Those complaining about blocking hot-keys are probably not managing virtual servers or similar systems, they are probably running VMs to access an application. In this case, something like Unity mode would be much better. Speaking of which, I hope VMware adds that back again...

[Hi-Angel]

I note on the mailing list there was similar comment. However if you have a VM with the same hotkeys as the Host/Client system, how do you access the functions in that VM.

Rebind the keys wherever you less care. I.e. (I must say I'm running here Awesome-3.4.14 which did not allow VB to intercept its keys. It was broken later, I reported a bug, and newer versions probably fixed it back. I couldn't test because back then didn't manage to compile because of problem with dependencies due to old system) I have in office a virtualbox with WinXP running a visual studio for C#. I need sometimes to access its startup menu, but "Super" key is bound to WM. So, given I do care of my WM, I rebound inside the WinXP the "Super" key to "F1". Conversely, if I didn't care of WM keys, I'd change them instead of ones in guest system.

It always annoyed me that the X11 Grab did not also capture Alt+F#, so if I want to change console on the VM I end up changing console on my desktop..

You probably mean Ctrl+Alt+F#. If I correctly remember, VirtualBox hacked the problem around by rebinding the keys to either Alt+F# or Ctrl+F# for the guest system.

I can't think of a better solution than full grab, with stacked release.

Well, another viable alternative is to allow Compositor having a list of "exceptional" apps or windows, for which it would give up full grub.

Those complaining about blocking hot-keys are probably not managing virtual servers or similar systems, they are probably running VMs to access an application. In this case, something like Unity mode would be much better. Speaking of which, I hope VMware adds that back again...

Right, I do use a VM to access an app. And I must say, the fact that old Awesome didn't allow to grub its keys is important enough to become for me a show-stopper to not migrate to i3, and to not upgrade office Ubuntu-14.04 to 16.04.

What's the Unity mode?

[guildem]

I think full grab is the only way to do, to allow users to do what they want.

In my use case, I use multiple screens (and refuse to use a vm on a single screen, too annoying to hide the full host, and all the daily used apps). So I want full grab activated when I put my mouse on the vm (if Windows, OSX or Xorg/Wayland client, on a click when in a console vm only), and deactivated when it leaves the vm (or a shortcut configurated by the vm manager when in a console vm only).

And same mapping is important for me too, I don't want to remap some usual shortcuts (like console switching on a linux client), i want to have the same shortcuts anywhere. But i understand that some people want to have some shortcuts redirected to the host. And I think this is a job for the vm manager, allowing the user to forbid some shortcuts in the client. Not a job for the compositor.

So if this draft is accepted and "implemented" in the protocol, I think this is a great news for Wayland !

[Hi-Angel]

I think full grab is the only way to do, to allow users to do what they want.

In my use case, I use multiple screens (and refuse to use a vm on a single screen, too annoying to hide the full host, and all the daily used apps). So I want full grab activated when I put my mouse on the vm (if Windows, OSX or Xorg/Wayland client, on a click when in a console vm only), and deactivated when it leaves the vm (or a shortcut configurated by the vm manager when in a console vm only).

And same mapping is important for me too, I don't want to remap some usual shortcuts (like console switching on a linux client), i want to have the same shortcuts anywhere. But i understand that some people want to have some shortcuts redirected to the host. And I think this is a job for the vm manager, allowing the user to forbid some shortcuts in the client. Not a job for the compositor.

So if this draft is accepted and "implemented" in the protocol, I think this is a great news for Wayland !

Your use case is different. I didn't use mouse most of the time — I'm having touch-type ability, and using tiling WM, as well as everything else fine grained to use keyboard. Which is actually cool, so you can lie back in the chair with keyboard on the knees, and to not care of stretching for the mouse. Or you can use netbook without having problems because of cursor management via touchpad.

I think the good compromise is to ask a user whether they want to allow to grub keys, and then remember the choice, with possibility to change it somehow, of course. And it was actually mentioned in the article and the first message on the list, but what's worrying me is that devs upon implementing might forget it, because by no way asking a user could be a part of the protocol.

[uid313]

Can I listen for key presses in other applications then programmatically insert key presses in other applications?

To make macro software in Wayland, such as AutoHotkey or such.

[guildem]

Your use case is different. I didn't use mouse most of the time — I'm having touch-type ability, and using tiling WM, as well as everything else fine grained to use keyboard. Which is actually cool, so you can lie back in the chair with keyboard on the knees, and to not care of stretching for the mouse. Or you can use netbook without having problems because of cursor management via touchpad.

I think the good compromise is to ask a user whether they want to allow to grub keys, and then remember the choice, with possibility to change it somehow, of course. And it was actually mentioned in the article and the first message on the list, but what's worrying me is that devs upon implementing might forget it, because by no way asking a user could be a part of the protocol.

I agree with your use case, we have all one, and that's why I think Wayland must implement a "full grab" permission to the apps, and then each app can implement settings to forbid some client shortcuts, or more. And I don't think "real" Wayland compositors will forget to ask users for those permissions. It would be a bad move for the compositor to forget it. Same for the vm managers, if they forget this future option, then they are not as good as they think

[Hi-Angel]

Can I listen for key presses in other applications then programmatically insert key presses in other applications?

To make macro software in Wayland, such as AutoHotkey or such.

AFAIK the only app allowed to watch every keypress windows getting is a compositor. That's why they calling the protocol to be secure, i.e. no app can sniff your password, or something. So such a software would rather be an addon to a particular compositor.

[ssokolow]

AFAIK the only app allowed to watch every keypress windows getting is a compositor. That's why they calling the protocol to be secure, i.e. no app can sniff your password, or something. So such a software would rather be an addon to a particular compositor.

Yeah. More specifically, to the use case of macro software, there are proof-of-concept exploits which steal information when all they have is "keyboard/mouse scripting" access by relying on the fact that most desktops have global hotkeys for things like the Run dialog which can be relied upon.