2021: The year of the Lomiri desktop environment?

[alan_g]

At the beginning of 2021

The last year saw various developments around Lomiri, including an alpha of Lomiri on Manjaro.

There is also ongoing work to get Lomiri into Debian and people are trying to build it on Fedora.

My own project, Mir, is important to Lomiri because it provides the low level management of input and output devices, the communication between the desktop environment and apps, portability across different graphics stacks and the basic elements of window management.

However, over the year Mir has been progressing along a related but separate path. This includes several improvements to the graphics driver support that Lomiri needs to work well on Pinephone and improvements to the support of "desktop" applications (including X11) that Lomiri needs for the desktop.

Because Mir needed to drop support for some "legacy" APIs that Lomiri still uses we need to bring Mir and Lomiri together again. (Essentially, Lomiri needs to "move to Mir 2.0".)

The plan

Towards the end of last year I outlined the approach needed to enable Lomiri to use the latest developments in Mir. The plan is essentially to move some code from part of Lomiri (called QtMir) to a new library in Mir (called Miroil).

I followed that post with some notes on how to set up a development environment in which changes to QtMir and Mir can be tested. I also figured out that the best place to make progress is by incrementally moving the code between QtMir and Miroil based on the xenial_-_edge_-_wayland_-_mir18 branch of QtMir and the v1.8.1 version of Mir.

By sticking to Mir 1.x and adding Miroil to that this allows for incremental development before the big jump to Mir 2.x.

The tactics

I've set up a Github project MirOil-for-Lomiri with forks of Mir and QtMir for working on. I'm not going to have time to do much more work on these and would welcome some assistance.

The task at hand is to tidy up the code in QtMir under src/platforms/mirserver/ so that it provides an API to the rest of QtMir suitable for incorporation into Miroil. That means removing from that API any references to Qt or the mirserver or mirclient APIs.

After this the code gets moved to Miroil. There's currently around 8000 lines of code here, so this isn't an enormous project, and because of the way QtMir fits into the Lomiri stack this can be worked on and tested in isolation.

Once this is complete, then I can get Miroil incorporated into a Mir 1.9 release (and into Mir 2.x). That will enable UBports to incorporate just the QtMir changes while using Mir 1.x and migrate to Mir 2.x in due course.

Any volunteers?

I'm happy to help with getting volunteers set up and working, to add them to the github project and provide guidance. But I will be limited to a couple of hours a week in which to do this stuff and won't achieve much by myself.

[Emphrath]

@alan_g I'm real sorry but aren't we supposed to go full wayland anyway ?

[alan_g]

@emphrath, yes Wayland support is one of the things that came with Mir 1.x. And is even better in later versions of Mir.

[arubislander]

@emphrath Wayland is a protocol. There needs to be actual software that implements the protocol. As Alan mentioned, the Wayland protocol has been implemented from Mir 1.x and has been much improved since.

[Emphrath]

@arubislander thanks for the explanation !