Given recent progress, how about 2020Q1: Time to make Unity8 great again?
I like it! Maybe we can just rename this thread?
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:
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.
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.)
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).
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.
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:
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
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
@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
Also you can restart it with
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.)
@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
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").
it seems we need to
when run mir/unity8 but I don't undestand how...
That's just one way to set an environment variable.
@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.
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.
$WAYLAND_DISPLAY - I don't thinks it is set at all but maybe I am looking wrong.
That's fine - it overrides the default of
If you've dropped any confinement then the next question is:
What are the permissions on
Almost certainly, as apps can only access their package-specific path in $XDG_RUNTIME_DIR I think. We might need to add something to the apparmor policy to allow apps to see this socket?
That sounds similar to the situation with snaps. As well as the AppAmour policy, client apps need to do a "little dance" to use the Wayland socket. For example: https://github.com/MirServer/mir-kiosk-kodi/blob/master/glue/bin/kodi-launch.sh
I don't know the details of how edge is set up, but I do have experience of running Wayland apps on Mir servers. So there are a few questions:
$XDG_RUNTIME_DIRand does your app have permissions to open it?
$WAYLAND_DISPLAYset in your app environment? To something other than
If you set
WAYLAND_DEBUG=client before starting your app, the libwayland library will write what's happening (if anything) to the console log. There may be clues there.
I'll just add that I'm eager to have Unity8 working on the desktop. My thinking is that many will want to try Unity8 on the desktop first, and if they like what they see on the desktop, they'll be more likely to install UT on a phone.
The reality is that the priority for the UBports developers is the phone, and there's more than enough work for them there.
I too would like to see some "dev love" for the desktop but, it needs new developers so it doesn't distract from the phone. While I am a developer by trade, I don't find time for it either, so I do understand why nothing much happens.