Mir News: 28th September 2018

Mir
1

Mir News

At the end of last week we released Mir 1.0 and took a rest from reporting “Mir News” but we’re back again now!

IoT

Those that have been following closely will know that the main focus of this release has been support for graphics snaps on IoT devices running Ubuntu Core. Along with the release announcements we’ve updated and added to the tutorials for creating graphical snaps for IoT:

I also collated some notes about configuring mir-kiosk and that kicked off some discussions on IRC about interaction with “gadget snaps” and ensuring that these can effectively set up the display configuration. The resulting enhancements have just landed and will soon be available in the snap store.

Availability

In addition to Ubuntu’s ppa:mir-team/release Mir 1.0 is currently available in the AUR for Arch and the Fedora 29 and rawhide archives.

@raof is working on getting Mir 1.0 into the Ubuntu archive, the state of the 18.10 release means that this yet hasn’t completed. And @tsimonq2 is working on getting it into Debian.

We’ve also received the first PRs (#615 and #616) from PostmarketOS developers following their success getting Mir to run on Alpine Linux.

Desktop

@sophie-w has been working with the MATE developers to get the MATE panel working with Wayland (and Mir). This is a first step towards getting the MATE desktop environment working on Mir. There’s a still long way to go with this but the forst steps are being taken.

What is Mir?

I’ve seen and heard significant confusion in the reports of the Mir 1.0 release. I don’t know if I can fix this, but I’ll have a go…

A server supports the user shell:

  • libmiral Mir provides an API for building a shell/display server/compositor that started life as part of Canonical’s vision of “convergent computing”.

    • It supports writing shells that work across a range of hardware configurations.

    • These shells (like existing desktop environments such as Gnome, Unity or MATE) are useless without client applications.

Clients need to talk to the server:

  • libmirclient When we started work on Mir we chose to implement a client API (libmirclient) for these clients to work to.

    • There are pros and cons to this approach but it required client “toolkits” to adopt this library and that didn’t work out. Instead the toolkit projects adopted an alternative approach based on Wayland.

    • We don’t advise anyone to write new client code using this API, but we’ve not removed it yet (and there are projects that have not yet eliminated this from their code).

    • That code makes up about 10% of the Mir codebase.

  • Wayland is a protocol, and set of “extension protocols” clients can use to talk to the server.

    • These protocol extensions can be standard, stable extensions (likely to be supported by several servers) or non-standard and/or non-stable extensions that may be specific to a particular desktop.

    • Mir’s support for Wayland around 10% of the Mir codebase.

If you’re writing a client based on libmirclient: STOP!!! Instead, write a client based on Wayland and then you can use it with Mir, wlroots, KWin, Mutter, weston, etc.

You only need to care about Mir APIs if you’re writing a shell based on Mir: then you have to care about the libmiral API.

If you’re not writing servers nor clients then you can use applications that support Wayland with any Mir server.

3 Likes