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:
- If $DISPLAY is not set, search for the socket and (if found) set $DISPLAY
- If $DISPLAY is still not set, create it using Xwayland
- 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:
- Create x11 socket and listen for events
- On an event spawn an Xwayland instance letting it handle the socket
- Connect as a X Window Manager
- When Xwayland exits goto 1
- When closing, terminate any Xwayland instance
Until the logic required by 3 can be implemented, Xmir could be used as a stop-gap.