WEBVTT 00:00.000 --> 00:16.760 Hello everyone, so today I'm talking about running NOMOS on mobile phones, so I am part 00:16.760 --> 00:24.600 of the GNOME release team since 2018, I also have a GNOMOS maintainer and I work at 00:24.600 --> 00:29.880 the GNOME website, so what is GNOMEOS? 00:29.880 --> 00:38.680 Some of you might know it already, but for those who don't, GNOMEOS is GNOME's development 00:38.680 --> 00:46.360 team and QA operating system, in a way that's how we present it, it's not really for people 00:46.360 --> 00:54.000 who use it every day, though we might want people who work on GNOME, so who develop the GNOME 00:54.000 --> 01:02.720 desktop to use it every day, I do use it as a few other GNOME developers, designers as 01:02.720 --> 01:13.720 one, yeah, try to talk to the others, and yeah good, so they use it to test the new features 01:13.720 --> 01:20.240 as they develop it, so they can you see the new designs, how the new designs get implemented 01:20.240 --> 01:27.640 without having to build the latest version themselves, because that's what we do, we build the latest 01:27.640 --> 01:35.000 in development version of GNOME desktop and the core applications, and so when there are 01:35.000 --> 01:43.480 no built failures you can expect to get two new builds every day with the latest commits, 01:43.480 --> 01:49.720 and there are issues, issues and things don't work together, so when there are integration 01:49.720 --> 02:01.720 issues it may take a couple of days until someone fixes it, it's also an image based system, 02:01.720 --> 02:09.600 so if something breaks you could roll back to the latest version, generally it doesn't, 02:09.600 --> 02:17.840 because we have, well, it can break, but at least it boots, we don't get to the, because 02:17.840 --> 02:26.960 we have a pipeline that tests the system before publishing the images using OpenQA, we use 02:26.960 --> 02:33.760 system this is update for the updates and other tools from the system, the AirConsystem, 02:33.760 --> 02:47.000 the PCL lock system, the C6, with system extensions and all of that. 02:47.000 --> 02:55.600 So where do we run this, initially when it was first published back in 2020, we were only 02:55.680 --> 03:05.680 supporting the virtual machines and in particular GNOME boxes, because it had what's needed 03:05.680 --> 03:17.240 to run UEFI, wasn't really widespread back then, but now you can probably run it on other 03:17.480 --> 03:28.440 veteran machines, we started doing it on laptops, the stops, you might not always get the latest 03:28.440 --> 03:35.480 hardware or the more niche hardware might not be supported, you need to figure out to add the 03:35.480 --> 03:45.080 kernel, some kernel module to the configuration or something, but it mostly works and you can 03:45.160 --> 03:56.760 use it and you can contribute if something doesn't, we do have an AR64 version, which we don't 03:56.760 --> 04:04.200 really probably, we don't really talk about, if you are on the Matrix channel, you might get 04:04.280 --> 04:14.680 pointed to it, asking how do I run a veteran machine on the macOS, because yeah, so we have it's 04:14.680 --> 04:22.680 using, it works using UTM, I'm not really a macOS guy, but Jordan from the GNOMEOS team has 04:22.760 --> 04:41.720 macOS and answer questions, and this is the topic of this talk, so there are quite a few pieces 04:41.720 --> 04:49.560 of the puzzle to get this running, the first one is that regular, regular, they're super-wise, 04:49.560 --> 04:56.200 so it's not really like, something like both macOS, which tries to run on these Android devices, 04:56.840 --> 05:04.520 by building a kernel as an Android image and then putting the router fest in another partition, 05:05.480 --> 05:12.840 so it's a regular desktop OS, which expects to use and partition a disk and partition it, it could 05:12.840 --> 05:20.760 work if you manually install it, but it's generally not recommended, it could work if you have 05:21.400 --> 05:27.560 already have a partition table and you want and have some free space and you can install it alongside 05:27.560 --> 05:33.160 another system, you have to do it manually, it's not supposed to be in the installer, but it's 05:33.160 --> 05:39.640 possible, but we in general with an OS, with a desktop OS you need at least two partitions, 05:40.600 --> 05:45.960 the ESP, the ESI system partition, and the root partition of the system. 05:49.720 --> 05:55.320 We, for normal, as we need more, because we're using system D6 update, we have both A and B 05:55.320 --> 06:02.120 partitions for user, for slash user, and then we have a very deep partitions for these 06:02.520 --> 06:10.280 user partitions, and then we have the root partitions, plus the ESP, that makes a total of six, 06:10.280 --> 06:19.160 I think, and we also expect a UEFI compatible firmware and we've always did, so even from the 06:19.160 --> 06:29.560 beginning, we never supported BIOS boot, so how do we take these, make it work on a for 06:32.600 --> 06:41.480 the first pieces you would, you would probably, you know what you would is, it's boot loader, 06:41.480 --> 06:47.000 that was initially developed for embedded devices, but as over the year, I committed so many 06:47.000 --> 06:55.080 features that it can be used for almost everything, included as a replacement for UEFI firmware. 06:55.080 --> 07:10.360 Another feature of your boot is the block maps, so we can take what let's explain the first 07:10.360 --> 07:21.480 why, so we have these android files with a lot of partitions, in terms of them, and most of them, 07:22.760 --> 07:29.080 we don't need, but sometimes if you try to delete a partition, this will break the phone, 07:30.040 --> 07:35.400 and even if it doesn't, and you delete, for example, the user data partition, 07:36.360 --> 07:42.200 and then you try to create multiple partitions in there, instead it could break the phone, 07:43.960 --> 07:54.440 for instance, something we had with the break phones, but was that when the partition label was longer 07:54.440 --> 08:04.120 than 16 characters, I run them, I run them, but it would prevent it from loading into fast boot, 08:04.200 --> 08:10.840 so you could replace it. Fortunately, we have developed this on the OnePlus 6, 08:11.560 --> 08:17.320 which for which we can do ETL flash, so we could get them back. 08:19.720 --> 08:31.320 So we don't want this to happen to our users, so the block maps is a feature of your boot, 08:31.480 --> 08:37.640 that's kind of similar to the Linux device model, it can allow booting from 08:39.480 --> 08:47.320 unconventional places, so the examples in the U-Bot documentation are booting from a fit image, 08:47.320 --> 08:59.320 so you could extract some part of the fit image, and from an extra image downloaded of the 09:00.280 --> 09:08.680 network, so for networking, so the way we're using it is that we use the user data partition 09:08.680 --> 09:19.240 from Android, but it has a separate device, so like another hard disk, and then 09:19.480 --> 09:26.760 plug the partitions there and find the ESP, the various partitions, so you would can find the ESP there 09:26.760 --> 09:37.320 and boot whatever boot loader we have, system DE, boot, for instance, and then get the rest of the 09:37.400 --> 09:51.800 system code. But this, then the system needs to also know this, so in the GNOMOS in ETL, 09:53.000 --> 10:00.600 you have the U-dev rule to detect the Android user data partition and then mount it as a loop device, 10:01.160 --> 10:09.240 and then pull for the partitions there, and then Linux will find the end system DE 10:10.840 --> 10:17.640 auto, I found forget it, auto GPT generator or something like that, can find the different 10:19.400 --> 10:28.280 partitions and boot with that, and find the correct root partition and user partition in whatever. 10:31.560 --> 10:42.520 So, how to put this together, we could try to build everything ourselves, but we are 10:42.520 --> 10:51.720 kind of standing of the other people's work, this is a, you would not, not talk can, 10:51.960 --> 11:02.360 this is a project, a working progress, it's hosted on the post market OS, GitLab, but it's kind of 11:04.360 --> 11:13.000 a separate project, it aims to produce a U-boot build that supports all this and can be flushed directly 11:13.640 --> 11:21.000 in fast boot to your phone, for welcome these tools, so we have a few phones that are currently 11:21.000 --> 11:29.880 supported, and by using this we flash this to the boot partition on the Android phone, flash the 11:29.880 --> 11:41.240 GNOMOS image to the user data partition, and then it boots. So, what works and what does, that's the 11:41.320 --> 11:53.320 one, can I use it on my, can I daily try this, first thing it puts, that's a good thing, 11:56.920 --> 12:06.680 it's very basic things, it gets all the way to the graphical interface and have that machine working, 12:07.240 --> 12:16.760 Wi-Fi, so that we can update, update to the new version, because that was the first thing 12:16.760 --> 12:25.800 that needed to happen, because if not, you need to flash it every time that's not really useful, 12:26.760 --> 12:36.840 sensors, we've integrated the lib ssc and the patch for IO sensor proxy, so we have kind of 12:37.640 --> 12:45.320 working sensors, including the auto brightness and things like that, and mobile data, 12:45.880 --> 12:57.160 it works, if you're really know the, well, there is a readme file in the here, refers to 12:57.160 --> 13:03.880 read the price explained this, but it works and then sometimes it stops and you need to reboot 13:03.880 --> 13:15.240 the phone, just regular mobile image issues, and most importantly, we're only doing this for 13:15.240 --> 13:23.240 the OnePlus 6 and the Fair 4 5, so we're not trying to do it, like post-market OS support 13:23.240 --> 13:33.720 a maximum number of devices, where mostly want one device that can be used to develop, to test 13:34.680 --> 13:44.200 the GNOME apps, where we have a UI to work with mobile devices, some apps do, 13:44.840 --> 13:51.320 there used to be a time where people who test on the lib 5, things like about the phone, 13:51.720 --> 14:00.120 trying to get more powerful devices, if I may say so, so we're focusing on this too, 14:01.080 --> 14:08.600 other, other phones can be made to work, especially if we are in the same category of 14:11.240 --> 14:18.120 phones that can work with mainline Linux, so we're only carrying a few patches for the OnePlus 6, 14:19.560 --> 14:22.280 don't remember if you did the display of the touchscreen, 14:22.600 --> 14:32.200 other than that we're using a vanilla mainline Linux, we're not having a patches for every device, 14:35.000 --> 14:42.840 so what doesn't work? The first thing is that it's still GNOME shell, a regular desktop GNOME shell, 14:43.800 --> 14:53.640 and then it goes 200,000 resolution scale, so it doesn't go any higher because then the 14:53.640 --> 15:02.920 logic of screen size would be smaller, text is too small, so it's not really usable as a mobile, 15:02.920 --> 15:09.800 so we can't go to a 300% resolution scale, but that makes the logical size smaller than one 15:09.880 --> 15:19.320 of the shell supports, so it's not really usable, and the GNOME shell UI is really made for 15:21.000 --> 15:29.960 a mobile device, all you need is not working, and we don't know why, so obviously cause 15:29.960 --> 15:37.000 it can't work, if you don't have audio, and anything else we didn't think of testing, 15:37.000 --> 15:45.320 probably don't work, so I'm not saying this is something that you're ready to use, but we're 15:45.320 --> 15:57.960 hoping to get there, so where to go from here? So one thing we talked about is the GNOME shell 15:58.040 --> 16:07.320 desktop UI isn't really usable for a phone, a couple of years ago, there was a grant for 16:08.760 --> 16:18.120 I think it was Jonas, Tressler, who worked on kind of improving the GNOME 16:18.120 --> 16:24.920 GNOME shell experience to be usable on mobile, it kind of looks like Flash, so the UI part diamonds, 16:25.080 --> 16:34.280 et cetera, but those are using an older version of GNOME, so it doesn't really work with the latest 16:34.280 --> 16:39.960 version of GNOME, so we couldn't work, we couldn't just use this old version of 16:41.240 --> 16:50.920 mobile patches for GNOME shell and with the latest GNOME, so there is working progress to 16:50.920 --> 16:57.480 re-base them against the latest version, and then we can probably have that as a feature that 16:57.480 --> 17:04.600 gets enabled in GNOME OS, so you can switch between regular shell and the mobile optimized shell, 17:07.320 --> 17:14.840 and yeah, we want to try to focus on one device or maximum two and try to get them to a point 17:14.840 --> 17:27.160 where we can be usable, as a daily driver, and at least insofar as someone can have this as a secondary 17:27.160 --> 17:38.360 phone, so where you can just the apps work with it and not have everything works, even if it's not 17:38.680 --> 17:44.920 your primary phone, where you store your banking apps and private data, but at least it is 17:44.920 --> 17:54.280 usable for testing the apps and developing them, et cetera, so that's all for me, thank you. 17:54.360 --> 18:09.560 So you can join us on matrix from discuss and any questions? 18:09.560 --> 18:17.720 Yeah, you mentioned getting patches of GNOME mobile in GNOME OS, is there interest in getting 18:18.280 --> 18:25.560 mobile applications? Yes, so there is interesting getting them there, but 18:25.560 --> 18:31.880 if you repeat the questions, sorry, the question is, is there interest in getting the GNOME shell 18:31.880 --> 18:40.200 mobile patches upstream, so not only in GNOME OS, but in upstream GNOME shell, and yeah, there is 18:40.280 --> 18:49.640 interest to have that, but there is some disagreement between the GNOME shell main tables, so that 18:49.640 --> 18:57.480 thing, that will take some work, so it's not straightforward, not just get that, everything 18:57.560 --> 19:02.440 matters, some things are good to merge, some things are probably need to be reworked, 19:03.400 --> 19:15.240 and you want this? Yeah, I can use a note, no matter what, I'm going to find a way out of this, 19:15.240 --> 19:19.080 and something in all this case, even I use it to get something like a spot for some of this, 19:19.080 --> 19:24.360 like there's other things that seem very similar, like very close with it, so what has the 19:24.360 --> 19:29.160 or like to keep that thing in particular, and I'm wondering, is that something that does 19:29.880 --> 19:38.520 you share with these contacts, or is there any mode specific? Sorry, I'm not wrong, 19:39.400 --> 19:44.120 so you're talking about the GNOME mobile patches or GNOME OS? 19:52.120 --> 19:54.120 Ah, yeah. 19:59.880 --> 20:07.560 That's a hard feature, please, question. So there are some things in GNOME OS right now that 20:07.560 --> 20:15.880 don't work like on-fash, so some of these things might get fixed when we use the mobile patches, 20:15.880 --> 20:25.240 when we get them merged, or at least in GNOME OS. We already have feedback to GNOME OS, but it's 20:25.560 --> 20:37.080 probably not working with GNOME-shel OSK on-fash keyboard, because it doesn't make for mobile devices. 20:37.080 --> 20:43.560 It might be already fixed in the mobile fork, or maybe it's not, I don't know. 20:44.520 --> 20:54.520 Yeah, someone wants it to ask question, yeah? 21:02.520 --> 21:04.520 Sorry, I can't hear you. 21:05.480 --> 21:17.320 Yeah, I think all but one are implemented, I'm not sure, but yeah, they're mostly work, 21:17.320 --> 21:27.960 so for the proximity sensor works, but it's not used, the gyroscope, I'm not sure, 21:28.680 --> 21:38.040 the accelerometer, I think it works, but then GNOME-shel doesn't use it, we don't know why, 21:38.600 --> 21:48.200 things like that. That's what I mean by the kind of work, but that's not necessarily being used in the system. 21:49.160 --> 21:55.160 You said you want to focus on one core, but you have to tune both. 21:55.160 --> 22:05.880 Yes, so mostly when I'm planning to focus on the Fairphone 5, but the one plus 6 22:07.000 --> 22:14.360 was implemented first, so we can maybe focus on both, but we'd like to focus on the Fairphone. 22:19.160 --> 22:23.480 Anyone else? Thank you, God. 22:34.600 --> 22:44.600 I didn't have a video, but it is trying to put, that's really small on. 22:45.560 --> 22:51.960 Yeah, this glitch, for the beginning, once because the firmware isn't loaded early enough, 22:53.160 --> 23:01.240 then it's a very small spinner, and if you get video.