How Can I Contribute OR Why YOU Will Drop Ubuntu Touch Entirely

[grenudi]

read md files attached. dont read. whatever.

ps



pss
if you have seen movie "Unhinged", that's how ppl get unhinged. If you are the person who takes part of making such systems that does not even tell me where I'm being wrong, just straight up shut me up, don't wonder when you will become 'next' for such "Unhinged" person.

---

factcheck_v3_upstream_audit.md.txt

---

post_clean_hyperlinks.md.txt

[grenudi]

For @charly —my only contact here.

[Keli]

@grenudi thanks for the detailed writeup. I like your honest critique and insight on the situation.

[projectmoon]

What even is this?

I agree with certain points, especially about the display stack and, to some extent, the browser. Moving to QT6 is good, but moving to a normal Wayland compositor with a set of small patches to Firefox/Chromium would be better in the long run. I'm not exactly sure what "necessary functionality" from Mir would be lost, but I can't think of anything (but, I am not well-versed in the magic of Mir). I will withhold final judgment of the compositor situation until Mir 2.x is out.

The rest of it, the stuff about "pet project" and blah blah seems like unnecessary complaining. Ubuntu Touch is not a "pet project," even if one tries to stuff the definition into a specific hole. It is a volunteer-run open source project with some commercial backing. Volla is supporting Ubuntu Touch with commercial resources. They have at least one employee working on UT to make sure it runs properly on their devices, which is probably why the Volla devices (at least newer ones) have the smoothest experience. There is also apparently a commercial agreement with FairPhone for the FP4.

[alan_g]

Interesting perspective. I am the team lead on Mir and recognise some of the history you report on. But I don't interpret them all as you do:

• Mir (display server): Canonical's alternative to Wayland. Pivoted to IoT. Wayland won.

This conflates the Mir display server and the mirclient API. mirclient was used before Mir switched to Wayland. Support for Wayland was introduced in 2017 and mirclient was dropped in 2021. Wayland did win, but Mir didn't lose.

C-02 | UBports Perpetuating the Pattern

UBports did not create the architectural problems. They inherited them.
But after 8 years, they have not resolved any of the fundamental ones:

• Halium: still on vendor EOL kernels
• Mir: still not standard Wayland-native

Mir is Wayland-native (for at least 5 years) and the basis of several popular desktop Wayland compositors:

• Lomiri
• Miracle-WM
• Miriway

Mir 2.x IS a Wayland compositor. Standard Wayland client apps DO run via XWayland.

That misunderstands Xwayland - that allows X11 applications to run on a Wayland compositor,

The mirclient protocol — the native app protocol for UT Click apps — is not standard
Wayland. It is a Mir-specific extension. Miroil preserves it as a compatibility shim
over Mir2. The Mir team lead proposed Miroil in 2021 as a low-priority project.
In 2026 it is still not complete.

Miroil is complete and has been in maintenance mode since 2021, It provides API compatibility for Lomiri to make migration from Mir 1.x to Mir 2.x easier. It is not related to mirclient in any way.

Phosh's phoc uses wlroots. wlroots speaks native Wayland. GTK/Qt apps run natively.
No containers. No compatibility shims. No mirclient. One protocol. Standard.

To paraphrase: UBports Lomiri, Canonical's Ubuntu Frame, Matt's Miracle-WM, my Miriway and Budgie's Mirpie use Mir. Mir speaks native Wayland. GTK/Qt apps run natively. No compatibility shims. No mirclient. One protocol. Standard.

Using containers is a OS choice, not a compositor choice.