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.

Is SDL_VIDEODRIVER=wayland? Or mir?

If you set WAYLAND_DEBUG=client when starting your app, the libwayland library will write what's happening (if anything) to the console log. There may be clues there.

@zubozrout said in Running Wayland apps on edge?:

$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 wayland-0.

If you've dropped any confinement then the next question is:

What are the permissions on $XDG_RUNTIME_DIR/wayland-0?

@dobey said in Running Wayland apps on edge?:

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:

1. Is there a wayland-0 file in $XDG_RUNTIME_DIR and does your app have permissions to open it?
2. Is $WAYLAND_DISPLAY set in your app environment? To something other than wayland-0?
3. Does the click confinement prevent access to this file?
4. Does Unity8 allow the connection?

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.

@GizmoChicken said in Ubuntu Touch Q&A 55 Is Saturday 27th Of July At 19:00 UTC:

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.

@alan_g said in What's the situation with blue light filtering on Ubuntu Touch?:

Propose (and get accepted) this addition to the Mir project.

I've added an issue to the Mir project. (But it won't be scheduled in the foreseeable future.)

@3arn0wl said in What's the situation with blue light filtering on Ubuntu Touch?:

@Opolork @alan_g

There was an email address at the bottom of the Redshift website, so I just pinged the developer and asked if he might consider contributing some expertise to Mir.

As dobey said above, there's very little overlap. About the only thing in common is the choice of values for the gamma curves.

@joe said in What's the situation with blue light filtering on Ubuntu Touch?:

@alan_g Are there some suggested links to the Mir code etc?

For starters, there's a handy guide to step 1 here: https://mir-server.io/doc/getting_involved_in_mir.html

@Opolork if it isn't a priority for you, that's fine too.

@Opolork said in What's the situation with blue light filtering on Ubuntu Touch?:

I'd see a blue light filter function as a very high priority given how it's known to affect peoples sleep so badly.

Everyone is entitled to decide their own priorities. If this is "a very high priority" for you, the joy of open source is that you can do something about it. Here's a plan:

1. Check out the Mir code and get it building.
2. Find the mir_demo_server example and add a "blue light filtering" option by setting gamma ramp on the display configuration.
3. Try it out and confirm if it has the desired results.
4. Adapt this code to provide this "filtering" option via the MirAL interface.
5. Propose (and get accepted) this addition to the Mir project.
6. Check out the QtMir code and get it building.
7. Make use of the new MirAL option for "blue light filtering".
8. Propose (and get accepted) this addition to the QtMir project.

There are people willing to help with every step along the way.

Good luck!

@3arn0wl said in Ubuntu Touch Q&A 53 Saturday 29th June At 19:00 UTC:

Can I ask a follow-up question then, please...? Are the UBports devs doing all the work on getting Unity8/Mir onto Wayland, or are Canonical devs contributing too? Canonical, after all, still have interest here, I think.

This post is probably not the best place to discuss this, but I'll answer briefly.

Canonical funds most of the work on Mir, and that work includes making Mir work with Wayland.

In principle, Unity8 (or other server using Mir) doesn't care whether clients are using the mirclient API or Wayland. Except where it uses the mirclient API itself, or features that would need Wayland extensions to support. The Mir devs have provided advice about the Unity8 changes, but are not otherwise active in making them.

@UniSuperBox said in What's the situation with blue light filtering on Ubuntu Touch?:

Gonna disappoint you here, I really don't know what's needed to do that. It's possible that color calibration is already built in to Mir (I'm sure it is), so that'd be the first lead to follow. @alan_g?

Not a full answer, but essentially "blue light filtering" amounts to customising the gamma curves. Mir supports setting the gamma curves as part of the display configuration: this allows more general "display calibration" than "blue light" but is the way to do it.

So far as I can recall this has not been used outside if the tests, and I can't say whether any of it works with your libhybris/android "platform".

It would be an interesting "exercise for the reader" to try implementing "blue light filtering" in one of the Mir examples.

Seeing the above question about integrating Wayland I think it would be good time to explain how some things fit together:

1. "New Mir"
2. "New Unity8"
3. Replacing Xmir with Xwayland
4. Enabling apps using toolkits that support Wayland
5. Migrating existing apps to Wayland
6. Migrating compositior components to Wayland

@Leppa said in Ubuntu on Huawei devices?:

the chinese government can ask for whatever data they, want, and get it

This is hardly unique (c.f. https://www.govinfo.gov/content/pkg/PLAW-107publ56/html/PLAW-107publ56.htm), and is not the regulatory obstacle to shipping Ubuntu Touch in China.

But, regardless of regulatory concerns, the commercial reality is that Huawei can continue to use the open parts of Android and already have replacements for Google services they could roll out worldwide. For them that is far less risky than switching to something that is far less mature, and unproven in any commercial market.

Is there any plan to replace Mir?

An oft asked question has arisen on the Telegram channel once again and I thought I'd post an answer here for posterity:

Is there any plan to replace Mir? Since it's completely abandoned, it may take too much effort to maintain it, and it may better to switch to Wayland, if it's possible, since it has way more support. - so manpower could be used somewhere else (PWA maybe?)

Greatly exaggerated

"I can understand perfectly how the report of my illness got about, I have even heard on good authority that I was dead. [A cousin] was ill in London two or three weeks ago, but is well now. The report of my illness great out of his illness,. The report of my death was an exaggeration." - Mark Twain

Like the reports of Mark Twain's death, Mir's abandonment is based on a misconception.

There's a lot of confusion about this because "the internet" has confused toolkits supporting the mirclient API with servers using the Mir libraries. These are two different stories.

The mirclient API

The mirclient API is a way for application toolkits (and other client-side libraries) to use Mir. This API is abandoned: it is no longer under development and the Mir developers have deprecated it and will remove it "someday". I think UBports is the only remaining project to use it (the Mir support in Kodi, SDL2, gtk3, etc has been dropped).

UBports do need to switch from using the mirclient API to using Wayland before "someday" becomes "today". That is a multi-step process described here: The Way to Wayland (for Unity8)

The Mir server libraries

Mir was the core of Canonical's effort to enable "Convergence". [See: https://forums.ubports.com/post/18392 for my take on "Convergence"]. These libraries are still supported and developed by Canonical and there are a number of projects using them or planning to use them. Canonical has IoT projects, some experimental "desktop" work (including with MATE).

There is no reason for UBports to switch from using the Mir server libraries, they are the foundation on which Unity8 (and some other, less visible, components) are built. Even with the issues presented by the switch to using Wayland for applications the support for "Convergence" is unique to Mir and core to UBports.

@guru said in xev like tool to see key_press (...) events:

Is the OSK used to route the chars to the terminal-app when the key-events (and mouse events) come from a Bluetooth device?

No.

At least the OSK is not visible in this case on the screen.

Exactly.

Where I could check the sources for the OSK?

They'll be on github or gitlab (UBports are migrating projects from one to the other).

I suspect you are misunderstanding me: OSK is not the solution you asked for, but it is the only process that does anything even vaguely like what you want. So, if you figure out how it is able to do that, you might be able to use that knowledge to create something new to remap input.

I suggest that writing a new terminal app (or enhancing the existing one) with the ability to remap input would be far simpler.

@guru said in xev like tool to see key_press (...) events:

In plain old X11 there is a tool xev to read and understand what the Xserver gets as key-pressed, key-release etc. events and one can map these with another command xmodmap to characters the application receives.
How I could do this within UT? Is there some app to read native from the keyboard? Or some undocumented logging?

Mir (and therefore Unity8) takes the view that applications should not be able to "spy" on the input to other applications. So, in UT applications don't have access to input devices and only get key events that Unity8 routes to them.

As you may suspect, there's a special dispensation for the OSK to synthesise keyboard events and pass them (via Unity8) to the app. I don't know enough about how that works to know if it could help your scenario.