Can you please elaborate of what exactly has been backported and the resulting patches?

Which Wayland compositor do you use?

It's worth noting that the xwayland patches in themselves won't make a difference *unless* the Wayland compositor implements the corresponding protocol, and I am aware of none for now (the patch for mutter is still pending).

The Ubuntu diff is
http://launchpadlibrarian.net/334552966/xorg-server_2%3A1.19.3-1ubuntu3_2%3A1.19.3-1ubuntu4.diff.gz

it looks like the backported commits are 

xwayland-pointer-confine.diff
+d5e2f271ad93e50 xwayland: Remove two unused proc pointers.
+ca17f3e9fd3b59f xwayland: Lock the pointer if it is confined and has no cursor
+513e3bd3870fdb8 xwayland: Update root window size when desktop size changes
+fafdb0cc9697eb5 xwayland: "Accept" confineTo on InputOnly windows
+c217fcb4c4640ff xwayland: Allow pointer warp on root/None window

xwayland-add-grab-protocol-support.diff
https://cgit.freedesktop.org/xorg/xserver/commit/?id=0a448d133

Ubuntu doesn't have any compositor change, it's standard GNOME 3.24 so there is must be something wrong and it does make a difference without implementing the protocole.

Note that reverting 0a448d133 does fix the issue

Tried reproducing the issue with the arrow keys using the current Xwayland from master with mutter/gnome-shell from master, using qemu-kvm with SDL backend (-display sdl) but failedto reproduce, all keys (including the arrow keys) work fine in the guest.

Created attachment 133910 [details] [review]
Test patch

Can you try the attached patch (this is for testing purpose *only*) and report back if that makes any difference?

With this patch, if the compositor has no support for Xwayland keyboard grab protocol as you said you haven't in Ubuntu, Xwayland won't set up its grab handler at all.

the patch doesn't seem to make a difference

Well, what this patch does is disabling any specific grab handler if the Xwayland grab protocol is not available, by postponing the setup of those handler until Xwayland can bind to the relevant interface as advertised by the compositor.

If the compositor doesn't support the Xwayland grab protocol, then all those routines are not "enabled" in Xwayland, I don't see how they could break anything if not used...

Unfortunately, we cannot tell whether or not the compositor supports the Xwayland grab protocol using something like weston-info because, for security reasons, the compositor will (should) only advertiset he given protocl to Xwayland alone and hide it to any other client.

So, if that patch makes no difference, it means that:

 - The Wayland compositor claim to support Xwayland grab protocol but is buggy and doesn't send all key events as expected

 - Or the problem is completely unrelated to this patch.

So next step for you is to:

 - Check the actual patches applied to mutter in Ubuntu
 - Check what happens at the protocol level

To do so, yo can use the envvar WAYLAND_DEBUG prior to start gnome-shell (which will spawn Xwayland) so that we can tell what globals are listed in the wl_registry and see if "zwp_xwayland_keyboard_grab_manager_v1" is one of them.

e.g., from a console:

  $ WAYLAND_DEBUG=1 dbus-run-session -- gnome-shell --display-server --wayland |& tee ~/wayland-debug.log

The wl_registry globals will be listed at the beginning of the log so that should be enough to tell if the compositor claims to be supporting "zwp_xwayland_keyboard_grab_manager_v1".

Then, you can start qemu-kvm as usual and try to press the keys that do not work, those will be captured in the log as well, so we can tell if the compositor sends those key events to the client (Xwayland, in which case the problem lies in Xwayland) or not (in which case the problem lies in the compositor).

Please attach the "wayland-debug.log" to this bugzilla once you've performed those tests (but make sure you don't type any sensitive data in any application while the log is being captured as any key event will be logged).

the issue isn't there when using your debug command but it begins in that session if gsd-media-keys is started... I'm calling it a week now but I'm going to poke to it a bit more on monday

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/706.