Posts made by alan_g

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?

Someone turned up on the "UBports Unity8 Development (Not a game engine)" group today asking about installing Unity8 on Ubuntu.

There doesn't seem to be anything helpful on the unity8.io property about this, and I linked to an out of date blogpost: https://ubports.com/blog/ubports-blog-1/post/unity8-on-the-desktop-95 as the least bad option.

I know that desktop is not the focus of the core developers, but I think there is interest in the community to keep this information up to date if "drive by" corrections and changes were possible. Could something like a Wiki be used on unity8.io for the current status of desktop, install instructions, etc.? And linked to from the landing page?

@Aury88 sorry, I didn't read the whole thread, just from the point you pinged me.

That log isn't related to https://github.com/MirServer/mir/issues/704 where one of the DRM functions returns a misleading result. Instead it looks like the graphics driver isn't adequately supported by Mesa.

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). But maybe you can find something useful here: https://forum.snapcraft.io/t/support-for-raspberry-pi-4/11970

For example:

you might need to play with the dtoverlay= kms or fkms values in config.txt. i know the vc4 driver isnt fully ready to drive the vc5 hardware in the pi4 but i know that for example my omxplayer-pi snap works fine (only 1080p though, omxplayer does not support h265 yet) when either using no dtoverlay or with the fkms one (not with the kms one though). - https://forum.snapcraft.io/t/support-for-raspberry-pi-4/11970/17

@Aury88 it might help others help you if you pastebin the Unity8 log.

@Aury88 said in Raspberry Pi 4 Model B:

@Pulsar33 it should be in the Ctrl+Alt+F7. unity8 is by default already running in background. you can prove that by typing in the console

start unity8

Also you can restart it with

restart unity8

The problem is that it doesn't seem to work properly because of the mesa-kms missing support in the raspberrypi4 as you can see above
(EGL platform does not support EGL_KHR_platform_gbm extension, Failed to detect whether device /dev/dri/card1 and card2 supports KMS and Couldn't get DRM resources for an Invalid argument)

If that's how you are starting Unity8, then setting the environment variable needs to be done in the launch scripts, not in your terminal session. (Sorry, I don't know enough about how your image is set up to know where these scripts are.)

@Aury88 said in Raspberry Pi 4 Model B:

@alan_g sorry but I'm not so skilled about bash and linux. so excuse me for the stupid question:
I knew that environment variable had to have a value so something like

ENV_NAME=value

MIR_MESA_KMS_DISABLE_MODESET_PROBE seem only the name...what is its value? is it"true"?

It doesn't need a value, so "true" will be fine (as will "false").

@Aury88 said in Raspberry Pi 4 Model B:

@Pulsar33
Hi!
The unity8 log is very similar to this issue in mir-kiosk. It says there is a workaround but I don't understand what it is....we need to study it and or help from @alan_g

it seems we need to

--env-hacks MIR_MESA_KMS_DISABLE_MODESET_PROBE

when run mir/unity8 but I don't undestand how...

That's just one way to set an environment variable.

@chdslv That doesn't make much sense. UT packaging uses click, not apt.

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

@alan_g I see in the Mir 1.4.0 release discourse mention of the layer-shell extension. If I understand correctly how this extension works, we should be able to use it for re-implementing the trusted overlays, no?

I agree we should map out Wayland protocols that can help replace mirclient functionality. But in this specific case, I don't think layer-shell addresses the same concerns as trusted prompts, so I don't immediately see how you imagine using it.

I'll have a closer look at this idea after the holiday weekend to see what I've missed.

Having seen the post about the Ofono Hackathon I was reminded of the Halium project.

For a long time now Halium has been the suggested route for new ports and, architecturally, it seems like an excellent initiative. In spite of this the UBports supported phones have continued with the legacy stack.

• What is the state of Halium based UBports? Are there working phones?
• What is the state of other Halium based projects? And is the project moving forwards?
• Are we ever going to see a move to Halium for future OTAs?

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.