Ubuntu Touch Q&A 90
OTA-15 in testings, Pinephone 5.10 kernel testings, Miroil work

 
 
 

Looking for the Audio-only version

of the Q&A?  You're just one big orange

button away -->

News and Update

Presenting this time were Florian and Dalton initially, with Marius arriving late when his internet kicked back in :)
Go to devices.ubuntu-touch.io for info about whether your device is supported.

OTA 15 call for testing

The OTA-15 call for testing has gone out, ready for a December 16 release. There are supposed to be 4 to 6 weeks of pre-release prep plus 2 weeks of testing for each cycle. We are now starting to get back on that track after some diversions. Some Qt updates and some improvements for Volla are in there. In particular there have been some kernel config issues. Thank you very much to all who have given feedback, to make the update possible. Initiating calls by Bluetooth with Volla now works, as do many in car links. A big surprise is that we also have quite advanced support with in car systems, including calling contacts based on voice initiation. Front camera orientation in Volla is now fixed.

F(X) Tech Pro1 and Pixel 3a support have been added to the installer. New devices are now arriving very rapidly.

We now have easy swipe management of Morph tabs and tab previews work correctly. Dark theme now works in Morph and it has a new icon. Kudos to Daniel.

Integrating mobile Linux apps

Jonny commented on Dalton’s previous commentary on the difficulty of integrating apps between different Linux for mobile platforms. He drew attention to some work being done by Vannash on convergence-components. These provide an abstraction layer between Qt and different systems, so Qt apps can in principle work across platforms. A practical illustration of this is PureMaps, which trialed this approach. With it, you can build once and it will run for all. There are four platforms involved already, including Sailfish, Kirigami and UT. Qt 6 may have an impact on this to an extent but it is certainly not expected to remove the need for this type of abstraction.

PinePhone works

Dalton has been working on the kernel for PinePhone and PineTab. You can test the present state of his upgrade now. You can simply switch to the new kernel in Settings. It involves some moves from Qt 5.6 to 5.10 and some newer developments to better use the latter. The kernel patches will provide better hardware compatibility and security and changes lots of things. For Pine, WiFi now works. We have 60fps working now. But lots of big issues remain to be done. Biggest of those is that incoming calls do not produce a proper wake state. Calls also cannot be placed in 3g. The camera is not working at all. In addition, half the time when you try to boot the system it just doesn’t work. There is no way to get 100% battery charge and modem booting can be very slow. All of these problems are kernel issues.

In the older kernel configuration, the screen woke with an incoming call and the call display was initiated. With the rebuilt kernel, ofono now wakes up, looks around and then does nothing. The screen does not turn on and ofono does not get the cue, in the absence of that happening. Repowerd detects screen activation associated with a specific purpose. Ofono the needs screen to turn on before it triggers. Dalton tried delaying waking a bit longer to give ofono a chance to catch up. The problem with that is that it wakes up too late to catch the call. Bhushan checked inside modem. It runs its own small Linux system and has its own, different kernel. In effect, the PinePhone has four distinct CPUs. The AT protocol is one iteration of the call management function. The other is the QMI protocol specifically associated with Qualcomm hardware. Both protocols have been tried. QMI utilizes a small shared memory, sending prompts to the main Linux system. This is not mediated by software though. It is directly exported. This means that there is no opportunity to modify mediating software – because there isn’t any. There is something sending from there to main. Modem firmware directly exports QMI therefore does not look to be the answer. In theory a solution would be to monitor every wake up event for significance but that would be huge. The alternative is therefore to use AT instead. User space does receive input from AT but how to get ofono to talk to AT? Bhushan has now patched ofono to talk to AT to some extent.

Incoming phone call prompts do now transfer but unfortunately there is some sort of echo so they arrive twice. The workaround selects the second of these as a trigger but the state doesn’t return to normal. Marius suggested we ask Quectel to fix the issue but it isn’t clear how likely it is they would do that. QMI is unfortunately relatively undocumented. Marius suggested we might want to listen to both QMI and AT inputs. That ought to be possible because there is a plugin for Quectel which is capable of doing that. Lots more work is still needed to figure all of this out. Dalton has already spent 50 hours this week trying to do so. At present there is just a tangle of lots of sub-optimal solutions.

Going down the wrong path in development work is inevitable but it does mean that you learn a lot from doing it. That is particularly worthwhile when it turns out that you can re-use a solution many times afterward, in different situations. Remember that with the major phone operating systems, none of this kind of exploration is even possible, let alone an opportunity to fix things.

OnePlus 5T and Pixel 2XL ports coming?

A community member has loaned a OnePlus 5T to Florian, to attempt some porting work. This should add to our Android 9 porting work generally. Konatantin from Austria has donated €200 to that effort by allowing the purchase of a Pixel 2XL. On the subject of Florian’s efforts on Halium 7.1, there are some people who just want to try out UT as an introduction, so the device being a daily driver doesn’t matter to them. It does mean though that 7.1 still has a role to play in attracting new users.  Android 9 is of course now the major way forward though for ported devices. 

Sponsors were thanked.
 

Questions

The News section of our Forum is the best place to post questions for the Q&A. YouTube live chat, Telegram and Matrix are other places to post a question.

If you didn't know, the Forum questions get priority.

Our build processes have been strengthened by new servers coming on stream. We can now build at twice the speed. Big improvements in Jenkins are on the way as a result.

Why keep old devices and what are the promoted ones

Steve asked why we bother with older devices such as Nexus 5 (which is now eight years old) rather than change focus to the newer i.e. Android 9 devices? Applee asked on a related note what are ‘promoted’ devices?

A lot of these terms are not documented and just kind of appeared. More work is going on to define what is meant by the maturity indicators we have assigned.

‘Core’ device likewise makes no sense and seems to imply some relation to ‘core developers’ where none is meant. Almost all of our devices come from the community. These labels were supposed to communicate something useful about their stability etc. but really they don’t. A community device might be quite broken. There are so many now that we cannot do QA on every one of them, only some. We have to base our assessments mostly on trust but there is a need for verification that is independent. OpenCuts is the mechanism which we hope to use to automate these checks. It can yield hard data which can then be made public.

This whole subject needs thinking about and refining. There is a forum discussion already taking place and it is worth joining, to express your view.

What about Marius

Marius has been ill for a while but has nevertheless been working on documentation for Lomiri and whole stack. He has even made a new webpage on it. At the same time he has been trying to make it more easily build-able, as it was very challenging. The new details will hopefully explain how to build Lomiri. In a further refinement, he has created a build with the phone components removed. With building very much easier now than it was, it should be much more realistic to try it out on other systems.

This should benefit the Miroil work, adapting Mir for Lomiri.

Are N5 and OPO going to use 7.1 Halium

Stan Wood asked whether the new (old) port is nearly complete. Are Nexus 5 and OPO finally going to 7.1? What has happened with that? Florian is trying to set up an online hackathon with German developer group, in the very last days of the year. So the answer may be ‘soon’.

Why we still keep and work with 7.1 Halium

Gizmochicken asked why bother working on getting 7.1 to very old devices when we could put that effort into the Android 9 GSI? As we have said before, we have a huge amount on our plate. We need to make a start with 20.04, Mir etc and also X86 Lomiri. While we don’t want to be sidetracked, we are going about as fast as we reasonably can. Short and long term work both have to be done and the balance between them has to be managed. We have to consider newly arriving users at the same time as keeping our existing users happy. Right now a lot of the work done by core developers consists of merging what volunteers have produced. The 7.1 work is nearly all done by Florian and he is not a paid employee. He is free to make his own choices. Apps work is likewise almost entirely done by volunteers. 5.12 Qt work is proceeding and that is one of the core-conditions for 20.04.

An OTA normally has only one big item. New build Android 9 based hardware launches have dictated  a lot of recent work. We are looking to contract out more but growing too fast is also dangerous. For example, Dalton would get overworked on the management of that. We also have to make sure we don’t mess up our tax status etc. It is pretty amazing that we were still able to top in 2020 what we did in 2019, despite all the problems caused by Covid. Along the way, we have lost some people who had to switch to other priorities.

The launch of systemd will be very hard. “90% has been done and we have 90% left” because the stuff that remains is so hard. Rachanan has brought open gl support to libhybris. Lots of other prep is being done for 20.04. Lots of issues were solved when we were working to bring Lomiri to Manjaro and Debian. It has become ‘easier’ but not ‘easy’. This effort has a very long lead in time, as we fully expect it not just to pave the way for 20.04 but also for 22.04.

Florian added that this is by no means the end of the matter. We also need to do a lot of work with network-manager and other upstream packages. There is an awful lot there to inspect.

“Like a rocket. When you go, you go” – said Marius :)

Lomiri naming

Alan asked about the Lomiri naming switch. We own lomiri.com and will be moving material there soon from unity8.io

Q&A 91

There will be one more Q&A before Christmas.

Your feedback would be very welcome please about any aspect of this Q&A but especially about the in depth treatment of a subject (in this case PinePhone and the kernel challenges). Do you like this approach? Good or bad?

See you next time :-)







Call for Testing: Ubuntu Touch OTA-15