I've noticed a few discussions recently regarding developers getting involved in developing Unity8. I don't know all the answers myself, and don't have the free time to find them, but I think I can start a constructive discussion.

A bit of history

The Unity8 shell comprises a lot of inter-related projects and dependencies. These have to be coordinated and installed together, this worked best in Ubuntu 17.04 at which point it was possible to install a usable Unity8 desktop from the archive with a single command.

When Canonical withdrew from the project they understandably stopped maintaining these projects and dropped them and a number of the dependencies from the archives. There have also been some incompatible changes to some of the dependencies.

One of the big changes has been to the Mesa graphics drivers: Ubuntu used to carry a "Mir EGL" distro patch that enabled EGL clients to use the "mirclient API". Because Mesa changed in ways that broke that patch badly it was dropped in Ubuntu 18.04. I'll discuss this further below under "Going Wayland".

The UBports team has done its best to maintain the projects and dependencies in the UBports repo, but this hasn't been the most urgent thing to work on and they have not dealt with everything that has changed.

Getting started

I've never built the majority of Unity8 components from source, not am I sure which branches are canon in the UBports source repositories. I'm sure developers could figure this out, but it would save everyone time if there were a blogpost.

The bits I do know:

1. The first, best hope is 18.04LTS.
   Other distros and more recent series are possible, but let's make it work in one place before fixing everywhere.
2. The UBports repo at http://repo.ubports.com/ contains the dependencies, and needs to be added to apt sources.
   echo "deb http://repo.ubports.com/ $UBUNTU_CODENAME main" | sudo tee /etc/apt/sources.list.d/ubports.list
wget http://repo.ubports.com/keyring.gpg -O - | sudo apt-key add -
3. This is messy enough accidentally break your system: use test partition, VM, or secondary laptop as appropriate.
4. There are more detailed instructions in the README: https://github.com/ubports/unity8

Going Wayland

This is the bit I understand best (because I work on Mir). It is also, I think the biggest cause of deterioration since 17.04.

Unity8 was originally built using the "mirclient API" which was designed for convergence. But for "mirclient API" to be useful this needs support in client toolkits and even with Canonical pushing it this was never great. Since then, it has been dropped from GTK+ and SDL2.

Unity8 is based on Mir and @mariogrip had done the work needed for Unity8 to run on Ubuntu 18.04 without "Mir EGL" by using Wayland instead of the "mirclient API" (which is supported by recent versions of Mir).

However, Wayland is not a "drop-in" replacement for the "mirclient API" and there are some limitations apparent on Unity8 desktop:

1. GTK+ applications assume CSD and add shadows which Unity8 is "not expecting". That produces weird effects, like a disconnected, second titlebar.
   There is, theoretically, a solution to this upstream: https://github.com/MirServer/mir/issues/664
2. For X11applications the integration provided by Xwayland is even worse than that previously provided by Xmir
   Part of the solution to this is upstream: https://github.com/MirServer/mir/labels/Experimental
   2.1 But this isn't all: https://github.com/ubports/unity8/issues/56

I am biassed by my involvement in Mir, but these are issues that an interested developer could tackle to make a significant improvement to the Unity8 desktop. In addition, they are easier to work on than Unity8 as the Mir project has significantly fewer dependencies (all of which are in the Ubuntu archives).

Another effect of the loss of "Mir EGL" in Mesa and the consequent switch to Wayland ls that the "Mir-on-Mir" support needed to use the Unity greeter is no longer available. Some work has been done on providing a "Mir-on-Wayland" graphics platform in Mir, but that needs significant rework (it is on my list of things I want to get to, but if you fancy taking it on get in touch).

Note: There are additional limitations to using Wayland on the phone that need to be addressed, but I'm keeping this discussion to Unity8 desktop.

Other stuff

Unity8 was not finished in 17.04, and quite a few of the things that were "done" need to be updated. I'm not an expert on this so I'll leave detailing a list to others.

What I do know:

1. The issues list: https://github.com/ubports/unity8/issues

2019: Time to make Unity8 great again?

I hope this provides a bit of impetus to developers interested in contributing to Unity8 to progress further. Even if this post is simply a place for potential developers to declare their interest and meet each other it will have served a purpose.

tl;dr: There's nothing to worry about, this was expected and planned for.

The mirclient APIs used in Unity8 and 16.04 based applications is not dropped, and does not require a build-time option to enable it.

It simply needs switching on with a configuration option at runtime. (There are many ways that can be supplied, for example, adding code to QtMir and unity-system-compositor that fakes passing this as a "command-line option" to Mir.)

For a bit of perspective, these APIs have been deprecated for two years, and the UBports developers have been aware of that. Similarly, the Mir developers have been aware that they are used by UBports and have continued to build and test them.

Everyone working on this software stack has always known that UBports needs to move off these APIs at some point, but that cannot happen until there is a viable alternative. And that requires moving to a more recent version of Mir (at least Mir 1.3 for this Mir support for Wayland).

The change to "new Mir" is progressing, and is available on the "edge" channel. Delivering that will allow the migration to Wayland to start.

There have been discussions (here and here) about this migration and, when the time comes, the Mir team has the expertise, willingness and availability to help UBport move from mirclient APIs to Wayland protocols.

There may be a time during this transition where UBports cannot ship with the latest release of Mir, but the way forward is clear and the problems to be addressed are far smaller than ones that have already been overcome.

After another discussion around this topic I felt it time to write up something for the forum. However, I have to declare an interest: my "day job" is developing Mir. You have to decide if that means I know what I'm talking about, or if I'm promoting my own goals.

The Past

When the Unity8 project started Canonical needed a rich enough "language" for applications and server to "talk" to each other to support convergence. They chose to develop this in the form of an API: Mir. The idea was that Mir would provide a way for various shells (Unity8 and other shells) and applications to co-operate.

It may sound ambitions to expect that every existing application should stop talking X11 and start "talking Mir", but really there were reasons to move away from X11 and applications largely use one of a few "toolkits" instead of using X11 directly. Get support into those toolkits and the job is mostly done. For other applications they built Xmir - which is an X11 server that translates for applications that only talk X11. Xmir could never be perfect for the converged scenario, but applications would be able to run.

At least that was the theory. In practice things didn't work out that way: toolkit support was variable and, in general, was never good enough for convergence. While Qt got pretty close and SDL2 is usable, there were still serious problems with gtk3 and Xmir.

The Present

UBports has not given up on the idea of convergence and of running desktop applications on Unity8. But if those applications do not support "talking Mir" then there are currently no good options. The least bad option is to use Xmir, but the result isn't great.

Canonical is no longer developing Unity8, but it has continued with Mir because of the "other shells" mentioned above. That is good for UBPorts, as Mir is a substantial part of the functionality Unity8 needs. However, there is a problem both for Canonical and for UBPorts: applications are not going to "talk Mir".

The approach Canonical is taking is to support applications that talk Wayland in Mir. Wayland is another X11 replacement that is being taken up by toolkits. While the approach taken is different (there is a limited "core" protocol that all Wayland servers must support and an extension mechanism for servers that need something richer) there are enough parallels for this to work. There's even an Xmir replacement: Xwayland, plays the same role of interpreter.

The Future

UBports cannot rely on seeing improvements to the Mir support in toolkits nor improvements to Xmir. The way forward for UBports is to leverage the continuing work Canonical is doing on Mir to support Wayland clients.

That requires one, non-trivial, thing: Moving to the current, supported, version of Mir.

There are several reasons why that is non-trivial:

1. Mir is not supported on Vivid
2. Mir has dropped support for "android" graphics drivers
3. Code changes are needed to reflect changes to the Mir API
4. Some further changes are needed to support Wayland applications

Now for the good news:

1. Mir is supported on Xenial, and that is the next target for UBports
2. The code for using "android graphics" drivers is not lost, it is alive and well thanks to UBports developers
3. The code changes have been made before (Canonical made these changes for unity8-desktop-session on Zesty)
4. The bad news: while unity8-desktop-session on Zesty works with the latest Mir, Wayland applications are not rendered on the display.

Updating UBports to the latest version of Mir will take time and effort, but it is the most feasible way of getting desktop applications working.

Where we are now

While Unity8 has been most complete and successful on phone and tablet it was always intended that it would also encompass desktop operation.

After Canonical stopped work on Unity8 UBports has focused on supporting and developing phones and a separate project Yunit was working on the desktop case. However, nobody has been working on Yunit for a while now and people are asking on the UBports telegram group about Unity8 on desktop. This is an attempt to give a high level view of the implications.

There are two sets of differences between phone and desktop: the graphics "stack" and the input and display capabilities. Attaching external displays, keyboards and mice to phones allows a switch to "desktop mode" but uses the same libhybris/android graphics stack as for normal phone operation. On "desktop" architectures a different mesa-kms graphics stack is used.

For Unity8 or application developers the differences between these, or other possible, graphics stacks are hidden beneath the Mir libraries, but the distinction is important when installing onto a computer or device.

While all the software needed for the "desktop" installation exists in some form it hasn't been maintained since the Ubuntu 17.04 release. Indeed Canonical has dropped many of the packages from the upcoming 18.04LTS.

The way forward for "desktop"

The UBports developers are demonstrably sympathetic to a desktop variant, but their priority should be progressing the supported deployment onto the phone "stack". If people are interested in desktop they should try to progress it in a way that doesn't distract from these existing efforts.

Late last year I outlined a plan on the Yunit forum. It was probably too late for Yunit but I think much of that discussion is still valid.

There are differences between the UBports and Yunit codebases (and there's likely useful code on Canonical branches) this needs to be resolved.

In short, if there is the will, there is work that could be done.

Some context

A year ago I set out The Way to Wayland (for Unity8) which consisted of three pieces of work:

1. Updating to Mir 1.x
2. Updating Mir-on-Mir
3. Updating to Wayland

There's been progress on all fronts and, although none of these is entirely finished, it is time to look ahead again.

1. On the UBports side, The "devel" channel is working on moving Ubuntu Touch to a Mir 1.x base (Mir 1.2 AIUI)
2. On the Mir side Mir 1.6 introduced a Mir-on-Wayland platform that can, in theory, be used instead of Mir-on-Mir
3. On the UBports side there's been some initial work to use Wayland in Unity8 for the 18.04 desktop

The big piece of work outstanding is "Updating to Wayland":

Updating to Wayland

 
Using the mirclient API is also largely restricted to the phone and Mesa on 16.04LTS because GL rendering, like “Mir-on-MIr” depends upon Mir-EGL. That is a limitation on other distros, and other drivers.
 
The natural solution is to switch to Wayland and, with a recent Mir version, that can work for a lot of applications. However, Unity8 and the associated applications used by Ubuntu Touch also make use of Mir features designed to support “Convergence” and the security model Canonical designed for the phone.
 
This means that it isn’t possible to switch to everything Wayland without additional work. On the current phones that doesn’t matter for moving to Mir 1.x, as the mirclient APIs are still available and supported, but in the longer term there needs to be a way to support any features that prove necessary through Wayland. Fortunately, Wayland is designed to support protocol extensions and I would recommend this as the way forward.
 
Mir doesn’t (yet) have a clean API for adding Wayland protocol extensions in a server and, in any case, those that are needed by Ubuntu Touch are simply exposing existing Mir functionality. So, once the necessary protocol extensions are identified, the Mir code is the place to implement them.
 
A prerequisite for adding Wayland extensions is Wayland support in Mir, and that requires a recent version of Mir.

The point of the Wayland transition is to move away from the mirclient based APIs that Mir will be dropping in further development.

Mir 1.x is new and shiny, what is this "and beyond"?

For the immediate future, UBports will continue using Mir 1.x and the Mir team will try to provide backports of useful features to the 1.x series. But that will become increasingly difficult as time goes by.

The Mir team is in the process of removing mirclient specific stuff and that means there are already changes in Mir "master" that break all graphics using the mirclient API (if new features depend on those changes they won't appear in a Mir 1.x release).

Because of the history of Mir, the mirclient API actually affects other Mir APIs, for example Taking the mirclient out of MirAL. That means the impact of dropping mirclient on UBports goes further than simply switching qtubuntu-[desktop|android] to qtwayland for all applications.

QtMir

The principle component of the Unity8 stack that is affected by all this is QtMir. This the library responsible for joining Qt to the Mir server to customise the scenegraph and rendering. The way it does this is inelegant for historical reasons and everyone that has ever touched it has felt the urge to "clean it up". (Indeed, @greyback and I had started on this before Canonical withdrew from the project.)

Having these customisation points (animations, compositing and rendering) was one of the goals of Mir, and something the Mir team aims to provide in a more elegant way in the future. Ideally, one that isn't tied to Qt or GTK but can support alternatives. (Indeed @mariogrip has independently suggested the same idea.)

This seems like an area that would, once other priorities are cleared by both teams, would benefit from collaboration.

Seeing the above question about integrating Wayland I think it would be good time to explain how some things fit together:

1. "New Mir"
2. "New Unity8"
3. Replacing Xmir with Xwayland
4. Enabling apps using toolkits that support Wayland
5. Migrating existing apps to Wayland
6. Migrating compositior components to Wayland

@advocatux it isn't just "now".

Even after 16.04 ships do we really want to spend a month moving everything instead of...

• Porting to new phone(s)?
• Getting anbox support released?
• Getting Unity8 desktop working again?
• Delivering other cool stuff?
• Fixing bugs?
• Promoting the project?

Really, unless we realistically expect things to be better after the move this has to be a bad idea. (Getting 50% more work done afterwards would be a good argument - that's break-even in 3 months.)

Is there any plan to replace Mir?

An oft asked question has arisen on the Telegram channel once again and I thought I'd post an answer here for posterity:

Is there any plan to replace Mir? Since it's completely abandoned, it may take too much effort to maintain it, and it may better to switch to Wayland, if it's possible, since it has way more support. - so manpower could be used somewhere else (PWA maybe?)

Greatly exaggerated

"I can understand perfectly how the report of my illness got about, I have even heard on good authority that I was dead. [A cousin] was ill in London two or three weeks ago, but is well now. The report of my illness great out of his illness,. The report of my death was an exaggeration." - Mark Twain

Like the reports of Mark Twain's death, Mir's abandonment is based on a misconception.

There's a lot of confusion about this because "the internet" has confused toolkits supporting the mirclient API with servers using the Mir libraries. These are two different stories.

The mirclient API

The mirclient API is a way for application toolkits (and other client-side libraries) to use Mir. This API is abandoned: it is no longer under development and the Mir developers have deprecated it and will remove it "someday". I think UBports is the only remaining project to use it (the Mir support in Kodi, SDL2, gtk3, etc has been dropped).

UBports do need to switch from using the mirclient API to using Wayland before "someday" becomes "today". That is a multi-step process described here: The Way to Wayland (for Unity8)

The Mir server libraries

Mir was the core of Canonical's effort to enable "Convergence". [See: https://forums.ubports.com/post/18392 for my take on "Convergence"]. These libraries are still supported and developed by Canonical and there are a number of projects using them or planning to use them. Canonical has IoT projects, some experimental "desktop" work (including with MATE).

There is no reason for UBports to switch from using the Mir server libraries, they are the foundation on which Unity8 (and some other, less visible, components) are built. Even with the issues presented by the switch to using Wayland for applications the support for "Convergence" is unique to Mir and core to UBports.

Convergence is mostly a software thing. There are two parts to this:

1. flexibility: the software including shell and application GUI adapts to the capabilities of the hardware it runs on.
   This means that the same software, with the same features, works well on a desktop, a phone or a toaster.

2. agility: the software including shell and application GUI adapts to changes to the capabilities of the hardware is running on.
   This means that connecting a display, keyboard, dock etc. will enable user interactions optimized for these.

Most existing software is not designed for either of these goals. The Ubuntu Touch experience of using "desktop" apps in Libertine speaks to this, it is possible to use these applications, but the interaction is poor because these apps do not adapt to the hardware. This can change but, like any change, there will be costs, pain and resistance until suddenly it will be done and everyone wonders why it was ever any different.

But the software is only a part of what is being alluded to here. Real use-cases are not about using a specific piece of software, they are about accomplishing goals: publishing something, learning something, meeting someone. That needs a combination of user data, software and access to hardware.

I've had a long career in software development and seen computing shift from centralized "mainframe" computers that hold the data and programs for multiple users to "personal" computers that hold a users data and programs and back to centralized "clouds" that hold all the data. That change has been driven by economics: changes in the costs of computers and of connecting them.

While there are legitimate privacy and security concerns the economic drivers are currently pushing towards centralization and connections. Many apps are little more than optimized front-ends for data and computational services elsewhere on the internet. I think this trend will continue before a readjustment back towards "personal" computation.

In this context, any "one device" we might carry is more about having the keys (or passwords) we need to accomplish our daily tasks than carrying all the software and data we use. If both my laptop and phone can support all my daily tasks interchangably, browsing the web, emailing, Telegram, IRC, software development, video calling, phone calls, SMS, etc. then I need only take the one best suited to the occasion. Having the same software and keys on both is what would make them interchangable. (And yes, phone calls are best on a phone while software development is best on a laptop, but making both possible gives me control.)

Note: The issues described below have been resolved: Unity8 can run on 18.04. (There are still issues to be resolved, but the following is now only of historical interests.)

Background

As mention recently Unity8 has two problem areas running on Ubuntu 18.04LTS.

1. Mir-on-Mir doesn't work. This means that the configuration used previously of lightdm starting unity-system-compositor (to handle the "hardware") and Unity8 connecting to unity-system-compositor doesn't work.

2. Client applications that use libmirclient cannot use EGL (only applications that use software rendering will work).

Note that these are not Ubuntu specific, they are the same issues that prevent Unity8 running on other distros.

I think the way ahead is:

Don't use Mir-on-Mir

With a bit of tweaking to Mir Unity8 will be able to run under the GNOME Display Manager [GDM]. The Mir team is aiming to have the necessary tweaks in place for the 18.04 release along with an example "Mir" desktop session.

Until the Mir changes are available this approach can be "faked". Switch to a virtual terminal, log in and type the following:

$ sudo chown -R $USER /dev/input
$ QML_BAD_GUI_RENDER_LOOP=1 QT_QPA_PLATFORM=mirserver unity8

(Thanks to @malditobastardo from the "UBports Unity8 Dev" group who volunteered to test this.)

Applications should use Wayland to connect to Unity8

For Qt it is necessary to install qtwayland5.

This means changes to the environment variables set in the application environment. That means changes to any launchers (e.g. ubuntu-app-launch).

From:

GDK_BACKEND=mir
QT_QPA_PLATFORM=ubuntumirclient
SDL_VIDEODRIVER=mir

To:

GDK_BACKEND=wayland
QT_QPA_PLATFORM=wayland
SDL_VIDEODRIVER=wayland

Once again this can be faked using miral-app-run <application> from the command line. (miral-app-run is in the mir-demos package.)

There are still limitations to the Wayland support both in Mir and in the toolkits and the experience may not be perfect. In the release version of Mir Qt and SDL applications will work (with some issues) but GTK apps don't yet work as they require an unstable Wayland extension that Mir does not implement yet.

This extension (xdg-shell-v6) has been enabled on Mir "master" but not yet released. My experience with GTK apps is that they are pretty good at working with this (although there are still some Mir issues to resolve). Some Qt based applications are problematic (They also behave badly on, e.g., Gnome shell if forced to use Wayland and not X11.)

Please note

All of this is "in development" so don't wreck your real machine by "just trying it": Use a Virtual Machine!!

Things will not be "consumer ready" right away, there will be further improvements needed. This is just what is needed to get things running. (But, once these changes are in place, porting to other distros should just be a matter of compiling and packaging.)

What does this mean for UBports? Packaging of Unity8 Desktop for Debian

@rob said in What's Inside the Black Box of Ubuntu Touch?:

@alan_g that is really helpful. Now just to help in my understanding, where, as example does one configure a QT or a GTK so use these settings?

These want to be set for the process using the toolkit. Hopefully setting them for the launch command is enough:

QT_QPA_PLATFORM=xcb ubuntu-app-launch ...

There may be further details, it's been a long time since I did any of this.

@rob said in What's Inside the Black Box of Ubuntu Touch?:

GTK gets me further in Libertine. Which is funny. According to the docs, the host system has a lot of the Qtquick/QML libraries loaded already, so I'm thinking that on a Pinephone, there might be more room to play with it without Libertine and if so I'll try QML on it.

It's a long time since I tried developing on the phone, but one thing to bear in mind is the different backends/platforms that toolkits can be configured to use.

The "native" Ubuntu Touch environment uses mirclient, and the corresponding environment variables for Qt, GTK and SDL2 are:

QT_QPA_PLATFORM=ubuntumirclient
GDK_BACKEND=mir
SDL_VIDEODRIVER=mir

However, for using Xmir (or in the future Xwayland) from Libertine these ought to be:

QT_QPA_PLATFORM=xcb
GDK_BACKEND=x11
SDL_VIDEODRIVER=x11

Hope that clarifies some of the issues you're seeing.

---

PS At some point there will be a migration to Wayland:

QT_QPA_PLATFORM=wayland
GDK_BACKEND=wayland
SDL_VIDEODRIVER=wayland

@alan_g said in Mir 1.x and beyond:

Mir doesn’t (yet) have a clean API for adding Wayland protocol extensions in a server and, in any case, those that are needed by Ubuntu Touch are simply exposing existing Mir functionality. So, once the necessary protocol extensions are identified, the Mir code is the place to implement them.

Small clarification, that was a year ago. There's now a way to add Wayland extensions to Mir servers.

Some context

A year ago I set out The Way to Wayland (for Unity8) which consisted of three pieces of work:

1. Updating to Mir 1.x
2. Updating Mir-on-Mir
3. Updating to Wayland

There's been progress on all fronts and, although none of these is entirely finished, it is time to look ahead again.

1. On the UBports side, The "devel" channel is working on moving Ubuntu Touch to a Mir 1.x base (Mir 1.2 AIUI)
2. On the Mir side Mir 1.6 introduced a Mir-on-Wayland platform that can, in theory, be used instead of Mir-on-Mir
3. On the UBports side there's been some initial work to use Wayland in Unity8 for the 18.04 desktop

The big piece of work outstanding is "Updating to Wayland":

Updating to Wayland

 
Using the mirclient API is also largely restricted to the phone and Mesa on 16.04LTS because GL rendering, like “Mir-on-MIr” depends upon Mir-EGL. That is a limitation on other distros, and other drivers.
 
The natural solution is to switch to Wayland and, with a recent Mir version, that can work for a lot of applications. However, Unity8 and the associated applications used by Ubuntu Touch also make use of Mir features designed to support “Convergence” and the security model Canonical designed for the phone.
 
This means that it isn’t possible to switch to everything Wayland without additional work. On the current phones that doesn’t matter for moving to Mir 1.x, as the mirclient APIs are still available and supported, but in the longer term there needs to be a way to support any features that prove necessary through Wayland. Fortunately, Wayland is designed to support protocol extensions and I would recommend this as the way forward.
 
Mir doesn’t (yet) have a clean API for adding Wayland protocol extensions in a server and, in any case, those that are needed by Ubuntu Touch are simply exposing existing Mir functionality. So, once the necessary protocol extensions are identified, the Mir code is the place to implement them.
 
A prerequisite for adding Wayland extensions is Wayland support in Mir, and that requires a recent version of Mir.

The point of the Wayland transition is to move away from the mirclient based APIs that Mir will be dropping in further development.

Mir 1.x is new and shiny, what is this "and beyond"?

For the immediate future, UBports will continue using Mir 1.x and the Mir team will try to provide backports of useful features to the 1.x series. But that will become increasingly difficult as time goes by.

The Mir team is in the process of removing mirclient specific stuff and that means there are already changes in Mir "master" that break all graphics using the mirclient API (if new features depend on those changes they won't appear in a Mir 1.x release).

Because of the history of Mir, the mirclient API actually affects other Mir APIs, for example Taking the mirclient out of MirAL. That means the impact of dropping mirclient on UBports goes further than simply switching qtubuntu-[desktop|android] to qtwayland for all applications.

QtMir

The principle component of the Unity8 stack that is affected by all this is QtMir. This the library responsible for joining Qt to the Mir server to customise the scenegraph and rendering. The way it does this is inelegant for historical reasons and everyone that has ever touched it has felt the urge to "clean it up". (Indeed, @greyback and I had started on this before Canonical withdrew from the project.)

Having these customisation points (animations, compositing and rendering) was one of the goals of Mir, and something the Mir team aims to provide in a more elegant way in the future. Ideally, one that isn't tied to Qt or GTK but can support alternatives. (Indeed @mariogrip has independently suggested the same idea.)

This seems like an area that would, once other priorities are cleared by both teams, would benefit from collaboration.

What is the value in doing this? Do you have any evidence for your theory that this would make porting easier?

The costs are clear:

1. Developing and maintaining a VM
2. Creating and maintaining a port to the VM

There's likely developer-months of work in each of these tasks, so please be sure it's worthwhile it before spending time attempting it. (Sadly, I don't think the skills you list will be much help.)

@GizmoChicken said in 2019: Time to make Unity8 great again?:

Given recent progress, how about 2020Q1: Time to make Unity8 great again?

I like it! Maybe we can just rename this thread?

@GizmoChicken said in Ubuntu Touch Q&A 67 Saturday 11th Of January At 19:00 UTC:

As of about Mir 1.6, in addition to being Wayland compliant, "new" also supports the legacy protocol that was used by the "old" Mir display server. However, that legacy support will eventually be removed from Mir (probably starting from about Mir 1.7)

Thanks for the nice explanation. I'll add more detail from the Mir side:

• Ubuntu Touch release uses Mir 0.24
• Ubuntu Touch devel uses Mir 1.2
• Mir added Wayland support in Mir 0.28 (Aug 2017)
  Since then it has been the stated intention to drop support for the mirclient API "once Wayland support was good enough".
• mirclient is not supported for all the Mir "graphics platforms" (only "Mesa", "X11" and UBport's "android" - not "eglstream", "Wayland" or "dispmanx").
• Apart from UBports there are no downstream users of the mirclient API, but as of Mir's current release (1.6) it is still supported.

There are changes on Mir "master" that break and drop mirclient support but these have not been incorporated into a release yet. There are bug fixes and X11 enhancements that could benefit UBports and may be split out into another 1.x release.

@erlend said in Ubuntu Touch Q&A 67 Saturday 11th Of January At 19:00 UTC:

Mir is going to be replaced with Wayland....

As @GizmoChicken says, it is the mirclient API that will be replaced by the Wayland protocol. Mir is going nowhere. Mir is to Unity8 as Mutter is to GNOME, Kwin is to KDE or wlroots is to Sway. (Both Mir and wlroots are designed to support multiple user shells, Mutter and Kwin are more closely integrated.)

@erlend said in Ubuntu Touch Q&A 67 Saturday 11th Of January At 19:00 UTC:

Does this mean that we can run desktop apps (kde / gnome) in UT in the future ?

That is unchanged. It will remain possible to run desktop apps in UT. They may not run well because of the form factor (but that isn't related to using mirclient or Wayland).

@erlend said in Ubuntu Touch Q&A 67 Saturday 11th Of January At 19:00 UTC:

And will it be possible to run UT in other distributions like postmarketos/fedora?

Mir works for both of these and is in the Fedora archive. Unity8 needs work to run in a "desktop" environment (but that isn't related to using mirclient or Wayland). Other parts of UT do not make sense without phone hardware.

@alan_g said in Raspberry Pi 4 Model B:

I know that my colleagues at Canonical have yet to get graphics working on the Pi4 with Ubuntu Core (I think that's lack of time, not a technical issue)

Update: I just read the phrase "note: this fixes mir-kiosk support !" on this snapcraft thread about the Pi4:

https://forum.snapcraft.io/t/support-for-raspberry-pi-4/11970/37

That implies a kernel which works with Mir graphics and therefore can support Unity8.

How does the recent Mir 1.6 release affect "new Mir"? And Wayland?