Skip to content

WIP: Xwayland xdg portal

Olivier Fourdan requested to merge ofourdan/xserver:xwayland-xdg-portal into master

XDG portal support for Xwayland

This comes after some (somehow opinionated) discussions around XTEST support in Xwayland as part of !431

Xwayland being a Wayland client, it has no control over the input devices, and therefore cannot actually move the pointer or send keystokes.

But XTEST would still work among X11 clients (only it wouldn't actually move the pointer has it has no control over it) which makes it somehow confusing.

There are Wayland protocols proposed and being reviewed in wayland-protocols for virtual input devices, but those protocols are not approved yet and some desktop such as GNOME do not want to support such protocols.

What we already have, though, is the RemoteDesktop portal API, but X11 clients would need to be modified to support it and some legacy clients are less likely to be changed solely for Xwayland.

What this MR does is to add support for the XDG Portal API directly into Xwayland and wire that to the XTEST code so that legacy X11 clients using XTEST can still work in Xwayland and automatically benefit from the the new portal API.

How does this work?

The portal API is based on D-Bus. Luckily, the xserver already has some support for D-Bus (for logind and HAL) so this MR adapts and reuses that infrastructure.

The somehow tricky part is to implement support for the portal API using solely the low level D-Bus API, because the Xserver doesn't have the luxury to used higher level API such as GIO/gdbus.

Known limitations

  1. Currently, the RemoteDesktop API requires a ScreenCast session for absolute pointer motion events.

I see two problems with this for the use case here:

  • A user running an X11 clients using XTEST would be prompted with a screen-cast dialog, asking to select which monitor to share, which seems confusing and completely off topic for the use case here
  • The ScreenCast API is limited to a single output, so that would not work with a dual-head setup anyway

So for now, the implementation uses only a RemoteDesktop session, and tries to emulate absolute motion events by computing the relative motion, but that works only when the current pointer location is known to Xwayland, i.e. only when the pointer is placed on top of an X11 window.

  1. The API states that a org.freedesktop.portal.Session::Closed signal is sent when the session is closed from the service side. While I can see the equivalent mutter signal org.gnome.Mutter.RemoteDesktop.Session::Closed being sent in dbus-monitor, I do not see the org.freedesktop.portal.Session::Closed signal being emitted.

I filed https://github.com/flatpak/xdg-desktop-portal/issues/508 for this

  1. Sending RemoteDesktop requests while the session is closed on the service side crashes the xdg-desktop-portal-gtk.

I filed https://github.com/flatpak/xdg-desktop-portal-gtk/issues/319 for this.

  1. mutter-3.36.2 introduced a regression and would simply ignore RemoteDesktop request if there is no Screencast session associated. This issue is still present in mutter-3.36.3. Bsically, none of this works with mutter-3.36.2 or mutter-3.36.3.

I filed https://gitlab.gnome.org/GNOME/mutter/-/issues/1307 and sent a fix https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1338 which has been accepted.

Other considerations

I am aware that some projects are strongly against the use of D-Bus, this is not forcing D-Bus on anyone.

If there is no portal available, Xwayland will behave exactly like before. All D-Bus queries are non-blocking so this won't introduce any significant slow down at start-up.

Moreover, the portal API is not invoked unless there is a XTEST request issued, so with the vast majority of X11 clients, that won't make any difference.

At last, once the Wayland protocols for virtual device get approved in wayland-protocols, the hooks used her eto wire XTEST to the portal API can be reused to call the relevant Wayland protocols. Again, this is not forcing D-Bus on anyone.

Demo

Here follows a small screencast of an older version of this branch that demonstrates how it behaves, using xdotool [^1] to generate relative motion events with XTEST.

Xwayland_XDG_Portal_integration

[^1] For absolute motion events, xdotool uses the core X11 protocol XWarpPointer so only reltive motion events can be tested with `xdotool.

Merge request reports