Mir 0.28

We are pleased to announce that Mir 0.28 has been released and is available in Ubuntu 17.10 (Artful).

As the content (and even the name) of this release has changed over the time we’ve been working towards it now is probably a good time to reflect on what it is, and what it isn’t after all.

What is in Mir 0.28?

There is now a stable server ABI

This simplifies the use of “Mir snaps” making it possible to release new library versions without breaking servers.

One of the barriers to the adoption of Mir has been the potential for Mir releases to break downstream projects that depend on a stable ABI. This is provided by libmiral, which is now part of Mir.

The Yunit project which uses Mir as part of its graphics stack has already started migrating code to use libmiral for this reason.

The start of Wayland support

The desktop community has adopted Wayland as the client-server protocol of choice for replacing X11. This is already supported by several server implementations (Weston, Kwin and Mutter are the best known). By providing Wayland support we will make Mir servers compatible with the various toolkits and libraries that already have Wayland backends.

Our MVP goal for Mir 0.28 has been to support a Wayland client with a single fullscreen surface. We have slightly exceeded this goal in 0.28 as you can see from this short video:

We will continue to expand on this Wayland support in future releases.

The MirAL shells are part of Mir

The miral-kiosk shell is used by the mir-kiosk-snap to provide graphics support on UbuntuCore. This release includes a number of improvements to miral-kiosk based on feedback from potential users.

The miral-shell is now the canonical example of writing a Mir server. We’ve dropped several older examples that used other APIs (and reworked mir_demo_server to fit the new server APIs).

There is a (currently unstable) API for “graphics platform” plugins

We had planned to stabilize the graphics platform API and ABI before publishing it but we had to change that plan. Canonical no longer has the infrastructure to test and maintain the “android platform”. However there is was interest from UBports both in continuing to support the “android platform” and for developing a “Wayland platform”.

What is NOT in Mir 0.28?

We have not upstreamed Mesa distro patches

These patches support “Mir EGL” which forms part of the Mir client API. With the adoption of Wayland (and Wayland EGL) it looks likely that these will not have a long term future and upstreaming a wasted effort.

This should also become less of an issue as it only affects EGL clients using the legacy Mir client APIs. Software rendering, Xmir and Xwayland clients will work without these patches.

I’ve seen some confusion about how Mir is supporting Wayland clients on the Phoronix forums . What we are doing is teaching the Mir server library to talk Wayland in addition to its original client-server protocol. That’s analogous to me learning to speak another language (such as Dutch).

This is not anything like XMir or XWayland. Those are both implementations of an X11 server as a client of a Mir or Wayland. (Xmir is a client of a Mir server or and XWayland is a client of a Wayland server.) They both introduce a third process that acts as a “translator” between the client and server.

The Wayland support is directly in the Mir server and doesn’t rely on a translator. Mir’s understanding of Wayland is going to start pretty limited (Like my Dutch). At present it understands enough “conversational Wayland” for a client to render content and for the server to composite it as a window. We need to teach it more “verbs” (e.g. to support for the majority of window management requests) but there is a limited range of things that do work.

Once Mir’s support for Wayland clients is on a par with the support for “native” Mir clients we will likely phase out support for the latter.

We’re still testing things prior to the Mir 1.0 release, and Mir 1.0 will not support “everything Wayland”. If you are curious you can install a preview of the current development version from the “Mir Staging” PPA.

Mir staging ppa

A few weeks ago I was reminded of the “Mir staging ppa” and saw that, with the discontinuation of Unity8 it had fallen into disuse. After considering deleting it I eventually removed some Ubuntu series that are no longer supported and added MirAL trunk.

That means that for Xenial, Zesty and Artful you can get the latest development version of Mir and MirAL like this:

miral-release ppa

Now for the Internet of Things we are using UbuntuCore16 and snaps, but occasionally it is useful to have debs too. For Mir it is easy to use the underlying 16.04LTS (Xenial) archive, but MirAL isn’t in that archive.

To make up for that I’ve created a “miral-release” ppa containing the latest release of MirAL built for both Xenial and Zesty. Vis:

Mir release 0.27/MirAL release 1.4

This is an interim development release of Mir and MirAL to Ubuntu 17.10 (Artful) that delivers many of the features that were work-in-progress when we needed to restructure the project. The Mir release notes are here: https://launchpad.net/mir/0.27/0.27.0.

The MirAL 1.4 release exposes a few new features and removes support for Mir versions that are no longer supported:

Support for passing messages to enable Drag & Drop

Support for client requested move

Port to the undeprecated Mir APIs

Added “–cursor-theme” option when configuring a cursor theme

Drop support for Mir versions before 0.26

There will be further Mir releases culminating in a Mir 1.0 release before the Ubuntu 17.10 (Artful) feature freeze in August.

The Past

The Mir project has always been about how best to develop a shell for the modern desktop. It was about addressing concerns like a security model for desktop environments; convergence (which has implications for app lifecycles); and, making efficient use of modern hardware. It has never been only about Unity8, that was just the first of (hopefully) many shells written using Mir. To that end, the Mir developers have tried to ensure that the code wasn’t too tightly coupled to Unity8 (e.g. by developing demo servers with alternative behaviors).

There have been many reasons that no other shells used Mir but to tackle some of them I started a “hobby project” (MirAL) last year. MirAL aimed to make it easier to build shells other than Unity8 with Mir, and one of the examples I produced, miral-kiosk, proved important to Canonical’s support for graphics for the “Internet of Things”. Even on the Internet of Things Mir is more than just a way of getting pixels onscreen, it also fits the security model needed. That secures a future for Mir at Canonical.

The Present

In Canonical the principle target for Mir is now Ubuntu Core, and that is currently based on the 16.04LTS. We’ve recently released Mir 0.26.3 to this series and will be upgrading it to Mir 1.0 when that comes out.

Outside Canonical there are other projects that are making use of Mir.

UBports is taking forward the work begun by Canonical to support phones and tablets. Their current stack is based on an old release of Mir (0.17) but they are migrating to Ubuntu 16.04LTS and will get the latest release of Mir with that.

Yunit is taking forward the work begun by Canonical on “convergence”. They are still in an exploratory phase, but the debs they’ve created for Debian Unstable use the current Mir 0.26 release.

As reported elsewhere there have been discussions with other projects who are interested in using Mir. It remains to see if, and in what way, those discussions develop.

The Future

For all of these projects the Mir team must be more responsive than it has been to the needs of those outside Canonical. I think, with the work done on MirAL, much of the technical side of that has been addressed. But we still have to prove ourselves in other ways.

There’s a new (0.27) release of Mir undergoing testing for release to the Ubuntu 17.10 series. This delivers a lot of the work that was “in progress” before Canonical’s focus shifted from Unity8 to miral-kiosk and marks the point of departure from our previous plans for a Mir 1.0. Mir 0.27 will not be released to other series, as we expect to ship Mir 1.0 in 17.10.

The other thing 0.27 offers is based on the efforts we’ve seen in UBports (and a PR from a former Mir developer that has joined the project): we’ve published the APIs needed to develop a “mir platform” out of the Mir source tree. That means, for example, developing a mir-on-wayland platform doesn’t require forking the whole of Mir. One specific platform that is now out-of-tree is the “mir-on-android” platform – from my experience with MirAL I know that having a real out-of-tree project helps prove things really work.

In addition, while we won’t be releasing Mir 0.27 to 17.04, I’ve included testing there, along with the Unity8 desktop to ensure that all the features required by a “real shell” remain intact.

Beyond Mir 0.27 the plan towards 1.0 diverges from past discussions. We are no longer planning to remove deprecated functions from the libmirclient ABI, instead we are working towards supporting Wayland clients directly.

In order to trace a problem[1] in the Mir stack I needed to build mesa to facilitate debugging. As the options needed were not entirely obvious I’m blogging the recipe here so I can find it again next time.

Mir 0.26.3 for all!

The significant thing with Mir 0.26.3 is that we are making this version available across the latest releases of Ubuntu as well as 17.10 (Artful Ardvark). That is: Ubuntu 17.04 (Zesty Zapus), Ubuntu 16.10 (Yakkety Yak) and, last but not least, Ubuntu 16.04LTS (Xenial Xerus).

This is important to those developing Mir based snaps. Having Mir 0.26 in the 16.04LTS archive removes the need to build Mir based snaps using the “stable-phone-overlay” PPA.

The changes at Canonical have had an effect both on the priorities for the Mir project and on the resources available for future development. We have been meeting to make new plans. In short:

Mir is alive, there are Canonical IoT projects that use it. Work will continue on Mir to support these and on cleaning and upstreaming the distro patches Ubuntu carries to support Mir.

Canonical are no longer working on a desktop environment or phone shell. However we will maintain the existing support Mir has for compositing and window management. (We’re happy to receive PRs in support of similar efforts.)

In previous posts I’ve alluded to the ecosystem of projects developed to support Unity8. While I have come across most of them during my time with Canonical I wouldn’t be confident of creating a complete list.

But some of the Unity8 developers (mostly Pete Woods) have been working to make it easy to identify these projects. They have been copied onto github:

Mir provides a framework for integration between three parts of the graphics stack.

These parts are:

The drivers that control the hardware

The desktop environment or shell

Applications with a GUI

Mir currently works with mesa-kms graphics, mesa-x11 graphics or android HWC graphics (work has been done on vulkan graphics and is well beyond proof-of-concept but hasn’t been released).

Switching the driver support doesn’t impact the shell or applications. (Servers will run unchanged on mesa, on X11 and android.) Mir provides “abstractions” so that, for example, user input or display configuration changes look the same to servers and client applications regardless of the drivers being used.

Because the work has been funded by Canonical features that were important to Ubuntu Phone and Unity8 desktop have progressed faster and are more complete than others.

When Mir was started we needed a mechanism for client-server communications (and Wayland wasn’t in the state it is today). We did something that worked well enough (libmirclient) and, because it’s just a small, intentionally isolated part of the whole, we could change later. We never imagined what a “big deal” that decision would become.

[added]

Seeing the initial reactions I can tell I made a farce of explaining this. I’ll try again:

For the author of a shell what Mir provides is subtly but significantly different from a set of libraries you can use to build on: It provides a default shell that can be customized.

Disclaimer: With the changes in progress at Canonical I am not currently in a position to make any commitment about the future of Mir.

It is no secret that I think there’s value to the Mir project and I’d like it to be a valued contribution to the free software landscape.

I’ve written elsewhere about my efforts to make it easy to use Mir for making desktop, phone and “Internet of Things” shells, I won’t repeat that here beyond saying “have a look”.

It is important to me that Mir is GPL. That makes it a contribution to a “commons” that I care about.

The dream of convergence dies hard. Canonical may have abandoned it, but I hope it survives. A lot of the issues have been tackled and knowledge gained.

I read that UBPorts will be using Mir “for the time being”. They sensibly don’t want to maintain Mir and are planning a migration to an (unidentified) Wayland compositor.

However, we can also see from G+ Mark Shuttleworth is planning to keep “investing in Mir” for the Internet of Things.

This opens up an interesting possibility: there’s no obvious technical reason that Mir could not support clients using libwayland directly. It would take some research to confirm this but I can’t foresee anything technical blocking such an approach.

There could be some benefits to Canonical from this: the current design of Mir client-server interation makes sense in a traditional Debian (or RPM) repository based world, but less so for Snap (or Flatpak).

In a traditional environment where the libraries are a shared resource updates simply need to maintain ABI compatibility to work with existing clients. That makes it possible to keep Mir server and client and server libraries “in step” while making incompatible changes to the communications protocol.

However with Snaps the client and server “snap”s package the libraries they use with the applications.That presents issues for keeping them in step. These issues are soluble but create an additional burden for Mir, server and client developers. Using a protocol based solution would ease this burden.

For the wider community native support for Wayland clients in Mir would make the task of toolkit maintainers and others simpler.

If Canonical could be persuaded to add this feature to Mir and/or maintain it in the project would anyone care?

We read in the press that Canonical has pulled out of the dream of “convergence”. With that the current support for a whole family of related projects dies.

That doesn’t mean that the dream has to die, but it does mean changes.

I hope the dream doesn’t die, because Canonical has done a lot of the “heavy lifting” – the foundations are laid, the walls are up, we have windows, plumbing and power. But we’re lacking the paintwork and there’s no buyer.

My expertise is developing working software and I’m going to donate some of that to the dream.

Stable Intermediate Forms is an important principle – keep things working while making changes. If you throw away a large chunk intending to replace it you’ll find re-integration really, really hard. Do things gradually!

So, don’t simply fork Unity8 and plan to get it working on Wayland. You’ll end up with a single wall that falls over before you’ve replaced the rest of the building. (Sorry, I went back to “metaphor”.)

Take the whole infrastructure etc. and keep it in place until any replacements are demonstrably ready.

The Elephant in the room

Many have issues with the way Mir has been presented to the community, but in the opinion of the developers it is a good piece of software and not inherently incompatible with Wayland. (Just look at what the developers have written about it especially the early posts that addressed this directly.)

There are two plausible evolutions of the dream that reconcile Mir with Wayland.

Plan 1: (my recommendation) Add support to libmirserver for Wayland clients in parallel to the existing protocol. Once this is working this either junk libmirclient or rework its interaction with libmirserver.

Plan 2: Implement an analog of QtMir/MirAL on your choice of Wayland server. Then transition Unity8 to these and junk Mir.

I can’t guarantee that my recommendation of “plan 1” isn’t biased by my history with the Mir project, clearly I know its potential better than that of competing projects and I would find developing these easier than someone new to the code. In then end, the choice will depend on who takes on the work and what they can achieve most effectively.

There’s a bugfix MirAL release (1.3.2) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

The bugfixes in 1.3.2 are:

In libmiral a couple of “fails to build from source” fixes:

Fix FTBFS against Mir < 0.26 (Xenial, Yakkety)

Update to fix FTBFS against lp:mir (and clang)

In the miral-shell example, a crash fixed:

With latest zesty’s libstdc++-6-dev miral-shell will crash when trying to draw its background text. (LP: #1677550)

Some of the launch scripts have been updated to reflect a change to the way GDK chooses the graphics backend:

change the server and client launch scripts to avoid using the default Mir socket (LP: #1675794)

There’s a bugfix MirAL release (1.3.1) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

Unsurprisingly, given the project’s original goal, the ABI is unchanged.

The bugfixes in 1.3.1 are:

In libmiral a focus management fix:

When a dialog is hidden ensure that the active window focus goes to the parent. (LP: #1671072)

In the miral-shell example, two crashes fixed:

If a surface is deleted before its decoration is painted miral-shell can crash, or hang on exit (LP: #1673038)

Mir is continuing to make progress towards a 1.0 release and, meanwhile, Zesty Zapus (Ubuntu 17.04) is continuing to make progress towards final freeze.

Currently the version of Mir in Zesty is 0.26.1 and we’re not planning any major changes for the 17.04 series. We’re probably going to make a bugfix release (0.26.2). The other possibility is that work on supporting hybrid graphics is completed in time for adequate testing for 17.04. In the latter case we’ll be releasing Mir 0.27 to get that shipped.

For this and other reasons it isn’t yet clear whether there will be a 0.27 release before we move to 1.0.

The significance of a 1.0 release is that it will be the time we break the mirclient ABI and delete a lot of deprecated APIs, which will have a significant effect on downstream projects. We’ve tried to prepare by marking the deprecations in 0.26 and updating downstream projects accordingly. But while this preparation means that most downstream projects “only need recompiling” this is something we want to do at the start of a release cycle, not at the end.

The argument for a 0.27 release is that there is functionality we want to release and that this can be done without the disruption of an ABI break. So even if we don’t release 0.27 for 17.04 we may well do so once 17.10 is “open” in order to make this work available for Unity8 developers to use.

Either way, sometime early in the 17.10 cycle we’re going to release Mir 1.0. This will clear the way for Mir support in Mesa and Vulkan.

I got drawn into a discussion today and swiftly realized there is no right answer. But there should be!

The question is deceptively simple: Which order should graphics toolkits probe for backends?

My contention is that the answer is: “it depends”.

Suppose that I’m running a traditional X11 based desktop and am testing with a new technology (obviously Mir, but the same applies to Wayland) running as a window on top of it. (I.e. Mir-on-X or Wayland-on-X)

In this case I want any new application to *default* to connecting to the main X11 desktop – I don’t want my test session to “capture” any applications launched normally.

Now suppose I’m running a new technology desktop that provides an X11 socket as a backup (Xmir/Xwayland). In this case I want any new application to *default* to connecting to the main Mir/Wayland desktop – only if the toolkit doesn’t support Mir/Wayland should it connect to the X11 socket.

Now GDK, for example, provides for this with GDK_BACKEND=mir,wayland,x11 or GDK_BACKEND=x11,mir,wayland (as needed). But that is only one toolkit: OTTOMH Qt has QT_QPA_PLATFORM and SDL has SDL_VIDEODRIVER. (I’m sure there are others.)

What is needed is a standard environment variable that all toolkits (and other graphics libs) can use to prioritize backends. One of my colleagues suggested XDG_TOOLKIT_BACKEND (working much the way that GDK_BACKEND does).

That only helps if all the toolkits take notice. Is it worth pursuing?

There’s a new MirAL release (1.3.0) available in ‘Zesty Zapus’ (Ubuntu 17.04) and the so-called “stable phone overlay” ppa for ‘Xenial Xerus’ (Ubuntu 16.04LTS). MirAL is a project aimed at simplifying the development of Mir servers and particularly providing a stable ABI and sensible default behaviors.

Unsurprisingly, given the project’s original goal, the ABI is unchanged.

The changes in 1.3.0 fall are:

Support for “workspaces”

This is part of the enabling “workspaces” for Unity8 desktop. MirAL doesn’t provide fancy transitions and spreads, but you can see some basic workspace switching in the miral-shell example program:

$ apt install miral-examples
$ miral-app

There are four workspaces (corresponding to F1-F4) and you can switch using Meta-Alt-[F1|F2|F3|F4], or switch taking the active application to the new workspace using Meta-Ctrl-[F1|F2|F3|F4].

Support for “previous window in application”

You can now use Alt-Shift-` to switch to the previous in an application.

miral-shell adds a background

miral-shell now uses its background for a handy guide to the available keyboard shortcuts.

Bug fixes

Two bug fixes related to shutdown problems: one deals with a possible race in libmiral code, the other works around a bug in Mir.