As kugiigi says, Ubuntu Touch is using an obsolete version of Mir (1.8) with dated Wayland support. Also, most of the Wayland support in Lomiri comes from Mir (the rest comes from Mir's support for "custom" Wayland extensions).

The consequence of that is that there's no much prospect of improving the Wayland support in Ubuntu Touch without first updating it to use the current version of Mir.

The good news is that is work currently going on to get Lomiri working with the current version (2.20) of Mir. As of today this works on the machines of the developers involved and is close to landing in both the Debian and Fedora archives.

However, it will still take significant time to get the rest of Ubuntu Touch migrated over to this newer stack. That is probably the task that can most benefit from help at present.

After all that is completed, it should be possible for Ubuntu Touch to track the current version of Mir, and Wayland support will follow Mir. It is also possible to contribute to Mir's Wayland support, but that won't help Ubuntu Touch at present.

Hi @Raposa, I am not deeply involved in Lomiri, just with Mir and it's ecosystem. So I will answer those questions I can.

This could be useful background on the Wayland ecosystem:

https://mir-server.io/docs/ok-so-what-is-this-wayland-thing-anyway

is lomiri available for distributions other than ubuntu touch, or architectures other than arm? if not, would significant effort be needed to port lomiri to other distributions or architectures?

Yes, it is, for example, in the Ubuntu 24.04 and Fedora 40 archives and available for multiple architectures.

https://packages.ubuntu.com/noble/lomiri

is lomiri using wayland? is lomiri a wayland compatible desktop, capable of running wayland and xwayland applications seamlessly, what is the relationship of mir to wayland, and what is the architectural relationship of mir to lomiri?

Mir is a library for writing Wayland compositors and enables using Xwayland to support X applications.

https://mir-server.io/docs/developing-a-wayland-compositor-using-mir

Lomiri is one of multiple Wayland compositors written using Mir, and supports X applications. (Indeed the Mir support for X was initially contributed by one of the Lomiri developers.)

It has been over a year since I installed 23.04, but I had no trouble then.

And I installed 24.04 a couple of weeks ago also with no trouble.

Maybe there is a problem with it working on your hardware? But this is not the place to report problems.

I think the right place to report problems will be on Launchpad

AGPS has been an aspiration for the project since the initial Canonical effort. Does the sunsetting of https://location.services.mozilla.com/ affect the feasibility of this feature?

@zezba9000 you are asking questions about a stack that people moved on from. Four years ago:

• The mirclient API your client uses was dropped in favour of Wayland; and,
• Unity8 was renamed Lomiri

The error you are seeing is because Unity8 used to scan the client's command line to identify the .desktop file. (I forget what it actually looked for, but if you peek at the .desktop files for apps that do work, it will be obvious.)

But while I applaud using Mir, targeting a long obsolete version from an obsolete OS release seems like a bad idea. Even legacy systems ought to be running an OS that is supported.

@GermanAizek they wouldn't be empty run from the Terminal app. You might think it obvious you wanted to use adb shell but you didn't tell us.

How about checking ${USER} for "phablet"?

What is the state of the Lomiri desktop environment for the upcoming release of Ubuntu 23.10?

Support for the Wayland extensions (zwp_input_method_v1 and zwp_input_panel_v1) needed by maliit-keyboard (as used by Lomiri) have landed upstream in Mir. They are not in the Mir 2.15 release currently being tested, but will be available in subsequent releases.

As this was requested for Lomiri (by @dobey) I hope this of interest here. There will be some Lomiri work needed to use this in Lomiri so I hope the following will include enough information to guilde this.

Using Mir's support for maliit-keyboard

The easiest way to test this support is to install Miriway from edge and configure it to support maliit-keyboard:

sudo snap install miriway --classic --edge
sudo apt install maliit-keyboard
cat /etc/xdg/xdg-miriway/miriway-shell.config/ > ~/.config/miriway-shell.config
cat <<EOT >> ~/.config/miriway-shell.config
shell-add-wayland-extension=zwp_input_method_v1
shell-add-wayland-extension=zwp_input_panel_v1
shell-add-wayland-extension=zwp_primary_selection_device_manager_v1 # it isn't obvious why maliit-keyboard needs this
shell-component=miriway-unsnap maliit-keyboard
EOT

You can then log out and log back in into Miriway from the greeter. maliit-keyboard will show when input is on a text field*.

[*] The client needs to support one of the text-input-v{1,2,3} Wayland extensions.

Please report any issues on Mir's github: https://github.com/MirServer/mir/issues

@extraymond said in Possibility of basing on ubuntu core?:

run lomiri as it is on mir which I assume is possible with ubuntu core

If by "on mir" you mean using the mirclient IPC, then no. That won't work on Ubuntu Core.

Helpfully , that leaves you with just one option:

learn about confined-shell and mirway and see if I can get lomiri running as a standalone snap on a ubuntu core device.

Here's the code for these:

https://github.com/MirServer/confined-shell-wip
https://github.com/Miriway/Miriway

@extraymond I'd love to see this happen, but are you volunteering to work on it? Or hoping someone else does?

I've some knowledge of both Ubuntu Touch and Snaps and am willing to advise.

For anyone interested, the POC described would be a huge amount of work. Probably less than the 20.04 transition but certainly more than a few months:

• Ubuntu Touch uses a custom kernel for each phone so a kernel snap would need to be maintained for each phone. I also suspect that work would be needed to have hallium "play nice" with snapd.
  Anyone tackling this has a huge learning curve to surmount: You likely have as much knowledge as anyone else here about getting hallium working in a kernel snap

• The base doesn't really matter for this, but I'd suggest core20 to match the 20.04 base of other UBports projects

• Lomiri (the shell used by the project) is not designed to work with snap confinement, so this would involve more than "just packaging".
  And "just packaging" as a snap isn't trivial for shells - I speak as one that has done it! (See below)

• The only snap interface between Lomiri and "an snap" would have to be wayland (There is no Snap interface for the legacy mirclient-based IPC).
  The client bit is simple, there are loads of snaps available that consume the wayland slot. However, work on transitioning Lomiri to Wayland is incomplete (it has been in progress for several years)

If you're on Ubuntu desktop, you can experiment with a couple of relevant snaps of another Mir based shell (Miriway) that I've packaged: you can install both of these on your system:

• confined-shell is a strictly confined snap which is what is needed to install on Ubuntu Core; and,
• miriway an unconfined snap that doesn't have to deal with the limitations imposed by strict confinement

Probably the most tractable part of this POC would be to package Lomiri as a snap. This could also be useful for Lomiri's desktop ambitions. You could get an idea of what's involved by starting with a "classic" snap modelled on miriway.

Update: the weird colours are gone now

I too can't find any settings to change the horrible colour scheme. But I found the colours are OK (unchanged?) on an iPhone. Time to switch?

A better discussion of implementing this feature is:

https://forums.ubports.com/topic/2848/what-s-the-situation-with-blue-light-filtering-on-ubuntu-touch/

The tl;dr: it needs to be implemented (in Mir) and someone who thinks it important needs to their spend time doing that.

@arubislander said in Ubuntu Pro:

Only ESM support does not include ARM packages, so it turns out.

That's true for 14.04 and 16.04 but has changed since:

https://ubuntu.com/security/esm

Can you tell us how the integration of extended support for Ubuntu 16.04 went and what it means for both developers and users of Ubuntu Touch?

@rugby the developers (I think @Flohack is driving it) have been liaising with Canonical to get security updates from them. And, once this is in place, these will be incorporated in the OTA updates.

Mir is a core part of the what makes Lomiri and Ubuntu Touch possible and the Mir team (of which I'm a member) is recruiting:

https://grnh.se/f48787771us

@eirikr1848 I'm the team lead on Mir and can reassure you that there's open communication between the UBports devs and the Mir team, so this isn't news to them.

There are several pieces of work needed before Mir 2.9 could be integrated into Ubuntu Touch:

1. The UT ecosystem (apps, toolkits, indicators, etc) needs to migrate from the mirclient API to Wayland;
2. To do this, some functionality gaps need plugging that mirclient API provided and require new Wayland extension protocols; and,
3. Ubuntu Touch's QtMir needs to migrate to using Mir's libmiroil API

Some exploratory work has been done on all of these task and it is mostly a matter of someone finding time for them.

However, unless someone else steps up and volunteers, most of this work needs to be completed by the UBports devs and they are currently busy with the migration from 16.04 to 20.04.

@psingh said in Ubuntu Touch Q&A 120 This Saturday 30th July At 19:00 UTC:

I recall though how when Canonical maintained the OS they had a "pages" feature

I think this was called "scopes".

@duncancragg said in Vulkan and USC 0.9.0 (Mir):

do you mean there was work done inside /Mesa/ to support mirclient's Vulkan buffers

Vulkan, like GL and GLES, is an API.

Mesa is an implementation of graphics API specifications like GL, GLES and Vulkan.

For each API work is needed to support mirclient.