No more "Mir EGL" on 1804LTS (Bionic)

alan_g

As a result of some changes to the graphics stack on 18.04 the Mir team are dropping the Mesa patch that used to support Mir's EGL implementation.

As UBports is the only project I know affected by this change I'm explaining here, rather than on the Mir forums.

This affects Unity8 Desktop on Ubuntu 18.04. (It doesn't affect 16.04 desktop or phone.)

Background

We discovered this afternoon that the Mir-EGL patch mesa doesn't work with libglvnd which has been recently included in Ubuntu. This breaks:

EGL clients using libmirclient (not Wayland clients); and,
"nested" Mir (which is actually an EGL client of the "host" Mir).

The Mir have decided to drop the "Mir EGL" patch from bionic rather than writing and maintaining code that isn't strategic (it isn't needed for Wayland support). This patch has never been upstreamed and Mir works without this patch on Fedora and Debian SID.

Impact

Short term it means means more work for UBports to get Unity8 working on the 18.04LTS desktop. But it is the same situation faced getting Unity8 to work on other distros so the long term impact is minimal.

this change should not affect the Unity8 shell itself, only applications using libmirclient (most importantly those using qtubuntuclient). These applications should be able to work using Wayland, (e.g. Qt applications can use qtwayland).

There's no replacement for "nested" Mir in place yet (this is how unity-system-compositor is used on the phone, but is not essential for desktop). However, @mariogrip has done some work on a Wayland "Mir platform" that would allow one Mir server to "Nest" on another.

I had planned to have more solid Wayland support in Mir before dropping support for this legacy feature (but it was going to happen anyway). I expect the next release of Mir to address this shortfall before 18.04 is released.

WebDrake

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

I expect the next release of Mir to address this shortfall before 18.04 is released.

"Next release" means 0.31.0 ... ?

@mariogrip has done some work on a Wayland "Mir platform" that would allow one Mir server to "Nest" on another.

This is something I would be happy to help out with if anyone can offer a few starting pointers or simpler tasks to get my feet wet with.

alan_g

@webdrake said in No more "Mir EGL" on 1804LTS (Bionic):

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

I expect the next release of Mir to address this shortfall before 18.04 is released.

"Next release" means 0.31.0 ... ?

After the debacle of "Mir 1.0" last year I don't predict what the release will be called if I don't have to.

@mariogrip has done some work on a Wayland "Mir platform" that would allow one Mir server to "Nest" on another.

This is something I would be happy to help out with if anyone can offer a few starting pointers or simpler tasks to get my feet wet with.

This is the only pointer I have:

https://github.com/ubports/mir/commit/a8cd1fcc1eb15c45297b2181fc93a3503aa69150

It does need to be updated for Mir changes since then.

I have had some discussions with @mariogrip about this code: It deserves to be split out as a separate "platform" in the same way that the "android" platform has been.

WebDrake

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

After the debacle of "Mir 1.0" last year I don't predict what the release will be called if I don't have to.

OK, fair enough.

This is the only pointer I have:

https://github.com/ubports/mir/commit/a8cd1fcc1eb15c45297b2181fc93a3503aa69150

It does need to be updated for Mir changes since then.

I confess I'm finding the upstream/ubports relationship a bit difficult to follow from the existing repo (and not only for mir). There doesn't seem to be a very rigorous maintenance of the boundaries between local patches and upstream.

It would be really, really helpful if there would be a stronger distinction between well-defined master- or major-version branches (whether tracking an upstream or not), versus branches dedicated to specific distro packages.

I have had some discussions with @mariogrip about this code: It deserves to be split out as a separate "platform" in the same way that the "android" platform has been.

That's something I would again be happy to help out with, but I am currently finding the project a bit opaque in terms of actually getting engagement on tasks and priorities $:-\$

GizmoChicken

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

[Loss of support for Mir's EGL] should not affect the Unity8 shell itself, only applications using libmirclient (most importantly those using qtubuntuclient). These applications should be able to work using Wayland, (e.g. Qt applications can use qtwayland).

I'm sure that those who need to know (namely, UBports devs) already know. But for those of us watching from the peanut gallery, which particular Unity8 applications currently use libmirclient? And broadly speaking, how much work will be needed to get them to work under Wayland? (I suspect that the "'nested' Mir" issue is more involved, so I won't ask about it here.)

alan_g

@gizmochicken said in No more "Mir EGL" on 1804LTS (Bionic):

I'm sure that those who need to know (namely, UBports devs) already know. But for those of us watching from the peanut gallery, which particular Unity8 applications currently use libmirclient? And broadly speaking, how much work will be needed to get them to work under Wayland? (I suspect that the "'nested' Mir" issue is more involved, so I won't ask about it here.)

This is a simple question with a not so simple answer.

Applications tend to (but don't have to) use a "toolkit" to simplify the task of communicating with the compositor. These toolkits can use multiple backends (usually controllable through an environment variable).

To switch the most significant ones the following needs to be changed when launching applications from:

    GDK_BACKEND=mir
    QT_QPA_PLATFORM=ubuntumirclient
    SDL_VIDEODRIVER=mir

To:

    GDK_BACKEND=wayland
    QT_QPA_PLATFORM=wayland
    SDL_VIDEODRIVER=wayland

In the case of Qt it is also necessary to install qtwayland5.

However, 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.

We've just enabled this extension (xdg-shell-v6) on Mir "master" but not yet released this change. 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. (This may not be a problem we can fix in Mir's Wayland support: they also behave badly on, e.g., Gnome shell if forced to use Wayland and not X11.)

GizmoChicken

Thanks much for the reply. Much appreciated! You explained the situation in a way that even a neophyte like me can follow.

@alan_g said in No more "Mir EGL" on 1804LTS (Bionic):

[Issues with some problematic Qt based applications] may not be a problem we can fix in Mir's Wayland support: they also behave badly on, e.g., Gnome shell if forced to use Wayland and not X11.

At the risk of revealing the I understand less than I purport to understand, I have one more question: I know this calls for speculation, but do you anticipate that the above mentioned problematic Qt based applications will behave reasonably well (as a stopgap) under the XWayland solution that you are currently developing for Mir?

alan_g

@gizmochicken said in No more "Mir EGL" on 1804LTS (Bionic):

At the risk of revealing the I understand less than I purport to understand, I have one more question: I know this calls for speculation, but do you anticipate that the above mentioned problematic Qt based applications will behave reasonably well (as a stopgap) under the XWayland solution that you are currently developing for Mir?

That is a reasonable expectation, although don't expect immediate progress! (We've not started coding yet,) But Qt applications are largely usable already (and Qt 5.9.4 was a significant improvement on 5.9.3).