Keys can't be grabbed under Wayland

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

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.

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

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.

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

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.

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://<email address hidden>/thread/BBPOOC4GVBJXHLKSSFLGERG6GYAU6M6U/

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

(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://<email address hidden>.
> 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://<email address hidden>/thread/BBPOOC4GVBJXHLKSSFLGERG6GYAU6M6U/ or https://lists.freedesktop.org/mailman/listinfo/wayland-devel either.

*** Bug 1353422 has been marked as a duplicate of this bug. ***

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

(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

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.

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.

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)

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.

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.

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

Ugh, thanks. Wrong tracker.

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

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

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?

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

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.

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

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.

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.

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

Fixed with native Wayland apps, x11 fix pending review/merge.

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?

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

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

It works for me after upgrading to Fedora 27 (gnome-boxes)

Thanks very much.