Guest
on 17 January 2017
This is a guest post by Alan Griffiths, Software engineer at Canonical. If you would like to contribute a guest post, please contact [email protected]
2016 was a good year for Mir – it is being used in more places, it has more and better upstream support and it is easier to use by downstream projects. 2017 will be even better and will see version 1.0 released.
Uses of Mir
Mir support and development has continued on the two graphics stacks used by Ubuntu phone and desktop (i.e. “android” drivers and “freedesktop”). In the course of 2016 the Mir based Unity8 shell has been released as a “preview”; and, the Mir based miral-kiosk has also been enabled on the snap-based Ubuntu Core.
For the “preview” of the Unity8 Mir server on desktop – see here.
For Mir on Ubuntu Core – see here.
Developing with Mir
There are three ways which developers might wish to work with Mir:
1.Enabling a client-side toolkit, library or application to work on Mir
2.Creating a Mir based system compositor or shell
3.Enabling Mir on a new platform
Initially each of these ways of using Mir has been the province of Canonical developers. Partly because Mir is developed by Canonical, but mostly because it has been a moving target.
But that isn’t the long term goal, we want all of these uses to be possible for downstream projects. And we have been making progress: most of what we want to deliver to support the first two categories is ready and will ship in Ubuntu 17.04.
Enabling a client-side toolkit, library or application to work on Mir
In July 2015 we released Mir 0.14 which was the point at which we stabilized the “toolkit” ABI needed to work on client-side toolkits etc. Since then we’ve extended the API, but have maintained ABI compatibility.
In the course of 2016 we’ve built on this and upstreamed Mir support into GTK3, Qt, SDL2 and kodi. (Ubuntu also carries a patch for SDL1.2.)
The testing of toolkit work has been facilitated in 2016 by the development of miral-shell example server. This supports the testing and debugging of basic window management facilities. There’s a brief introduction to testing with miral-shell here and debugging here.
In the process of this work we have identified some potential improvements to the API. We are in the process of landing the improved APIs and deprecating the old ones. At some point this year we will be removing the deprecated APIs (and consequently breaking ABI for hopefully the final time).
Creating a Mir based system compositor or shell
The mirserver ABI causes problems for downstreams because ABI compatibility been broken routinely. At a minimum downstream projects have needed to rebuild for each Mir release and often also needed code changes to adapt to API changes.
In October 2016 we released MirAL to provide a stable ABI for developing Mir servers. Because MirAL depended upon some fundamental types created in Mir there was initially some ABI instability (in libmircommon).
That smaller ABI instability has now (December 2016) been addressed with the Mir 0.25 release. Mir 0.25 moved these “fundamental” types to a new library (libmircore) for which we can and will maintain ABI compatibility. At the same time we also released MirAL 1.0 (also breaking ABI) to clean up a few small issues. We intend the libmircore and libmiral server ABIs to retain ABI compatibility going forwards.
The QtMir project that Unity8 uses as an abstraction layer over Mir has also been migrated to libmiral to benefit both from the ABI stability and the basic window management defaults provided by libmiral.
There’s a starter guide to writing a Mir-based “Desktop Environment” here.
Enabling Mir on a new platform
There are at least three categories of “new platform” where developers might try to enable Mir.
1. New phone hardware/android drivers
2. A non-Ubuntu mesa distribution
3. A new graphics API
For all three categories the support is a “work-in-progress” and not yet ready for use downstream. That should change this year.
Enabling Mir on new phone hardware/android drivers
Diagnosing and fixing problems found with running Mir on android based hardware typically need debugging the driver interaction and updating the Mir “graphics-android” plugin module to accommodate variations in the way the driver spec has been interpreted by the vendor. Patches are welcome.
Enabling Mir on a non-Ubuntu mesa distribution
Ubuntu currently carries a “distro patch” for mesa to support Mir. Work is planned for this year to update and then upstream this patch. We’ve not done so yet as we know there are changes needed to support current developments (such as Vulkan).
There are instructions available for getting the current version of the Mesa “distro patch” here.
Enabling Mir on a new graphics API
To enable Mir on a new graphics API (such as Vulkan) requires the development of a Mir plugin module. We are working on Vulkan support and that work has led to a better understanding of how these plugins should integrate into Mir.
The APIs needed to develop platform plugin modules are currently neither stable enough for downstream developers, nor available as published headers in a Mir package that would support out-of-tree development. That should change this year.
Looking forward to 2017
As mentioned above, 2017 will see a cleanup of our “toolkit” API and better support for “platform” plugin modules. We will then be working on upstreaming our mesa patch. That will allow us to release our (currently experimental) Vulkan support.
We’ve also been working on reducing latency but the big wins didn’t quite make the end of 2016. There’s a snapshot of progress here.
As we complete these changes, 2017 will see a Mir 1.0 release.
