Supporting X11 clients on Mir servers

Documentation Mir Docs
1

Disclaimer

I’ve been involved in a series of discussions this week about how X11 applications should be supported by Mir servers. It’s obviously a “hot topic” as it’s been discussed by overlapping groups of people in the context of UBports, the feasibility of migrating MATE to Mir and “Core” snaps running on mir-kiosk.

This document is based on my notes and is not (at least not yet) a definitive conclusion.

Xwayland and Xmir

There are two existing technologies for supporting X11 applications on Mir servers: Xmir and Xwayland. Both are X11 servers implemented on top of a host shell. The differences:

  • Xwayland uses wayland to connect to the host shell and relies on an external X window manager. There’s a good explanation of Xwayland here.

  • Xmir uses libmirclient to connect to the host shell and implements some simple window management.

Historically, in Unity8 Canonical was running an Xmir instance for each X11 application so as to provide stronger isolation between applications. The experience from UBports is that this is more trouble than it is worth.

Internet of Things

Our approach to IoT is based on “snaps” and using the mir-kiosk snap as the display server. The Wayland protocol is a good fit for this and our recommended approach for client snaps. (While we contine to support Mir’s protocols for existing users we don’t wish to encourage it for the future.)

“Classic” snaps of X11 client applications on an X11 desktop can (and should) simply pick up and access $DISPLAY from the host environment, but that doesn’t happen with “confined” snaps on “core”. On core there is a proposal for confined snaps to provide an X11 server, but clients will have to search for the socket in a “standard place” and set $DISPLAY.

We don’t want to encourage the use of X11 on IoT, but recognise we must enable applications that do not (yet) support Wayland directly.

Our current thinking is that mir-kiosk will not support X11 connections, and that client applications needing X11 will need to provide their own. Their startup logic should be:

  1. If $DISPLAY is not set, search for the socket and (if found) set $DISPLAY
  2. If $DISPLAY is still not set, create it using Xwayland
  3. Run the application

In the “core” environment targeted by mir-kiosk the isolation of the X11 server in the client snap is not an inconvenience and limits the potential for security issues related to this protocol.

Desktop (also tablet and phone)

We don’t want to encourage the use of X11 on desktop, but recognise we must enable applications that do not (yet) support Wayland directly.

On desktop the prior art (other Wayland servers) and feedback from UBports is that a single X11 server should be servicing the desktop. The security issues arising from X11 are recognised as unavoidable.

Our experience with Xmir tells us that implementing an X Window Manager client-side is problematic as there can be a lack of context when interpreting events. The solution is to either provide this context through a privileged protocol or to embed the X Window Manager into the server.

Support for X11 clients should be available to all Mir based servers on request. (It is something that we don’t want for some scenarios (e.g. miral-kiosk), and something that can hopefully go away eventually.) That means it should be either be part of MirAL (or an additional support library).

The server logic should be:

  1. Create x11 socket and listen for events
  2. On an event spawn an Xwayland instance letting it handle the socket
  3. Connect as a X Window Manager
  4. When Xwayland exits goto 1
  5. When closing, terminate any Xwayland instance

Until the logic required by 3 can be implemented, Xmir could be used as a stop-gap.

2

Some more notes

(from more detailed discussion)

To work well with Xwayland we need the to provide an option to integrate an X11 Window Manager into Mir. This shouldn’t be compulsory as we don’t intend to use it for mir-kiosk. (A “desktop” shell may also chose to be “Wayland only”.)

At a high level, Mir needs the capability to offer an X11 endpoint, monitor it and fork/exec an Xwayland client if a client connects to it. I envisage it being supplied as an option:

    $ miral-shell --x11-desktop :0

When forking Xwayland Mir must supply a socket connected to a X Window Manager [Xwm] that integrates X11 window management with the rest of Mir.

Once the Xwayland service is started, the system architecture for supporting X11 looks like this:

Mir-X11-overview
Mir-X11-overview1058×794 52 KB

There are two channels for communication from the Xwayland process, a Wayland connection that conveys the surfaces and associated buffers and an X11 connection that handles window management requests.

Mir can already handle the Wayland connection and display surfaces, what is lacking is any of the information required for effective window management.

X11 applications can annotate surfaces to inform the Window Manager how they should be handled. We have experience translating this to Mir concepts in Xmir, so where this information is provided we can do the same in the server. This be entirely transparent to Mir’s window management.

However, X11 applications can set the override-redirect flag to also opt out of Window Management and place their own surfaces. This means that these applications need information about screen content that is not made available to Wayland (or legacy Mir) clients.

The Xwm support therefore also needs access to this information from the Mir “scene” and to make it available via X11. So this is how this feature integrates into libmirserver:

Mir-X11-detail
Mir-X11-detail1058×794 43.6 KB

X11 surfaces that “opt out” of window management will be (mostly) invisible to Mir’s Window management (although clearly they exist in the scene as seen by Xwm and compositing).

2 Likes
3

Provided that the EGLStreams Xwayland code lands in Xorg Server 1.20, do you foresee your Xwayland approach allowing the NVIDIA proprietary driver to work with XWayland on Mir?

4

There’s still some work needed to integrate Mir’s EGLStreams support with Wayland. Once that is done then Xwayland support for EGLStreams would enable X11 clients.

2 Likes
5

Once we hook the up the EGLStream extension, the Xwayland code will work.

However! I think you may be underwhelmed by the results; by my reading of the Xwayland EGLStream patches that just fixes glamor support - ie: 2D operations can be hardware-accelerated, rather than all software rasterising, all the time. Unless I’m misunderstanding their scope, those patches do not enable GLX clients to work.

1 Like
6

Yep, I’m under the impression that the Xwayland EGLStream patches are far from ideal. But, provided the patches at least marginally improve the Xwayland situation (which, hopefully, will only be needed on rare occasions), I will be grateful. :slight_smile: