Bug 1500397

+++ This bug was initially created as a clone of Bug #1285770 +++

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

--- Additional comment from Kamil Páral on 2015-11-26 08:01:11 EST ---

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.

--- Additional comment from Sean Young on 2015-11-27 07:47:50 EST ---

VirtualBox also suffers from this issue; it makes using my Windows 98 VM really painful.

--- Additional comment from Olivier Fourdan on 2015-12-16 08:51:15 EST ---

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.

--- Additional comment from Kamil Páral on 2015-12-17 04:54:30 EST ---

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

--- Additional comment from Rubén Lledó on 2016-07-05 13:29:06 EDT ---

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.

--- Additional comment from Christian Stadelmann on 2016-07-19 03:15:03 EDT ---

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/

--- Additional comment from Pierre Ossman on 2016-07-19 03:31:41 EDT ---

Those references only covers grabbing the pointer, not the keyboard.

--- Additional comment from Christian Stadelmann on 2016-07-21 11:37:49 EDT ---

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

--- Additional comment from IanB on 2016-07-21 17:17:31 EDT ---



--- Additional comment from Christian Stadelmann on 2016-08-13 12:20:57 EDT ---

I've filed an upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=97333

--- Additional comment from Olivier Fourdan on 2016-09-01 03:02:56 EDT ---

(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

--- Additional comment from Fedora End Of Life on 2016-11-24 08:45:32 EST ---

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.

--- Additional comment from Dimitrios Apostolou on 2016-12-11 11:19:52 EST ---

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.

--- Additional comment from Scott Clark on 2016-12-30 11:27:34 EST ---

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)

--- Additional comment from Lucas van Vloten on 2017-01-08 17:08:23 EST ---

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.

--- Additional comment from Kamil Páral on 2017-01-09 08:10:03 EST ---

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.

--- Additional comment from Pierre Ossman on 2017-01-09 09:48:54 EST ---

I don't think that was the right gnome bug number. :)

--- Additional comment from Kamil Páral on 2017-01-09 10:03:30 EST ---

Ugh, thanks. Wrong tracker.

--- Additional comment from Andrey sPirtovicH on 2017-03-03 07:27:50 EST ---

The same problem when using Remmina and VMware-view Horizon.

--- Additional comment from Olivier Fourdan on 2017-03-23 10:21:53 EDT ---

https://lists.freedesktop.org/archives/wayland-devel/2017-March/033526.html

--- Additional comment from Pierre Ossman on 2017-03-27 06:38:18 EDT ---

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?

--- Additional comment from Olivier Fourdan on 2017-03-27 07:32:33 EDT ---

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

--- Additional comment from Pierre Ossman on 2017-03-27 10:11:10 EDT ---

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.

--- Additional comment from Olivier Fourdan on 2017-03-28 03:10:35 EDT ---

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

--- Additional comment from Olivier Fourdan on 2017-03-28 03:33:19 EDT ---

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.

--- Additional comment from David H. Gutteridge on 2017-04-27 16:29:36 EDT ---

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.

--- Additional comment from Attila Pinter on 2017-05-16 01:13:20 EDT ---

I have issues only when using virt-viewer/virt-manager over ssh (from Fedora25). Simple workaround is to install virt-manager on your host and add the other Qemu/KVM servers as a new connection. Did the magic for me. 

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/sect-Virtualization-Managing_guests_with_the_Virtual_Machine_Manager_virt_manager-The_open_connection_window.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Administration_Guide/chap-Virtualization_Administration_Guide-Remote_management_of_virtualized_guests.html