Thank you all and thank you all for attending this talk.
So yeah, I'll be talking about how we can improve our future as mobile Linux users,
especially with Mobian, but this all applies to other similar projects such as Postmarka
2S and so on.
So first question you might have is, who is this guy?
So basically I'm working as Senior Software Engineer at Colabora.
I'm dealing mostly with building and maintaining custom distributions for embedded systems,
so kind of related to what I do with Mobian.
I've been a long time Floss Introduce and I've been a DBN developer for a few years.
And back in 2020, so just the last first damn before the pandemic, basically, I got
my hands on a pine phone and this prompted me to work on that, work on mobile Linux in
general and start and still continue working on the Mobian project.
So what's actually Mobian?
It's a DBN derivative or in the DBN jargon we call that a blend, which targets mobile
devices such as smartphones and tablets.
It has a separate package repository and provides ready to use disk images you can flash on
a few devices.
It's actually a very small overlay on top of the DBN and we only provide currently 25
source packages in our repository compared to the vastly greater number which is in the
DBN, which means that technically of all the packages you have access from a Mobian device,
actually more than 99.9% of that is pure DBN.
And so we have a few packages with downstream patches which can't be upstream at the present
time.
Half of those are kernels, a few others are user space applications, which we're working
on dropping those patches and trying to find upstream friendly solutions.
We have also a few packages which are basically workarounds because the feature does not exist
in the upstream world, not yet at least one of those being for example, Millipixels, which
is the camera application for the Libram 5.
Once the Libram 5 gets supported by either or both megapixels and Lib Camera, we can basically
just drop this package and rely on upstream applications.
And finally we have six Mobian specific packages which are to be rewrote to be included in
the DBN itself so we can lower the impact of Mobian and the footprint of Mobian.
So we hope that we can get below 10 packages by the end of next year.
We'll see if we make it, but that's our end goal for now.
So latest developments, what happened the past year?
We had the first table release.
We just did the whole quotes around stable.
It's basically that we released Mobian Bookworm at the same time as the DBN Bookworm was released.
So that's our stable release.
It doesn't mean it's bug free.
It just means that we don't do huge upgrades and only targeted fixes.
So the system stays stable and keeps working as it works currently even after software
updates.
So it was released in June last year.
We have a few supported devices out of the box which are several Linux first devices,
the PinePhone, the PinePhone Pro, the Librem 5 also.
We support a few Android-based devices thanks to the work of the community, especially on
the SDM845 kernel support.
So we support the OnePlus 660 and the Pocophone F1.
And we also provide X86 images for desktop PCs or X86 tablets such as the Microsoft
Surface Pro and Go.
We provide a single desktop environment in this release which is Posh.
And we provide also up to today's 6.1 kernels.
So the 6.1 kernel is not the latest but the former one LTS branch, meaning it's supported
up until 2026 if my memory is good.
And we have a script in CI which is run daily and automatically rebases all the kernel packages
we have on 6.1 on the latest point release.
So basically when there's a security update, usually the day after or the same day, the
kernel is up to date in the Bookworm Update's repo which is basically our staging repo for
the stable release.
There are however a few things we wanted to include in this release that couldn't make
it.
First one is universal images.
The plan here would be to have a single kernel package for all supported devices.
It's working quite well for SDM 845 devices because they share already a single kernel
and the people working on those devices all put their patches into the same repository.
But for pine 64 devices for example which is based on all winner A64, rack chip, different
chips also.
It turns out that making a single kernel package out of those proved to be trickier than we
anticipated and so we basically dropped this effort at some point and focused on having
just per device kernels, at least for this release.
So we couldn't make universal images obviously.
We didn't find the time also to improve the hardware support of upstream.
We still carry lots of patches across for all the devices I mentioned.
It must be a total of 800 to 1000 downstream patches in the kernels only.
So that's quite a significant amount.
We'd like to get them upstream but we all had dead jobs and for now every day is still
24 hours only.
So we have to make choice.
Also we wanted to switch to the latest LTS kernel which is now 6.6 and finally realized
that we couldn't because we didn't have any time, any resources to spend on that.
So that means that Bookworm is stuck forever on 6.1 which is not too bad because the life
cycle of Bookworm will end in about a year and a half and until then this kernel will
still receive security updates and bug fixes.
So as long as Bookworm lives, the kernel lives along with it and we can get up to date and
avoid security holes anyway.
However, the next release which I'm about to talk is Trixie and is already on 6.6.
So what about the recent developments?
We try still to unify our disk images slowly.
Instead of aiming for a single image for all devices, we're taking a step along this path
and try to just ship one image per kernel.
Until now we have one image for the PinePhone, one image for the PineTab, another one for
the PinePhone Pro and the PineTab 2 and so on because some of those devices require hardly
specific tweaks to be included with configuration strips, Udev rules and so on.
And so we came to a point where actually most of these tweaks weren't needed anymore because
upstream had picked up and had the necessary features for those devices.
So we could envision having instead of having one image per device, having one image per
kernel.
And so we have our kernels per architecture basically, per sub architecture really.
We have one for the old winner, A64 devices.
We have one for the Rockchip-based devices which are the PinePhone Pro and the PineTab
2.
Two different socks from Rockchip but still we can use the same tree and so on.
It was already working well on the SDM845 devices but we took this step a few weeks ago
and so it quite reduced the number of images we were doing.
Regarding Qualcomm-based images we had until now one image for the SDM845 devices and another
one for the SMS225 which is basically the PhanPhone 4 because we used to maintain different
kernels for all of those.
This is going to change and actually already changed recently because we pretty much imported
all the patches we needed into a single kernel for all Qualcomm devices we support.
There are not many of those which is why we are managing to do that but for now we have
a single kernel which handles all the SDM845 devices, 1 plus 6 and so on, the PhanPhone
4 which has a different chip and also the PhanPhone 5 which has another different chip.
And so we have a single image for all Qualcomm devices and we just use a simple config file
at build time to generate the boot image for the device because although the root file
system are identical the boot images are really device specific because they need to have
the device tree appended and the specific RAM disk and so on.
But other than this boot image generation everything is handled at runtime using JoyJuicer
which fetches the binary firmware from the Android vendor partition because those devices
ship with Android first and so the firmware are already present on the device.
This makes things a bit easier for us because we don't have to care about the firmware license,
we don't distribute it, it's at runtime fetched from data which is already available on the
device.
And there's also a small package with QCOM 4 new tools which basically just includes
a few scripts and configuration for which are basically the same on all Qualcomm based
devices we support.
We're also adding in the process a simpler way to add new device support at least if
it's Qualcomm based.
The thing is until now we needed to have a kernel package in the Mobian repo and a few
specific tricks in the image build process.
We created a new target for these build scripts and build recipes basically which is QCOM
4WIP, it's kind of a dummy device but the thing is you can separately build or rather
cross compile your downstream kernel using the bin depth package make target which is
supported by the upstream Linux so you don't have anything specific to do there.
It generates a Debian package which you can drop into the Mobian recipes folder, edit some
config file, run the build script and it will provide you with a root FS image and a boot
image tailored for your device.
Then you can flash it using fastboot and hopefully celebrate that your device can run Mobian.
This is almost never that easy but the thing is we're moving the complexity from knowing
the internals of the build system to just debugging the kernel booting on your device.
So there's nothing Mobian specific in that, it's just general debugging and we basically
made it sure it was as simple as it could be from the Mobian side.
And we also have a small first-dem-present in the sense that Mobian now provides, it's
been a week since the first images were published but we now provide plasma mobile images.
It actually started over a year ago and the goal was to from the start have everything
in Debian itself rather than carry downstream packages in Mobian.
And so Marco, one of the Mobian developers, worked on that for more than a year and he
managed to get all the needed packages in Debian itself including the MetaplasmaMobile
Meta package which you just have to install, apt install PlasmaMobileFool for example and
it will put in all the packages you need and from there we could build our Mobian image.
So that's basically what happened over the last year.
Now what's next?
We're taking, trying to take a step further towards universal image.
So I've talked about the kernel issue, unifying all patches into a single kernel but actually
there's all this little device specific tweaks I mentioned earlier which have to be handled
and until now we have per device packages so that means one new package to have in the
repo for each new device we want to support.
This is an approach that doesn't scale at all.
I mean it works fine if you manage 10 devices.
If you aim for tens or maybe let's hope for hundreds of devices it's just too much work
for a small team.
So the idea here is to have a runtime service which will identify the device it runs on
using the device tree compatible property for example or the ACPI, DMI, vendor, manufacturer
and so on strings on x86.
Select or generate the needed config files, put them into a runtime generated Debian package
and install it on the device with the ability to place triggers on that so that when one
specific config file is modified by another package this tweaks package is regenerated,
rebuilt and updated as well.
So that's something we hope to achieve this year as well as getting closer to Pure Blend.
This is a specific class of Debian derivatives and it involves having all the packages into
the Debian repository.
So this is our next step once we have a working runtime tweaks management but basically this
would mean having all our meta packages, tweaks packages and so on into Debian itself so we
can just install everything Mobian from the Debian repository.
Not all hardware features will work unless you use the Mobian provided kernels of course
so Mobian will stay relevant for some time at least and we'll also be still able to
generate ready to use images which will make things easier for users rather than having
to build themselves from the Debian packages.
Another big topic is also the call audio management.
A few years back we created call audio which is a demon monitoring the phone call status
and switching audio profiles and routing on the go depending on the situation.
This was in a post-sodial world and back then post-sodial didn't really bother with such
things the only automatic switching it did was when you plug the headphones and so on
and we made sure that call audio did disable that on the post-sodial side.
But now we are living in a pipe wire world and with pipe wire comes a session manager
which by default is wire plumber and the session manager is meant to do just that switch audio
profiles switch the routing to match the current situation.
And so call audio raises with wire plumber most of the time it often loses so this means
that you're having a phone call and actually you don't hear anything in the phone earpiece
because wire plumber did the switching right after call audio instructed pipe wire to do
so.
So there's clearly a conflict there and the goal here is to make call audio basically a
part of wire plumber itself.
This needs some work in pipe wire to make it aware of the modem and to monitor the phone
call stages but we hope to submit an initial RFC implementation at some point this year.
No problem obviously.
And finally we plan for a few other minor improvements.
I mean most of the project development process and infrastructure is under documented as
it is most often the case.
So we have very user centric documentation written by users but we are very few developers
and we didn't take the time to do so.
So we'd like to improve that because basically a significant portion of the project has a
best factor of one which is me basically.
So I try to change that and make sure we have backup solutions and we get more welcoming
to other contributors.
And finally we'd like also to keep working on upstream device improvements.
The Pinefone Pro has a few low hanging fruits.
We can upstream probably easily.
The support for the Pinefone 2 is being merged upstream as we speak.
It now has a working Wi-Fi device.
We'll have to look if it can be upstream as well.
We hope to support also the Pinefone V or Pad 9.5 depending on how you see it which would
be the first week 5 device supported in Mobian.
And we also welcome obviously contributions to support more devices to help us with documentation
and to basically help us make the mobile future brighter for all of us Linux mobile users.
So here are a few links.
I put the slides.
Thank you very much.
Questions?
Hi.
So I was profoundly disappointed to read your blog post in October about the Travals
with the Pinefone kernel and the fact that essentially all of the work that had gone
into the Pinefone kernel in Meggy's kernel tree was not being upstream.
Which I presumed was the case really since the Pinefone had come along.
So I was just kind of wondering what had happened if anything had changed on that front if
Meggy was upstreaming patches now or anyone else and kind of what the situation was with
that.
For the original Pinefone the current situation is that someone in Mobian stepped up to maintain
and update this kernel.
He also started upstreaming a few patches and is monitoring the kernel mailing list
and working with upstream to improve the situation over time.
So there's lots of work to be done.
I know there's also another person which has started working on the driver for the Wi-Fi
chip which for now it was downstream real tech full of crap basically and nothing close
to being upstream able.
The new driver will be hopefully upstreamed and so that's already one big pain in the
ass which will be removed.
So now there's a bit more hope for the original Pinefone and if things continue that way then
it will probably be great.
So a question from the matrix.
Is there any plan to port the EG25 manager to LibGP-IoD 2.0?
Right, yeah EG24 manager is a very specific piece of software for the modem found in the
Pinefone and Pinefone Pro.
It's using GPIOs through LibGP-IoD and there's a new release which changed the API completely.
The thing is for now LibGP-IoD isn't packaged in Debian at least the version 2.
Version 1 is in Debian so yeah for now I don't have any definite plan.
The plan being once version 2 is in Debian then we go with it but before I'm not sure
I have the time to deal with all of this.
But much requests are welcome as always.
Yeah so a question regarding your tweaks approach.
So why do you want to build if I understood this correctly?
The tweaks on the device package them there and then install this package instead of having
just one package that carries all the tweaks.
The thing is we will have one package carrying all the tweaks but those tweaks can conflict
with each other.
You can have conflicting configurations for OGO for example and depending on the device
you have to select the right one.
You have also devices which can't suspend because otherwise they don't resume and other
devices which can do that.
So you have to select the appropriate tweaks and the idea of creating a Debian package
is that the packaging system is aware of those files.
If you have some files and the user shares something then it won't overwrite them with
a file from another package.
If we don't do a package on the device and install it then if we just move files around
the packaging system will not be aware of those and if at some point one Debian package
ships a file with the exact same name then it will break.
So that's the idea.
Alright please give another background of applause for Anu.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.