Bug 1285770 - Keys can't be grabbed under Wayland (needed by remote desktop viewers, virtual machine managers)
Summary: Keys can't be grabbed under Wayland (needed by remote desktop viewers, virtua...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: mutter
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1353422 (view as bug list)
Depends On:
Blocks: WaylandRelated 1500397 1500399
TreeView+ depends on / blocked
 
Reported: 2015-11-26 12:24 UTC by Pierre Ossman
Modified: 2020-03-20 08:49 UTC (History)
50 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1500397 (view as bug list)
Environment:
Last Closed: 2020-02-25 08:11:51 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 97333 0 None None None 2017-01-09 15:03:30 UTC
GNOME Bugzilla 783342 0 Normal RESOLVED Wayland: RFC - add xwayland keyboard grab / shortcut inhibitor support 2021-01-15 14:49:48 UTC

Description Pierre Ossman 2015-11-26 12:24:27 UTC
Applications such as vncviewer[1] have the option of grabbing the keyboard in order to be able to send all keyboard input to a remote system, even if the window manager would like to reserve some things for itself. This is no longer possible when these applications are running under XWayland.

I know this is currently per design in the Wayland protocol, but it is something that needs to be handled somehow.

[1] Boxes, virt-manager and such should also be affected

Comment 1 Kamil Páral 2015-11-26 13:01:11 UTC
In virt-manager, I can't send Win key to the client, it always triggers overview mode in the host. That's probably caused by the same issue.

Comment 2 Sean Young 2015-11-27 12:47:50 UTC
VirtualBox also suffers from this issue; it makes using my Windows 98 VM really painful.

Comment 3 Olivier Fourdan 2015-12-16 13:51:15 UTC
I think this is pretty much the desired behaviour, Wayland was designed with security in mind an no Wayland client can grab the keyboard exclusively.

An X11 application running on Xwayland in Wayland is no different, it cannot "steal" keyboard events from native Wayland applications.

Comment 4 Kamil Páral 2015-12-17 09:54:30 UTC
OK, so IIUIC, this issue should be moved to Wayland, it's not XWayland specific. Thanks for info, Olivier. Is there some solution being worked on or proposed, or is there nothing like that planned?

In my experience, not only I can't send Win key to a VM, I can't even send Alt+Tab or Win+Tab. Which makes controlling it somewhat inconvenient. I assume the same issues will be present in vncviewer and other remote desktop solutions (which might be even more inconvenient, if you're used to work remotely often or for long periods of time).

Comment 5 Rubén 2016-07-05 17:29:06 UTC
Hello.

There must be a workaround that doesnt' compromise security nor violates design requisites. I need to connect to my office computer at work from my home via a Windows 10 virtual machine with Boxes and it's really cumbersome!

Fedora 24.

Thank you!

Regards.

Comment 7 Pierre Ossman 2016-07-19 07:31:41 UTC
Those references only covers grabbing the pointer, not the keyboard.

Comment 8 Christian Stadelmann 2016-07-21 15:37:49 UTC
(In reply to Sean Young from comment #2)
> VirtualBox also suffers from this issue; it makes using my Windows 98 VM
> really painful.

Made my day ;)

(In reply to Christian Stadelmann from comment #6)
> According to [1] this bug is being handled upstream at freedesktop.org by
> wayland devs. They are adding protocol extensions to wayland:
> https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/pointer-
> constraints/pointer-constraints-unstable-v1.xml
> https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/
> relative-pointer/relative-pointer-unstable-v1.xml
> 
> [1]
> https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.
> org/thread/BBPOOC4GVBJXHLKSSFLGERG6GYAU6M6U/

(In reply to Pierre Ossman from comment #7)
> Those references only covers grabbing the pointer, not the keyboard.

You are right, upstream just handles mouse, not keyboard.

Nothing relevant on https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.org/thread/BBPOOC4GVBJXHLKSSFLGERG6GYAU6M6U/ or https://lists.freedesktop.org/mailman/listinfo/wayland-devel either.

Comment 9 IanB 2016-07-21 21:17:31 UTC
*** Bug 1353422 has been marked as a duplicate of this bug. ***

Comment 10 Christian Stadelmann 2016-08-13 16:20:57 UTC
I've filed an upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=97333

Comment 11 Olivier Fourdan 2016-09-01 07:02:56 UTC
(In reply to Kamil Páral from comment #4)
> OK, so IIUIC, this issue should be moved to Wayland, it's not XWayland
> specific. Thanks for info, Olivier. Is there some solution being worked on
> or proposed, or is there nothing like that planned?

See also https://lists.freedesktop.org/archives/wayland-devel/2016-August/030863.html

Comment 12 Fedora End Of Life 2016-11-24 13:45:32 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Dimitrios Apostolou 2016-12-11 16:19:52 UTC
Just letting you know that this is still valid bug.

I hit this bug after upgrading to Fedora 25. I logged in Wayland GNOME session (I was a user of X GNOME), and I can no longer fully control a remote desktop via VNC, using the Remmina VNC client: alt-tab, windows key etc shortcuts are all captured by the local desktop, even when I've set the remote one to full screen with full keyboard grab. This makes work very painful, so I'll have to revert back to the non-default X GNOME session.

Regarding the "security feature" argument that I've heard, I don't see it, as long as I give permission for keyboard grab by explicitly selecting it and possibly answering some dialog box. Apparently I wouldn't like random applications listening to all my keyboard events, but this is not the case here.

Comment 14 Scott Clark 2016-12-30 16:27:34 UTC
Similar experience after upgrading from 24 -> 25, the Remmina clipboard sync no longer works. I expect this has something to to with Wayland and the isolation of the windows, but have not yet looked into that.

Fedora 25
Remmina 1.2.0-rcgit-15 (1.2.0-0.23.20160914git42f5a87.fc25)

Comment 15 Lucas van Vloten 2017-01-08 22:08:23 UTC
I confirm this bug using the freerdp client to connect to Windows remote desktop session. All Windows keyboard shortcuts (alt-tab, Windows-e, etc. are not sent to the remote desktop but to the local host instead.

Fedora 25
freerdp-2.0.0-12.20160909git1855e36.fc25.x86_64

In my experience, this bug effectively makes it impossible, or at least highly impractical, to use a Windows remote desktop under Wayland.

Comment 16 Kamil Páral 2017-01-09 13:10:03 UTC
Thanks, no more confirmations are needed. We know this is simply not implemented yet. If you need this, please use the X11 session until this is fixed.

Comment 17 Pierre Ossman 2017-01-09 14:48:54 UTC
I don't think that was the right gnome bug number. :)

Comment 18 Kamil Páral 2017-01-09 15:03:30 UTC
Ugh, thanks. Wrong tracker.

Comment 19 Andrey 2017-03-03 12:27:50 UTC
The same problem when using Remmina and VMware-view Horizon.

Comment 21 Pierre Ossman 2017-03-27 10:38:18 UTC
Nice to see this progressing. :)

Just a quick note, override redirect is the old way of fullscreen on X11 and a lot of well behaved applications ask the window manager instead. So I guess Xwayland may need support for both extensions depending on how well behaved the application is?

Comment 22 Olivier Fourdan 2017-03-27 11:32:33 UTC
(In reply to Pierre Ossman from comment #21)
> Nice to see this progressing. :)
> 
> Just a quick note, override redirect is the old way of fullscreen on X11 and
> a lot of well behaved applications ask the window manager instead. So I
> guess Xwayland may need support for both extensions depending on how well
> behaved the application is?

That's unrelated, this is about adding a mechanism to "emulate" grabs on Wayland, the window being O-R is just a case of where there is no workaround.

But "well behaved" X11 applications asking for fullscreen using EWMH already work fine and certainly do not need this mechanism.

Comment 23 Pierre Ossman 2017-03-27 14:11:10 UTC
It sounded like one of your (two) grab extensions was specifically for O-R windows? Fullscreen via EWMH should be able to make do using the other proposed Wayland extension.

Comment 24 Olivier Fourdan 2017-03-28 07:10:35 UTC
(In reply to Pierre Ossman from comment #23)
> It sounded like one of your (two) grab extensions was specifically for O-R
> windows?

That's correct.

> Fullscreen via EWMH should be able to make do using the other
> proposed Wayland extension.

Maybe you should take this discussion on the thread upstream where this would be more appropriate than in a downstream bugzilla.

On Wayland, an X11 application running on Xwayland uses the "regular" X11 window manager which implements EWMH, it does not need any specific Wayland protocol for that, it just uses the good ol' X11 protocols.

See https://wayland.freedesktop.org/xserver.html

For example, on GNOME, mutter plays the role of Wayland compositor and X11 window manager, and mutter/gnome-shell itself relies heavily on X11/Xwayland even when running as a Wayland compositor. An X11 client wishing to map its X11 window fullscreen using EWMH does not need an O-R, it just sents the relevant WM hint on the window and the X11 window manager will map that window fullscreen if applicable.

The protocol for Xwayland I sent upstream is for O-R windows, those are not focused by X11 window managers (basically they are mostly ignored by X11 window managers, by definition, even if that's not true with compositor managers which need to draw them), so that an X11 client issuing a grab on its X11 window will never get the keyboard focus when running on Xwayland because Wayland does not have any grab mechanism to match the X11 grabbing protocol.

Comment 25 Olivier Fourdan 2017-03-28 07:33:19 UTC
And to clear up any misunderstanding, there is nothing neither in the protocol nor in the sample implementation I made which is specific for O-R windows in any way, it's just that the protocols is necessary for O-R window *because* they aren't focused by X11 window managers.

Comment 26 David H. Gutteridge 2017-04-27 20:29:36 UTC
Adding myself to the CC list, and while here, I should add, the situation is worse still if another layer of indirection is involved. If I run virt-viewer or virt-manager as a remote X client under Xwayland, no keyboard events at all make it to the VM.

Comment 28 Olivier Fourdan 2017-10-10 14:35:29 UTC
Fixed with native Wayland apps, x11 fix pending review/merge.

Comment 29 Matěj Cepl 2017-11-09 15:32:31 UTC
I wonder whether it is the same bug, but I don’t have ANY keys inside of the VM machine when virt-manager runs under Xsession. Is it?

Comment 30 Christophe Fergeau 2017-11-09 15:40:40 UTC
(In reply to Matěj Cepl from comment #29)
> I wonder whether it is the same bug, but I don’t have ANY keys inside of the
> VM machine when virt-manager runs under Xsession. Is it?

Could it be https://bugzilla.redhat.com/show_bug.cgi?id=1479682 ?

Comment 31 Olivier Fourdan 2017-11-09 15:58:29 UTC
(In reply to Christophe Fergeau from comment #30)
> (In reply to Matěj Cepl from comment #29)
> > I wonder whether it is the same bug, but I don’t have ANY keys inside of the
> > VM machine when virt-manager runs under Xsession. Is it?
> 
> Could it be https://bugzilla.redhat.com/show_bug.cgi?id=1479682 ?

If this affects virt-manager under a plain X session (as comment 30 states), then it's completely unrelated to either bugs (i.e. neither Wayland nor Xwayland).

Comment 32 Rubén 2017-11-14 22:38:38 UTC
It works for me after upgrading to Fedora 27 (gnome-boxes)

Thanks very much.

Comment 33 Jonas Ådahl 2020-02-25 08:11:51 UTC
This is already possible, using two ways:

 * With Wayland clients, they can use the 'shortcut inhibitation protocol'. This is used by e.g. GNOME Boxes already.
 * With X11 clients, there is a (preconfigured, but changable) white list of clients whos grabs will be granted allowing them to work as intended. See org.gnome.mutter gsettings.

Comment 34 Antoine Martin 2020-03-15 07:54:31 UTC
>  With X11 clients, there is a (preconfigured, but changable) white list of clients whos grabs will be granted allowing them to work as intended. See org.gnome.mutter gsettings.
Who manages this list and how do we (xpra) get in on it?

Comment 35 Jonas Ådahl 2020-03-15 08:23:04 UTC
(In reply to Antoine Martin from comment #34)
> >  With X11 clients, there is a (preconfigured, but changable) white list of clients whos grabs will be granted allowing them to work as intended. See org.gnome.mutter gsettings.
> Who manages this list and how do we (xpra) get in on it?

Correct me if I'm wrong, but isn't Xpra more similar to X11 forwarding than a virtual machine viewer or remote desktop client? As in, the difference between showing the whole desktop where one needs to Alt-tab etc, and running a client remotely but used just as if it was running locally. If this is indeed how Xpra work then the gsetting you are referring to is not aimed to help with that, as it such clients should gain no extra abilities to take control of the input devices in the session more than if the same client was running locally.

Comment 36 Antoine Martin 2020-03-15 08:52:29 UTC
> Correct me if I'm wrong, but isn't Xpra more similar to X11 forwarding than a virtual machine viewer or remote desktop client?
That's correct for "seamless" mode, but xpra now also supports a "desktop" mode, which is more similar to VNC and even supports basic VNC clients. ie:
xpra start-desktop --start=fluxbox --attach=yes

Then there's also the use case of forwarding another remote desktop client or virtual machine manager via xpra.

Comment 37 Antoine Martin 2020-03-20 08:49:03 UTC
The default location where this is configured in mutter is 'xwayland_grab_default_access_rules' in 'meson_options.txt' and here's a merge request for it:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1138


Note You need to log in before you can comment on or make changes to this bug.