Thanks for coming, I'm here to talk about the missing 20% of current support for mobile
Linux.
My name is Luca Weiss, I'm a post-marketist core contributor, I've also had many
patches in the Linux kernel already, not really in the core kernel systems, but more on device
bring up and a few drivers and things.
I am maintaining the open-wares project and my data is in the software long-divided team
at Fairphone.
So if we look at how mobile Linux is currently looking in 2025, this is the list of devices
in post-marketers in the community, or phones in this year.
You can see green, it's working, orange, it's partial, like sometimes it's working,
or a part of it is working, and the white or gray is not available, but the white parts
are not working yet.
So you can see there's quite a good number of devices which are quite well supported already,
but there are no device also, like completely green or like you don't see a sea of green
unfortunately.
Yeah, so about there, let's go a bit back in history, so like if we look at, I don't know,
2016, for example, you can see there were basically only three devices in mainland Linux,
which were onboard, but I'm mostly focusing on core devices, because it's what I'm familiar
with, and also what most devices are used, or like most devices in mainland, are based
on the core control, even though there's also some mid-attack devices in some other
ones.
But yeah, back in 2016, there was basically only Nexus 7, which is a tablet or another phone,
Sony experienced that, and Sony experienced that one, which were like the only actual form
factor devices that there were.
There was a bunch of like single-bot computers and some test devices, but they are nothing,
apart from these three, nothing really good.
For arms 64, there was actually no single phone or tablet or something in there.
In August 2016, one of the devices that for the longest time was like the device with
mainland support, which was the Nexus 5, yeah, it got added in August 2016, and there
was also actually a pretty cool demo of the Nexus 7 tablet, running with the free-drainer,
open source graphics driver, running Android, but yeah, like from a kind of perspective,
it was working back then.
And then 2017, post-muggler started, as basically the first Linux distribution made for
mobile phones.
But yeah, also back then only two phones were supported, with 3.0 and 3.4 colour, respectively,
not mainland at all, so, and it was using the Western Compositor, which was the reference
for the most part, and yeah, and some demo apps for like DDK3 demo, so you can open
like the Witcher's demo.
So, it was really not super interesting, not at all, at what you would expect from a phone.
But also nowadays, already like there's a lot of more devices supported, obviously.
It's like with 34 devices, for 32 bits, it's Qualcomm, and they're not too many are being
added, because, yeah, no new devices being launched with 32 bits, but there are 64 bits,
we already have about 140 devices there, and I executed some like Chromebooks, where there's
like 10 different variants of it, and there's also quite a few more devices out of 3,
so not in mainland yet.
And yeah, quite a few of these devices can actually be used to some degree for daily driving,
so I mean, maybe just as a podcasting machine, so you download the podcast, you stream
into Bluetooth headphones, or, I don't know, YouTube machines, so you just have to browse
the open with YouTube, so like for these purposes, actually working quite well now, there's
even.
But yeah, and also this talk is mostly focusing about the kernel, the user space parts
are living on top of the kernel, so like if the kernel doesn't work, user space also won't
work for this feature, for example, I don't know, camera, but yeah, so like mainland
sort of works for these devices, but yeah, so if we look at the whole device, bring up,
that's basically two different important topics, there's functionality, it's like whether
a given feature works or works when you test it, and about reliability is about, does
it actually also work like the fifth time opening, does audio still work after being suspended
for two hours, does cameras switching work all the time and not get stuck randomly, and
then needing, needing reboot, so like device bring up what most people are doing is just
really looking at functionality, and it's not really testing reliability, but then reliability
is really what the people that try to use the phone actually notice and see, and this is
what they get annoyed about if it doesn't work, like if you want to use your camera and
to make it a photo, and then it doesn't work, because I don't know, there's some issue
somewhere, then yeah, and we get annoyed probably and not like using the phone as a daily
driver at least, yeah, and yeah, what you often use like, I just want working phone cards
please, this is kind of the most difficult because it requires so many different components
to work together, and also together with the spend, and maybe there's lots of ITE coming
at some point, and there's a lot of things that need to actually work properly there and
need a lot of extra work to make this work properly. And yeah, I also like, I will talk
a bit about this a bit later, but yeah, like we also need to figure out what we want to
achieve, like how we want to organize and make, for example, like one specific phone work
very well or something, so right now it's kind of a bit of a wide west, so like everybody does
what they want to do, and it's really cool, but of course, then not a single device is
then actually getting weathered by doing this. So yeah, let's look at the kind of the 20%
of the functionality that I'm missing, so I would say like for a lot of devices, like what you saw earlier
with the green and orange track boxes, like more than 80% is actually working for quite a lot of
devices, so it's really good, but it's also yeah, there's some things missing which are missing
for a lot of devices, so I mean, this place is working for basically all devices which are any
usable. When for example cameras, it's still quite a quite a topic where not a lot is supported
right now, but it's actually like in the last year, a lot of devices have gained cameras,
reports, so pixels 3A, a voice of God, two cameras working on the 155, so lots of things there,
there's some devices where the battery few gauge drivers missing or not working properly,
this is where you can see the battery percentage on your phone then. And then yeah, phone call,
it's kind of a difficult topic because there's so many edge cases and so many reliability things
that the Samsung's not work, but there also that it's always kind of a different set of
functionality that's not working for any given device. So like probably if you take some from
this device and some from this device, you probably have like a fully working device, like
bit across three phones, which is also not very useful. And yeah, yeah, and the bring-up for new
devices, like for new core-com devices, it's actually surprisingly trivial compared to like the
devices from I don't know, 5 to 8 years ago, because the SOCs are already, there's a lot of functionality
upstream already and most SOCs from core-com are only quite a minor variation from each other,
so while there might be some bigger or some bigger difference in the marketing from these come
from the SOCs, seem in the factors, it's there are quite similar to be fair. And yeah,
and I would say like if you start from scratch for completely for a completely unsupported
SOC in mainland, at least after like I don't know, after most of the day, you can after device booting
to something so that you can have a shell on it and after a couple of days or something, maybe a
week of full-time work or like a couple of weeks of like hacking on in the evening,
I think you can actually have a device working reasonably well, unless you hit some roadblock,
which you don't know how to resolve, which is a different problem. There's also the problem
that's getting some functionality in the kernel upstream is actually can be quite difficult for certain
things. So for example, for cameras are a good example, because cameras are quite complex,
there's normally no public documentation, even if the status hits available, they're often not
complete or not very useful to be fair. And there's a lot of kind of magic variables that people
who are not super familiar with how cameras or the communication works can be quite difficult to
then make a proper driver that actually handles the things correctly. So so that the case for the
both four and five, there's a vibration motor driver in there that is quite complex for what it should
do. So and there are also the documentation based on non-existent, it's difficult to get,
I mean, for me working at Fairphone getting through our ODM and to the actual supplier
is quite difficult, and since we don't have any documentation, it's tricky to know,
like which part should we configure it how exactly? Yeah, like things like this are
difficult. There's also, for example, audio amplifier drivers, often you can just copy
places downstream driver and it works, but then actually getting this into an upstream
image state, there's a lot of work, and they're just often, yeah, you don't really want to take
the time to do it. You don't want to spend a week rewriting a driver which was really bad in the first
place to try to get it to some states to be able to upstream it. Because it's not too much work,
to re-based those, like normally like every couple of releases you need to change a few lines
at most, maybe if the return type of the remove function has changed from inch to void,
then you need to change this, but otherwise it's not, it's not really extra work to maintain
this out of three, and for basically all devices, there will be a need for some patches on top of
mainland kernel in any case, so it's not like you can completely get away from doing this.
Yes. So let's talk about reliability. So we were talking about functionality, if it works,
and now reliability about, yeah, if it actually works all the time when you want to use it.
So when somebody's working and bring up, they're working on functionality, they look it, I don't know,
that's the touchscreen driver work, that's a recognize touchers. It's a different question like
whether the touchscreen also works correctly when you have your gloves on, where it might
need some extra code in there or something, or if it's, if it sometimes misses something, or
if the camera driver works all the time. So there's a lot of different things there,
and reliability is very often just ignored during this, during this stage, because it works
well enough for now, essentially. And yeah, developers like me, like I don't actually use the
device, like as a daily driver, I boot it up, test one thing that I'm currently testing,
and then reboot again to test a new test, an updated version of the same thing. So I don't have
the device running for multiple hours since then seeing like what things still work correctly, for example.
And I don't update every day and then see exactly if anything has changed and
or if anything has broken and then try to fix it. So I'm not quite sure like how to
resolve this like community-wise. If, yeah, basically you probably the developers,
like if there's only one person, they need to start actually using the device,
and then yeah, and then figure out what things are actually not working correctly, etc.
But it's just a lot of work, especially if it's only one person doing this all the time,
because there's a new kind of release every nine weeks of something, there's new stable release
for stable kernels, every week or something, and obviously if you run a rolling release distribution,
then package exchange every ten minutes, essentially. It's like making sure it actually continues
working all the time is quite a lot of work. And especially if you have multiple devices
in the same SOC that you're supporting, then you should probably test all of these devices.
So you really need to be very persistent there in doing this. But of course, and also like
if after a few months you kind of get bored of it essentially, then yeah, nobody is doing it
anymore. Which is an awesome not great. So now I'm talking about what we need, and like
we I defined here as kind of a group wanting to want to get like one device working perfectly well,
so like so it's usable by your grandma or at least your sister. And like it doesn't matter
which device in particular we are talking about, like just any device. And also like even if we just
want techies to use a device, so actually I have like their Linux command line and everything there,
like we still need to have it working reliably and well everything that we have.
So think to achieve this, like actually multiple different people or multiple people with different
roles need to kind of come together and focus on this one thing. So like kind of developers need to
kind of sit together and also just brainstorm sometimes to how to resolve some issues where
one person can just be stuck and just not not really have any good ideas in like how to continue
or how to debug the problem to resolve it. For example, getting the video decoder to work on some
ISOC, yeah. Then there needs to be just some testers that actually just look at it or yeah,
just make sure that that new releases be it stable because so very minor version upgrades are actually
major version upgrades to make sure this actually works correctly in this person. Maybe then also
uses the device for a bit longer for example, I don't know what some YouTube videos and see if this works.
And maybe some sort of product manager which kind of tries to hold it together, try to keep it
on track, try to maybe advise on like what is the best thing to work on now. For example, if there's
five features not working and then like which one is the most important for our target audience,
essentially. And yeah, what I mentioned before, I don't think a thing in person can do everything
at once because yeah, there's just not enough time in the day to do this. And also for people who
like to get started with kernel development or also testing, like I think any person who knows a
bit of git can already get started with with merging stable updates to the to the existing branch.
So for example, from six to 12, I'm just six or 12 to three, tag into it, into it, make sure
builds which it normally does. And then briefly test it or test it a bit further. And I think
anybody with some git experience or willing to learn git at a very least can do this. And even
even as a further than like rebasing the kernel on a new version or a new release kind of that from
the kernel, it's actually not not too difficult. You need, yeah, you need to know get rebays,
but it's for the most part it. And of course, if then something fails, you can ask someone who might
want to help you. But for just getting started with it, yeah, it's not necessary to be a big
kernel developer or something to do this. Yeah, and I think it's also really important to motivate
each other in the whole thing. And like if also the developers know that people actually
using it and are basically appreciating what you do, it is already helping to keep people motivated.
Because if you don't see anybody actually using it, it's like at some point you think like,
yeah, why do I actually do this? Why does spend so much time on this? If there doesn't seem to be
anybody interested in it. But if there's somebody coming along who's who looks very interested in it,
then things, I think, yeah, it can be quite motivating in my experience.
Yeah, and so yeah, we've looked at what happened in the last five to ten years, which is
everything that you see on phones now or on post-mugglers nowadays, has happened only in the
last five to ten years before there was nothing. So thing in the next five years, there will really
be a lot of progress. And maybe we are 80% of the weight there, but it will take at least another
five to ten years probably to make the other 80% to work. But yeah, I think it will definitely
become better, but we need to keep working, it makes sure to press along. And yeah,
we're getting closer every day essentially. Thank you.
Questions? One thing you didn't mention was device resource, and all that's in order to
all, you know, make devices and devices. Yeah, so for the device resource for a
parting manner, yeah. So I mean for devices where this is not provided by the dumps or not
provided in the dumps from kernel sources, you can essentially just decompile the dtb that's
running like the binary that's running on the device on the dumps from kernel and just work from that.
It's not source, but you can still work on that. It's no, it's no issue. I've tried this for some
random show me smart clock, and there's no kernel sources at all. I've asked from you about it.
The customer support basically said no, but yeah, you don't really need it strictly. I mean,
yes, the dumps from kernel sources are for most extent purposes very needed, but for the dtb,
you can decompile it, essentially. But yeah, can ask me later. Yeah.
There are any resources, for example, how to hit the camera, which are often not working,
or because navigating the Linux camera is glides over running at least for me. So I would like
need some pointers to help, and if there's anything available, there's a question, if there's any
resources for getting cameras working, and I think right now it is quite limited. There's
yeah, there's essentially many you can look at existing camera drivers or camera sensor drivers
and kind of see the structure. For the most part, it is an inner sequence of registered
rights that gets written to the device and then basically wanted to register to start streaming
and stop streaming, and that's it for the most part. And you can essentially dump this from the
downstream kernel to see like what inner sequence is running to the device, add some prints there,
and then start from that. In the best case, then you get a camera stream also with the same
sequence and mail-in, and you get a camera stream. If you just get a hang while reading the image
data, then there's something wrong, which is in the fun part, because and which are also
done now, how to how to really debug it. No more time for questions, but yeah, I think I
will be maybe outside, so you can ask me then. Thank you.