While the Mir team is no longer as active in the Unity8 project as we once were, we are happy they are using Mir and are planning to upgrade to the latest version in the near future. As we’ve been involved in a number of conversations about different aspects of this I’m taking a moment to write about how we see this going from the Mir perspective and what we can do to help.
I’m going to address three topics:
- Updating to Mir 1.x
- Updating Mir-on-Mir
- Updating to Wayland
I think this is the order in which they should be tackled. Certainly, the first item should be migrating to the current, supported, release of Mir.
None of what I describe below conflicts with what the Mir team wants to achieve, we are supportive of efforts to achieve it.
Updating to Mir 1.x
We’ve been careful in our work on Mir to avoid unnecessarily breaking things that Unity8 is using. That means that the legacy mirclient APIs still work and that we still support Mir-on-Mir on 16.04LTS. The only thing we “broke” was to drop the “android graphics platform” from our source tree.
The “android graphics platform”
Because we no longer had access to the hardware to test and maintain this code, we dropped it from the project. But we didn’t abandon UBports - we co-operated with them to ensure that they could take it over and build it as a separate project.
This “android graphics platform” project is affected by the changes in Mir, and, in development, it has been updated to work with Mir 1.1. (I understand that this work isn’t quite complete because “Mir-on-Mir” doesn’t yet work on all of the different phones they support.)
Moving Ubuntu Touch to Mir 1.x brings a number of benefits, it is faster, it is supported, and it enables the changes discussed below.
On the phone, Unity8 uses “Mir-on-Mir” to allow Unity System Compositor to manage the hardware and switch between the greeter and user sessions.
“Mir-on-Mir” is implemented by some ancient code In the depths of Mir that supports Mir acting as a (mirclient API) client of a Mir server. Like many uses of Mir’s mirclient API this requires EGL support in the driver to be implemented via the mirclient API.
In 16.04LTS this EGL support is implemented in Mesa as a distro-patch by Canonical. If there had been minimal work involved we would have maintained the patch in 18.04LTS, but there were changes to Mesa that made this impractical. As a result, this patch is not available in later versions of Ubuntu, and has never been available on other distros nor for other drivers. (Such as Mali: Although the Mir team hasn’t released (or even integrated) support for Mali yet, the UBports developers have found the work we’ve done useful for their pinephone development. See Mir news: 11th January 2019.)
Using Mali, Nvidia, or (on any distro except Ubuntu 16.04LTS) Mesa means that “Mir-on-Mir” doesn’t work, and that has implications for running Unity-System-Compositor.
While we’ve kept this code working for 16.04LTS and Mesa it clearly needs rework or replacement to use Wayland for use on other configurations. This hasn’t been a priority for the Mir team as we’re not using it at present.
This Mir-on-Mir code is the same in Mir 0.24 and Mir 1.x and isn’t (apart from the issue mentioned above about updating the android graphics platform) affected by the change. However, rewriting it to use Wayland would only be possible on recent versions of Mir which have support for Wayland.
Updating to Wayland
Using the mirclient API is also largely restricted to the phone and Mesa on 16.04LTS because GL rendering, like “Mir-on-MIr” depends upon Mir-EGL. That is a limitation on other distros, and other drivers.
The natural solution is to switch to Wayland and, with a recent Mir version, that can work for a lot of applications. However, Unity8 and the associated applications used by Ubuntu Touch also make use of Mir features designed to support “Convergence” and the security model Canonical designed for the phone.
This means that it isn’t possible to switch to everything Wayland without additional work. On the current phones that doesn’t matter for moving to Mir 1.x, as the mirclient APIs are still available and supported, but in the longer term there needs to be a way to support any features that prove necessary through Wayland. Fortunately, Wayland is designed to support protocol extensions and I would recommend this as the way forward.
Mir doesn’t (yet) have a clean API for adding Wayland protocol extensions in a server and, in any case, those that are needed by Ubuntu Touch are simply exposing existing Mir functionality. So, once the necessary protocol extensions are identified, the Mir code is the place to implement them.
A prerequisite for adding Wayland extensions is Wayland support in Mir, and that requires a recent version of Mir.