GNOME's Mutter Now Supports XWayland Keyboard Grabbing, XDG-Output

[phoronix]

Phoronix: GNOME's Mutter Now Supports XWayland Keyboard Grabbing, XDG-Output

More (X)Wayland improvements are en route for GNOME 3.28...

http://www.phoronix.com/scan.php?page=news_item&px=Mutter-XWayland-Key-Grabs

[uid313]

Under GNOME on Wayland, if I want to detect key presses inserted into another application and insert key strokes on that application, do I need to create an GNOME Shell extension?

I want to;

1. Listen for middle-mouse button clicks on window with the title "Foo".
2. Insert key press F5 into the window with the title "Foo".

This would allow me bind my mouse buttons to hotkeys in games. So when I press middle mouse button it does send F5 to the game which throws a magical spell.

[oiaohm]

Under GNOME on Wayland, if I want to detect key presses inserted into another application and insert key strokes on that application, do I need to create an GNOME Shell extension?

I want to;

1. Listen for middle-mouse button clicks on window with the title "Foo".
2. Insert key press F5 into the window with the title "Foo".

This would allow me bind my mouse buttons to hotkeys in games. So when I press middle mouse button it does send F5 to the game which throws a magical spell.

https://www.phoronix.com/scan.php?page=news_item&px=Inputfd-v3-Wayland-Protocol

No way the path you suggested is going to be good long term. inputfd passthrough design can remove the compositor off particular input devices.

https://cgit.freedesktop.org/wayland...nts/keyboard.c items like virtual keyboard support under wayland are not designed to find what application they are in fact sending messages to.

Of course running application under xwayland and using X11 method still works.

Really you have to remember client side decorations. Under Wayland you are not required to "set surface title".on all windows in a unique way in fact if you don't want to list in task-manager you are not required to set one..

So since there is nothing in protocol directly is there still a method that could be used to pull of want you want. The answer is yes.

http://manpages.ubuntu.com/manpages/zesty/man1/weston.1.html

Most people don't notice that wayland compositor can run inside another wayland compositor. So the correct way would most likely to be to write a wayland compositor that itself runs inside wayland for the expresses purpose of this.

1. Since now you would start the game inside particular compositor providing this feature you would know all windows in that compositor relate to that game particularly for multi process games.
2. Incompatible wayland protocols could be reported to application as not existing or not permitted like inputfd on mouse so the modification point cannot be cut out of the events going to the game..
3. Finally security you are not running application snooping on all desktop activity that if breached could steal information from other applications. This is why not a shell extension.

Notice something else about wayland compositor inside wayland compositor method the overhead of input monitoring and modification would not effect every application running either only the game/program running in a special compositor.

Wayland is more designed from a security point of view and this does mean items use to be done by shell extensions and other things at times will be write compositor and take overhead. Interesting point is that stacking two compositors can be less over head than having to string check all the titles windows on every mouse click.

Some of the headaches about migrating to Wayland is having these extra parts be made and come into common usage. Of course this is slowed down by those attempting to keep on using the old X11 and Windows methods of being able to snoop on everything that is a security risk on Wayland..

[franglais125]

Under GNOME on Wayland, if I want to detect key presses inserted into another application and insert key strokes on that application, do I need to create an GNOME Shell extension?

You can do this with an extension, but apparently this is not so easy to achieve. I tried to do this for dash-to-dock, and opened a bug upstream, where the asnwer was something like:

"This is doable in mutter, with an extension, but you'll have to work hard for it".

https://bugzilla.gnome.org/show_bug.cgi?id=788159

[uid313]

Some of the headaches about migrating to Wayland is having these extra parts be made and come into common usage. Of course this is slowed down by those attempting to keep on using the old X11 and Windows methods of being able to snoop on everything that is a security risk on Wayland..

Thanks for the insight.
This seems like difficult task to accomplish. I was hoping it would be easier.

[jacob]

More than anything I hope that GNOME 3.28 will fix the bug where XWayland crashes because GNOME Shell/Mutter is too slow to respond to events. This happens in Ubuntu 17.10 and is extremely annoying.

[oiaohm]

More than anything I hope that GNOME 3.28 will fix the bug where XWayland crashes because GNOME Shell/Mutter is too slow to respond to events. This happens in Ubuntu 17.10 and is extremely annoying.

https://www.addictivetips.com/ubuntu-linux-tips/get-stock-gnome-shell-in-ubuntu-17-10/

I would have to ask is that with Gnome on Ubuntu switched back to stock or with normal ubuntu lack of quality control made parts. Part of the reason I was not suggesting uid313 use shell extensions.

[jacob]

https://www.addictivetips.com/ubuntu-linux-tips/get-stock-gnome-shell-in-ubuntu-17-10/

I would have to ask is that with Gnome on Ubuntu switched back to stock or with normal ubuntu lack of quality control made parts. Part of the reason I was not suggesting uid313 use shell extensions.

I can't test it here but AFAIK the same problem was reported on Fedora, which uses stock Gnome Shell, so it's not related to the Ubuntu tweaks.