News and Update
The frequency of the Q&A broadcasts has reduced sharply but that doesn’t at all mean that activity has ceased.
Xenial base updates
Lots of performance improvements have gone into Xenial and most of those will find their way into Focal too. In some WebGL demos on capable phones the frame rate was jumping between 40 and 60. On the Pixel 3a it now sits solidly at 50. There was some bad behaviour of drivers, causing flicker. Now fixed. There were fixes to libdeviceinfo, so porters should look at the change, to see if they can implement the changes on their devices. Alexander has produced documentation to cover that. When ports have blurreddraw enabled, that will now function in Lomiri.
There are some aethercast improvements. Full HD 60fps mode is now supported. It is not perfect yet. For some reason 16x10 screens are having problems. The default 16x9 seems to be imposing itself.
New Bluetooth patches
Calls with Bluetooth headsets are a different problem (affecting only some devices). The update will not directly help with that. OTA23 crashed some things and that seems to have been caused by the (essential) update of Bluebinder.
It is a little bit flaky still but on supported devices double click to wake should now work. There is a new icon in Settings called Gestures. At the moment, the only item in the list there is the ability to switch double tap on or off. Other features can be added there, depending on device capabilities.
Other improvements and OTA-24
Alberto Mardigan has written a new ContactsSync. The big hope is that it will bring us into Nextcloud functionality, which we have wanted forever. We have to build an ecosystem around it so we will need to wait a bit longer for full integration.
There are some SMS messenger improvements and the Shift phone gets stable and rc channels.
We are losing some overlays for later Halium devices when updating, so OTA24 will be released when we have fixed all of that. As always, rc will release the things we are confident about and have finished.
Manuel asked which device developers used for testing UT. In response they held up lots of different phones. Testing has to take place on lots of different devices. They also need a load of different SIM cards for testing functions.
20.04 build and VolTE news
We are one item short of what we will call the Core Development Release. This is a version which developers will be able to evaluate. Most hardware is working in it. GPS still needs attention as does NFC. It can be ‘used’. What it does not have is OpenStore or any GUI mechanism for installing apps. Building the core has been most of the work. Filling in the gaps will be easier and quicker. It is not yet ready for users in general to play with but if you have a supported device that you don’t need and you have the technical skills to unpick a soft brick when it fails, you can try it out. Actually we want you to try it out because the feedback will assist and acclerate progress.
Already you can see the speed improvements against Xenial, even at this early stage.
It is not the Edge channel. If you want to try it you will need to go to the Ubports installer and look under Options. There you can enable ‘hidden channels’ and find 20.04. From now on, the progress will be visible rather than ‘under the hood’.
Laboratory is side hobbies, tinkering informally with UT. Fairphone 4 has two cameras and a depth sensor. The second camera is wide angle. It seems that we have the Qt interpreters already in our system and just need to implement the ‘choose second camera’ option. Marcin Kobuz has created a branch where we can test the software controls. Formally it works but if the camera requested is not found, there is a crash. It needs a bit more work.
Marius has been playing around with VolTE. He has got to the point of being able to make and receive calls and send and receive SMSs. It is still very hacky. Without any knowledge of the modem stack it seemed impossibly difficult but now we are getting some insights into how it works it is possible to see how the binary blobs are doing stuff. The way forward was to run Android and capture all the calls made to the drivers. Sailfish have some of it working so their solution provided tools too. The fixes so far are very specific. They will only support Qualcomm and every proprietary system has its own unique way of doing things. It is a horrible standard and no carrier even follows the standard. The modem is a black box with no outputs. To be honest, when it works, we don’t know why it works. It works perfectly well though, so result.
In the US, this is very important because 3G is mostly turned off and without VoLTE, UT phones are useless. In India the lack of VoLTE has been a problem for a long while and steadily other regions will be affected.
With Mediatek and other devices we will have to start completely from scratch. They have a different ecosystem. Anything earlier than Halium 9 will not benefit. That would be far more work than we are capable of.
A fun fact is that the Volla phones combined now number more than the Nexus 5 in the device stats. Volla uses Mediatek, so will have to address those chips at least.
Florian is trying to work on notification and selection of 5G for the Fairphone 4. Sailfish have got there already so hopefully they can help. There are four additional lines to go in ofono but not clear where to insert them in the thousands of lines.
Alfreds Qt plugin
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.
New porting guidelines
MrT10001 said there are 81 supported devices on the list but quite a lot of those are missing important functionality.
Our new porting guidelines will tighten this up. The best will qualify for inclusion in the installer; some will only make it to our infrastructure; others we won’t acknowledge at all. That will give porters an incentive to finish their work. With the move to 20.04 we will have to be quite selective about the devices we support because the core team has limited time available. The installer sends a lot of feedback to us about failed installs and a large proportion of that comes from phones where the porter has not put in a proper effort to make the device match the installer. This reflects very badly on Ubports and we really cannot go on tolerating it. If porters do not set correct parameters leading to soft-bricked devices, we will have to delete those devices from the installer
It is fine for people to play around with a device, to try porting as a challenge and to learn from their experience. Anyone who wants to do that is free to do it and we make no demands of them. When someone ports and then pitches that to our community under the Ubports/UT name then they take on responsibiities and they must meet the necessary quality standards.
In future, to enter the installer a ported device must be a properly functioning quality product. If a device is not in the installer, users should note that it is for fun or testing, not for use as a phone. Alexander from SHIFTphone has been setting out as an inspiration how Lineage deal with quality standards for their ports.
Our documentation is available to anyone, so if a porter does not want to comply with any of our standards, we will share how we build images, how we support them at a server level etc. They are even welcome to fork our installer if they want. Our rules apply to our brands and our community. Anybody is welcome to do their own thing.
The criticism that our documentation is not always as great as it could be is totally fair but of course we need people to step up and help write it. In a normal tech organisation you would have two or three full time documentation writers for the number of core developers we have.
Josue asked about the camera application and whether it could be replaced by the Megapixel app used in other Pinephone distros, because it has superior post-processing options?
Alfred thought that it was a GTK app, for Mainline. The cameras we use are Android cameras. They use their own protocol, entirely different from videoforlinux. So you would need to create an abstraction layer between the two and that starts to get very complicated.
We might very well ask why the Megapixel project decided to go their own way rather than adopting our camera app as the basis, given that it was around long before they started. There is no benefit in working together just for the sake of it, when for whatever reason they decided to ignore our software when they started their project.
Our software elements have been around for a very long time and have been subjected to technical and user testing exhaustively. A project without that test history is simply not going to be as solid. Apps don’t function in isolation they function within a complex ecosystem which itself has been intensively tested and improved. Slotting something new in would mean starting all that integration from scratch. Our operating is not experimental it is intended for use as a daily driver, so the standards of reliability have to be very high.
Of course we drop code but we only do that when the alternative is solid. If someone needs an ambulance, their UT phone must work. It is not just a fun project. Also the test is not whether it is ‘daily driver ready for tech nerds’. If you give the phone to your grandparent they should be able to pick it up and use it without any difficulty and without knowing any fixes. It is a consumer product which should not break when you use it.
If we can find a maintainer who gets really into our camera app and adds a load more features that will be great. But we have to find them.
With the camera function especially, devices have very sophisticated processing going on already inside the residual Android side and even in the physical camera element itself. That is how we get sharp, balanced, colour corrected and noise free images. It operates outside of the Halium ‘bubble’. There is no point in duplicating or second-guessing those functions, which operate differently for each device.
When you look at the interface, there are lots of features in Qt which we are not using, such as red-eye reduction and night compensation. They are there in the camera modules but we just don’t make use of them. We could do. If we attempted to shift post-processing into our own software, it would have to be programmed with defaults for 80 very different devices with a huge range of different camera sensors. That would introduce enormous complexity and bloat. On top of that we would do it less well. A lot less well. [At the moment we don’t capture images in RAW through the camera app, even though most of our devices can support that option. If we enabled that, users would have infinite post-processing options, out of camera.]
Impact of Dalton´s departure
Cliffcoggin asked about the impact of Dalton’s departure on the pace of UT development? Well there was disruption initially of course but we picked up fairly quickly and for both Xenial and Focal we are moving along faster than we have ever moved. We have added some new active developers and we are getting more assistance from businesses. Of course we would have preferred to have Dalton with us forever but we long ago planned for the day when we might lose key members of the team. It is just something that happens with any organisation. If Dalton tuned in, we would love to have you back!
Getting VoLTE working would be a big help with that. Difficult to have a core member who can’t actually use UT!
A quick note
A reminder that Waydroid is being developed by an independent team. They are not an official part of Ubports and they have their own Telegram group. You are welcome to ask them questions about it there.
Can we have a background image in Teleports? Put a bid in on the Gitlab page for Teleports and we will look at it as a feature request.
Thousandtopics also asked for a guide to port GTK apps to UT. It isn’t a trivial task because clipbooard, contenthub, notifications, camera and all the other things that need to be integrated. GTK has not been mobile friendly for a very long time so there will be an extensive need for boot-strapping.
Qt is where our expertise is and where our stack is, so expect that always to be the focus of our resources.
As to the point that Libertine buttons are too small, that is about the wrong sort of use. If you are making use of Libertine you should be working on a big screen, then you wouldn’t have the problem :)
PSingh asked about the pages feature (actually scopes) which were removed years back. Those were very complicated to maintain. The APIs were of poor quality. [There wasn’t just one thing called ‘Scope’ there were quite different things with the same arbitrary label]. They won’t be coming back…
UT on virtual machine
Is it possible to try out UT on my computer by a virtual machine or some other way? There is an emulator called PDK, so the answer is yes. It has a 20.04 base which you can investigate with keyboard and mouse but of course it will be UT in its desktop mode and that feels very different. It isn’t a ‘phone emulator’. You need to try it on a device. The emulator works on MacOS as well as Linux. Marius suggest you think of it as dry spaghetti and cooked spaghetti. Not exactly the same eating experience… The best idea is to get a Nexus 5 and play around with it. They are very cheap now. Of course it is way slower than our modern devices. That is not to say that it is a good phone to buy as a daily driver, especially with the impending move to 20.04. If you want to continue using a UT device, look for a Pixel 3a. They are not expensive these days. If you have money to splash around, go straight to the Shift phone or the Fairphone 4. For pre-installed (until Fairphone offers that) choose Volla.
Nexus 5 could see an update to 20.04. It isn’t impossible. But please don’t rely on that happening. Disappointment is possible too.
Tablets with Ubutnu Touch
Jordan asked which tablets will get 20.04? Jingpad is a possibility but not a very useful one as it is almost impossible to get these days. Lenovo M10 is a maybe. Generally, it is not looking good for tablets. We don’t have the device trees for the old BQ tablets, so don’t hold out any hope for them.
It was hinted (ahem!) that a new tablet may be announced ‘sometime’ (ahem!)
Pinetab is pretty much lost. The hardware itself has issues and Dalton was our enthusiast on that side of things.
Nexus 7? ROFL
Manuel asked whether proprietary hardware blobs are the biggest roadblock to device support? Simple answer. Yes.
Finally, Rodney has been playing with maliit and all that stuff, so watch out for a replacement for our keyboard module at some point.
Finally, we would like to throw open an invitation to someone to lead on getting out Q&A sessions, so if you would like to be a presenter, let us know. A once a month slot might be better than the fortnightly session we used to have. Bring your ideas too.
See you next time :-)