Mir related ppas

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:

sudo add-apt-repository ppa:mir-team/staging
sudo apt-get update
sudo apt-get upgrade

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:

sudo add-apt-repository ppa:alan-griffiths/miral-release
sudo apt-get update
sudo apt-get upgrade

 

Mir release 0.27

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.

Mir: the new order

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.

making-mesa

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.

$ apt source libgl1-mesa-dri
$ cd mesa-17.0.3
$ QUILT_PATCHES=debian/patches/ quilt push -a
$ sudo mk-build-deps -i
$ ./configure --with-gallium-drivers= --with-egl-platforms=mir,drm,rs
$ make -j6
$ sudo make install && sudo ldconfig

[1] The stack breaking with EGL clients when the Mir server is running on a second host Mir server that is using the mesa-kms plugin and mesa is using the intel i965 driver. (LP: #1699484)

Mir release 0.26.3

Mir 0.26.3 for all!

By itself Mir 0.26.3 isn’t a very interesting release, just a few minor bugfixes: [https://launchpad.net/mir/0.26/0.26.3]

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.

Fairer than Death

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.)

unity8-team

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:

https://github.com/unity8-team

This is simply a snapshot for easy reference, not the start of another fork.

Why Mir

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

These parts are:

  1. The drivers that control the hardware
  2. The desktop environment or shell
  3. 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.

Mir supports writing a display server by providing sensible defaults for (e.g.) positioning tooltips without imposing a desktop style. It has always carried example programs demonstrating how to do “fullscreen” (kiosk style), traditional “floating windows” and “tiling” window management to ensure we don’t “bake in” too many policies.

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.

A new hope

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?

Is anyone else willing to help with such a feature?

The end of a dream?

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.