WEBVTT 00:00.000 --> 00:24.240 Thanks for coming, I'm here to talk about the missing 20% of current support for mobile 00:24.240 --> 00:25.240 Linux. 00:25.240 --> 00:31.000 My name is Luca Weiss, I'm a post-marketist core contributor, I've also had many 00:31.000 --> 00:35.640 patches in the Linux kernel already, not really in the core kernel systems, but more on device 00:35.640 --> 00:38.280 bring up and a few drivers and things. 00:38.280 --> 00:42.600 I am maintaining the open-wares project and my data is in the software long-divided team 00:42.600 --> 00:45.760 at Fairphone. 00:45.760 --> 00:52.480 So if we look at how mobile Linux is currently looking in 2025, this is the list of devices 00:52.480 --> 00:56.760 in post-marketers in the community, or phones in this year. 00:56.760 --> 01:01.120 You can see green, it's working, orange, it's partial, like sometimes it's working, 01:01.120 --> 01:06.520 or a part of it is working, and the white or gray is not available, but the white parts 01:06.520 --> 01:09.120 are not working yet. 01:09.120 --> 01:13.920 So you can see there's quite a good number of devices which are quite well supported already, 01:13.920 --> 01:19.160 but there are no device also, like completely green or like you don't see a sea of green 01:19.160 --> 01:20.160 unfortunately. 01:20.160 --> 01:27.240 Yeah, so about there, let's go a bit back in history, so like if we look at, I don't know, 01:27.240 --> 01:33.840 2016, for example, you can see there were basically only three devices in mainland Linux, 01:33.840 --> 01:39.640 which were onboard, but I'm mostly focusing on core devices, because it's what I'm familiar 01:39.640 --> 01:45.840 with, and also what most devices are used, or like most devices in mainland, are based 01:45.840 --> 01:49.880 on the core control, even though there's also some mid-attack devices in some other 01:49.880 --> 01:50.880 ones. 01:50.880 --> 01:55.800 But yeah, back in 2016, there was basically only Nexus 7, which is a tablet or another phone, 01:55.800 --> 02:00.360 Sony experienced that, and Sony experienced that one, which were like the only actual form 02:00.360 --> 02:02.480 factor devices that there were. 02:02.480 --> 02:07.520 There was a bunch of like single-bot computers and some test devices, but they are nothing, 02:07.520 --> 02:10.160 apart from these three, nothing really good. 02:10.160 --> 02:16.560 For arms 64, there was actually no single phone or tablet or something in there. 02:16.560 --> 02:21.520 In August 2016, one of the devices that for the longest time was like the device with 02:21.520 --> 02:27.440 mainland support, which was the Nexus 5, yeah, it got added in August 2016, and there 02:27.440 --> 02:32.880 was also actually a pretty cool demo of the Nexus 7 tablet, running with the free-drainer, 02:32.880 --> 02:37.920 open source graphics driver, running Android, but yeah, like from a kind of perspective, 02:37.920 --> 02:40.360 it was working back then. 02:40.360 --> 02:45.440 And then 2017, post-muggler started, as basically the first Linux distribution made for 02:45.440 --> 02:46.440 mobile phones. 02:46.440 --> 02:53.960 But yeah, also back then only two phones were supported, with 3.0 and 3.4 colour, respectively, 02:53.960 --> 03:00.800 not mainland at all, so, and it was using the Western Compositor, which was the reference 03:00.800 --> 03:05.680 for the most part, and yeah, and some demo apps for like DDK3 demo, so you can open 03:05.680 --> 03:06.680 like the Witcher's demo. 03:06.680 --> 03:14.760 So, it was really not super interesting, not at all, at what you would expect from a phone. 03:14.760 --> 03:19.760 But also nowadays, already like there's a lot of more devices supported, obviously. 03:19.760 --> 03:28.120 It's like with 34 devices, for 32 bits, it's Qualcomm, and they're not too many are being 03:28.120 --> 03:33.000 added, because, yeah, no new devices being launched with 32 bits, but there are 64 bits, 03:33.000 --> 03:38.960 we already have about 140 devices there, and I executed some like Chromebooks, where there's 03:38.960 --> 03:45.080 like 10 different variants of it, and there's also quite a few more devices out of 3, 03:45.080 --> 03:48.000 so not in mainland yet. 03:48.000 --> 03:53.520 And yeah, quite a few of these devices can actually be used to some degree for daily driving, 03:53.520 --> 03:58.800 so I mean, maybe just as a podcasting machine, so you download the podcast, you stream 03:58.800 --> 04:04.440 into Bluetooth headphones, or, I don't know, YouTube machines, so you just have to browse 04:04.440 --> 04:09.200 the open with YouTube, so like for these purposes, actually working quite well now, there's 04:09.200 --> 04:12.200 even. 04:12.200 --> 04:16.520 But yeah, and also this talk is mostly focusing about the kernel, the user space parts 04:16.520 --> 04:22.000 are living on top of the kernel, so like if the kernel doesn't work, user space also won't 04:22.000 --> 04:31.720 work for this feature, for example, I don't know, camera, but yeah, so like mainland 04:31.720 --> 04:39.240 sort of works for these devices, but yeah, so if we look at the whole device, bring up, 04:39.240 --> 04:43.400 that's basically two different important topics, there's functionality, it's like whether 04:43.400 --> 04:50.040 a given feature works or works when you test it, and about reliability is about, does 04:50.040 --> 04:55.000 it actually also work like the fifth time opening, does audio still work after being suspended 04:55.000 --> 05:00.120 for two hours, does cameras switching work all the time and not get stuck randomly, and 05:00.120 --> 05:05.400 then needing, needing reboot, so like device bring up what most people are doing is just 05:05.400 --> 05:13.160 really looking at functionality, and it's not really testing reliability, but then reliability 05:13.160 --> 05:19.680 is really what the people that try to use the phone actually notice and see, and this is 05:19.680 --> 05:23.360 what they get annoyed about if it doesn't work, like if you want to use your camera and 05:23.360 --> 05:27.840 to make it a photo, and then it doesn't work, because I don't know, there's some issue 05:27.840 --> 05:32.960 somewhere, then yeah, and we get annoyed probably and not like using the phone as a daily 05:32.960 --> 05:42.480 driver at least, yeah, and yeah, what you often use like, I just want working phone cards 05:42.480 --> 05:47.440 please, this is kind of the most difficult because it requires so many different components 05:47.440 --> 05:52.400 to work together, and also together with the spend, and maybe there's lots of ITE coming 05:52.400 --> 05:58.800 at some point, and there's a lot of things that need to actually work properly there and 05:58.800 --> 06:04.880 need a lot of extra work to make this work properly. And yeah, I also like, I will talk 06:04.880 --> 06:10.640 a bit about this a bit later, but yeah, like we also need to figure out what we want to 06:10.640 --> 06:18.560 achieve, like how we want to organize and make, for example, like one specific phone work 06:18.560 --> 06:22.960 very well or something, so right now it's kind of a bit of a wide west, so like everybody does 06:22.960 --> 06:28.080 what they want to do, and it's really cool, but of course, then not a single device is 06:28.080 --> 06:37.040 then actually getting weathered by doing this. So yeah, let's look at the kind of the 20% 06:37.040 --> 06:42.560 of the functionality that I'm missing, so I would say like for a lot of devices, like what you saw earlier 06:42.560 --> 06:48.560 with the green and orange track boxes, like more than 80% is actually working for quite a lot of 06:48.560 --> 06:55.200 devices, so it's really good, but it's also yeah, there's some things missing which are missing 06:55.200 --> 07:00.960 for a lot of devices, so I mean, this place is working for basically all devices which are any 07:01.920 --> 07:08.880 usable. When for example cameras, it's still quite a quite a topic where not a lot is supported 07:08.880 --> 07:12.720 right now, but it's actually like in the last year, a lot of devices have gained cameras, 07:12.720 --> 07:19.120 reports, so pixels 3A, a voice of God, two cameras working on the 155, so lots of things there, 07:20.720 --> 07:25.440 there's some devices where the battery few gauge drivers missing or not working properly, 07:26.000 --> 07:31.600 this is where you can see the battery percentage on your phone then. And then yeah, phone call, 07:31.600 --> 07:38.000 it's kind of a difficult topic because there's so many edge cases and so many reliability things 07:38.000 --> 07:44.960 that the Samsung's not work, but there also that it's always kind of a different set of 07:46.080 --> 07:50.880 functionality that's not working for any given device. So like probably if you take some from 07:50.880 --> 07:54.320 this device and some from this device, you probably have like a fully working device, like 07:54.320 --> 08:02.320 bit across three phones, which is also not very useful. And yeah, yeah, and the bring-up for new 08:02.320 --> 08:08.320 devices, like for new core-com devices, it's actually surprisingly trivial compared to like the 08:08.320 --> 08:15.200 devices from I don't know, 5 to 8 years ago, because the SOCs are already, there's a lot of functionality 08:15.200 --> 08:21.040 upstream already and most SOCs from core-com are only quite a minor variation from each other, 08:21.120 --> 08:28.000 so while there might be some bigger or some bigger difference in the marketing from these come 08:28.000 --> 08:36.400 from the SOCs, seem in the factors, it's there are quite similar to be fair. And yeah, 08:36.400 --> 08:42.880 and I would say like if you start from scratch for completely for a completely unsupported 08:42.880 --> 08:49.600 SOC in mainland, at least after like I don't know, after most of the day, you can after device booting 08:49.600 --> 08:55.920 to something so that you can have a shell on it and after a couple of days or something, maybe a 08:55.920 --> 09:00.480 week of full-time work or like a couple of weeks of like hacking on in the evening, 09:00.480 --> 09:05.200 I think you can actually have a device working reasonably well, unless you hit some roadblock, 09:05.200 --> 09:11.360 which you don't know how to resolve, which is a different problem. There's also the problem 09:11.360 --> 09:16.720 that's getting some functionality in the kernel upstream is actually can be quite difficult for certain 09:16.720 --> 09:23.040 things. So for example, for cameras are a good example, because cameras are quite complex, 09:23.040 --> 09:27.920 there's normally no public documentation, even if the status hits available, they're often not 09:27.920 --> 09:34.960 complete or not very useful to be fair. And there's a lot of kind of magic variables that people 09:34.960 --> 09:41.040 who are not super familiar with how cameras or the communication works can be quite difficult to 09:41.040 --> 09:48.640 then make a proper driver that actually handles the things correctly. So so that the case for the 09:48.640 --> 09:57.840 both four and five, there's a vibration motor driver in there that is quite complex for what it should 09:57.840 --> 10:04.960 do. So and there are also the documentation based on non-existent, it's difficult to get, 10:04.960 --> 10:10.160 I mean, for me working at Fairphone getting through our ODM and to the actual supplier 10:10.240 --> 10:15.120 is quite difficult, and since we don't have any documentation, it's tricky to know, 10:15.120 --> 10:23.200 like which part should we configure it how exactly? Yeah, like things like this are 10:24.480 --> 10:29.680 difficult. There's also, for example, audio amplifier drivers, often you can just copy 10:29.680 --> 10:33.840 places downstream driver and it works, but then actually getting this into an upstream 10:33.840 --> 10:43.680 image state, there's a lot of work, and they're just often, yeah, you don't really want to take 10:43.680 --> 10:50.080 the time to do it. You don't want to spend a week rewriting a driver which was really bad in the first 10:50.080 --> 10:56.240 place to try to get it to some states to be able to upstream it. Because it's not too much work, 10:56.240 --> 11:02.080 to re-based those, like normally like every couple of releases you need to change a few lines 11:02.800 --> 11:07.120 at most, maybe if the return type of the remove function has changed from inch to void, 11:07.120 --> 11:10.880 then you need to change this, but otherwise it's not, it's not really extra work to maintain 11:10.880 --> 11:18.400 this out of three, and for basically all devices, there will be a need for some patches on top of 11:18.400 --> 11:23.600 mainland kernel in any case, so it's not like you can completely get away from doing this. 11:23.680 --> 11:32.880 Yes. So let's talk about reliability. So we were talking about functionality, if it works, 11:32.880 --> 11:37.760 and now reliability about, yeah, if it actually works all the time when you want to use it. 11:39.120 --> 11:44.320 So when somebody's working and bring up, they're working on functionality, they look it, I don't know, 11:44.320 --> 11:49.200 that's the touchscreen driver work, that's a recognize touchers. It's a different question like 11:49.280 --> 11:54.240 whether the touchscreen also works correctly when you have your gloves on, where it might 11:54.240 --> 11:59.520 need some extra code in there or something, or if it's, if it sometimes misses something, or 11:59.520 --> 12:02.960 if the camera driver works all the time. So there's a lot of different things there, 12:04.480 --> 12:10.880 and reliability is very often just ignored during this, during this stage, because it works 12:10.960 --> 12:19.920 well enough for now, essentially. And yeah, developers like me, like I don't actually use the 12:19.920 --> 12:25.040 device, like as a daily driver, I boot it up, test one thing that I'm currently testing, 12:25.040 --> 12:31.200 and then reboot again to test a new test, an updated version of the same thing. So I don't have 12:31.200 --> 12:35.920 the device running for multiple hours since then seeing like what things still work correctly, for example. 12:36.880 --> 12:42.320 And I don't update every day and then see exactly if anything has changed and 12:42.320 --> 12:48.320 or if anything has broken and then try to fix it. So I'm not quite sure like how to 12:48.320 --> 12:55.200 resolve this like community-wise. If, yeah, basically you probably the developers, 12:55.200 --> 12:58.720 like if there's only one person, they need to start actually using the device, 13:00.640 --> 13:05.200 and then yeah, and then figure out what things are actually not working correctly, etc. 13:06.880 --> 13:12.640 But it's just a lot of work, especially if it's only one person doing this all the time, 13:12.640 --> 13:17.040 because there's a new kind of release every nine weeks of something, there's new stable release 13:17.040 --> 13:25.040 for stable kernels, every week or something, and obviously if you run a rolling release distribution, 13:25.040 --> 13:30.320 then package exchange every ten minutes, essentially. It's like making sure it actually continues 13:30.400 --> 13:35.200 working all the time is quite a lot of work. And especially if you have multiple devices 13:35.200 --> 13:39.440 in the same SOC that you're supporting, then you should probably test all of these devices. 13:41.440 --> 13:49.120 So you really need to be very persistent there in doing this. But of course, and also like 13:49.120 --> 13:56.080 if after a few months you kind of get bored of it essentially, then yeah, nobody is doing it 13:56.080 --> 14:04.880 anymore. Which is an awesome not great. So now I'm talking about what we need, and like 14:04.880 --> 14:11.520 we I defined here as kind of a group wanting to want to get like one device working perfectly well, 14:11.520 --> 14:19.520 so like so it's usable by your grandma or at least your sister. And like it doesn't matter 14:19.520 --> 14:25.440 which device in particular we are talking about, like just any device. And also like even if we just 14:25.520 --> 14:30.160 want techies to use a device, so actually I have like their Linux command line and everything there, 14:32.000 --> 14:36.560 like we still need to have it working reliably and well everything that we have. 14:37.440 --> 14:42.800 So think to achieve this, like actually multiple different people or multiple people with different 14:42.800 --> 14:50.160 roles need to kind of come together and focus on this one thing. So like kind of developers need to 14:50.160 --> 14:55.520 kind of sit together and also just brainstorm sometimes to how to resolve some issues where 14:55.520 --> 15:00.960 one person can just be stuck and just not not really have any good ideas in like how to continue 15:00.960 --> 15:07.040 or how to debug the problem to resolve it. For example, getting the video decoder to work on some 15:07.040 --> 15:17.680 ISOC, yeah. Then there needs to be just some testers that actually just look at it or yeah, 15:17.680 --> 15:23.600 just make sure that that new releases be it stable because so very minor version upgrades are actually 15:23.600 --> 15:28.320 major version upgrades to make sure this actually works correctly in this person. Maybe then also 15:28.320 --> 15:33.840 uses the device for a bit longer for example, I don't know what some YouTube videos and see if this works. 15:34.640 --> 15:41.760 And maybe some sort of product manager which kind of tries to hold it together, try to keep it 15:41.760 --> 15:47.600 on track, try to maybe advise on like what is the best thing to work on now. For example, if there's 15:48.160 --> 15:53.440 five features not working and then like which one is the most important for our target audience, 15:53.440 --> 15:59.440 essentially. And yeah, what I mentioned before, I don't think a thing in person can do everything 15:59.520 --> 16:05.680 at once because yeah, there's just not enough time in the day to do this. And also for people who 16:05.680 --> 16:12.400 like to get started with kernel development or also testing, like I think any person who knows a 16:12.400 --> 16:19.120 bit of git can already get started with with merging stable updates to the to the existing branch. 16:19.120 --> 16:25.360 So for example, from six to 12, I'm just six or 12 to three, tag into it, into it, make sure 16:25.360 --> 16:30.880 builds which it normally does. And then briefly test it or test it a bit further. And I think 16:30.880 --> 16:38.320 anybody with some git experience or willing to learn git at a very least can do this. And even 16:38.320 --> 16:43.840 even as a further than like rebasing the kernel on a new version or a new release kind of that from 16:43.840 --> 16:48.960 the kernel, it's actually not not too difficult. You need, yeah, you need to know get rebays, 16:48.960 --> 16:54.160 but it's for the most part it. And of course, if then something fails, you can ask someone who might 16:54.480 --> 17:02.560 want to help you. But for just getting started with it, yeah, it's not necessary to be a big 17:02.560 --> 17:09.600 kernel developer or something to do this. Yeah, and I think it's also really important to motivate 17:09.600 --> 17:18.560 each other in the whole thing. And like if also the developers know that people actually 17:18.560 --> 17:26.640 using it and are basically appreciating what you do, it is already helping to keep people motivated. 17:26.640 --> 17:30.640 Because if you don't see anybody actually using it, it's like at some point you think like, 17:30.640 --> 17:35.040 yeah, why do I actually do this? Why does spend so much time on this? If there doesn't seem to be 17:35.040 --> 17:41.440 anybody interested in it. But if there's somebody coming along who's who looks very interested in it, 17:41.440 --> 17:45.840 then things, I think, yeah, it can be quite motivating in my experience. 17:46.640 --> 17:52.160 Yeah, and so yeah, we've looked at what happened in the last five to ten years, which is 17:52.160 --> 17:58.560 everything that you see on phones now or on post-mugglers nowadays, has happened only in the 17:58.560 --> 18:03.440 last five to ten years before there was nothing. So thing in the next five years, there will really 18:03.440 --> 18:09.200 be a lot of progress. And maybe we are 80% of the weight there, but it will take at least another 18:09.200 --> 18:21.200 five to ten years probably to make the other 80% to work. But yeah, I think it will definitely 18:21.200 --> 18:27.760 become better, but we need to keep working, it makes sure to press along. And yeah, 18:29.040 --> 18:32.400 we're getting closer every day essentially. Thank you. 18:40.160 --> 18:50.160 Questions? One thing you didn't mention was device resource, and all that's in order to 18:50.160 --> 18:57.040 all, you know, make devices and devices. Yeah, so for the device resource for a 18:57.040 --> 19:05.840 parting manner, yeah. So I mean for devices where this is not provided by the dumps or not 19:05.920 --> 19:10.560 provided in the dumps from kernel sources, you can essentially just decompile the dtb that's 19:10.560 --> 19:14.960 running like the binary that's running on the device on the dumps from kernel and just work from that. 19:16.720 --> 19:22.000 It's not source, but you can still work on that. It's no, it's no issue. I've tried this for some 19:22.000 --> 19:27.200 random show me smart clock, and there's no kernel sources at all. I've asked from you about it. 19:27.200 --> 19:35.440 The customer support basically said no, but yeah, you don't really need it strictly. I mean, 19:35.440 --> 19:41.920 yes, the dumps from kernel sources are for most extent purposes very needed, but for the dtb, 19:41.920 --> 19:47.840 you can decompile it, essentially. But yeah, can ask me later. Yeah. 19:47.840 --> 19:53.600 There are any resources, for example, how to hit the camera, which are often not working, 19:53.600 --> 20:01.280 or because navigating the Linux camera is glides over running at least for me. So I would like 20:01.280 --> 20:08.480 need some pointers to help, and if there's anything available, there's a question, if there's any 20:08.480 --> 20:14.000 resources for getting cameras working, and I think right now it is quite limited. There's 20:15.040 --> 20:19.760 yeah, there's essentially many you can look at existing camera drivers or camera sensor drivers 20:19.760 --> 20:24.640 and kind of see the structure. For the most part, it is an inner sequence of registered 20:24.640 --> 20:29.760 rights that gets written to the device and then basically wanted to register to start streaming 20:30.000 --> 20:37.040 and stop streaming, and that's it for the most part. And you can essentially dump this from the 20:37.040 --> 20:42.000 downstream kernel to see like what inner sequence is running to the device, add some prints there, 20:42.000 --> 20:47.840 and then start from that. In the best case, then you get a camera stream also with the same 20:47.840 --> 20:52.640 sequence and mail-in, and you get a camera stream. If you just get a hang while reading the image 20:52.640 --> 20:56.240 data, then there's something wrong, which is in the fun part, because and which are also 20:56.240 --> 21:06.000 done now, how to how to really debug it. No more time for questions, but yeah, I think I 21:06.000 --> 21:17.520 will be maybe outside, so you can ask me then. Thank you.