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.