KDE Plasma Mobile — The Dev Log: April 2024 - June 2025
KDE Plasma Mobile — The Dev Log: April 2024 - June 2025
The Plasma Mobile team is happy to announce the developments in the project over the past few months! Housekeeping This blog post was completed much later than originally planned. In the meantime, several releases have taken place:
This blog post is already quite long, so it will omit changes merged for Plasma 6.5 (releasing in October, to be announced in a future post).
With the Plasma 6.2 release, we moved Plasma Dialer and Spacebar to the Plasma release cycle, allowing us to have consistent releases of the two apps. This completes our year long move to having all Plasma Mobile related projects released as part of wider KDE releases, streamlining the work for distributions and taking a load off us on having to maintain a separate release cycle!
In other news, a Fedora spin for Plasma Mobile was released! It will only be targeting devices that can currently boot Fedora (i.e. not ARM phones), but is very exciting nonetheless!
You're viewing a single thread.
While I love the idea, I just don't see this moving forward unless any of these projects can focus on splitting up these types of projects into a solid base, driver layer, and then UI layer. Instead they are all spending a ton of engineering resources building something from scratch.
So many projects have similarly started the same way and failed instead of working towards a base that replaces AOSP first, then spinning their own UI on top. The big device manufacturers figured out a decade ago this is the right way to go, and these small projects buck that and fail instead of just focusing on the thing they ultimately intend to focus on.
Get a good base that is removed from Google, THEN do this project.
solid base
GNU+Linux
driver layer
Linux
and then UI layer.
Plasma mobile
The split is already there, the problem is that most Android phone manufacturers never publish the drivers (let alone make them open-source) and the only way to get anything but stock image running is to just rip parts out of the stock image, which significantly limits what you can put below it (i.e. Linux version) and on top of it (i.e Android Java gubbins). And you can't "just replace AOSP", as it's a huge complicated thing (kind of by design) which allows vendors to tightly couple the drivers to the system image. The idea of all these "mobile Linux-es" is to get rid of AOSP entirely, replacing it with "desktop Linux userspace" (systemd, musl, D-BUS, NetworkManager, pipewire, upower, mpris, libnotify, Qt/GTK, Plasma/Gnome, etc etc etc). A DE is an integral part of this; you can't build and run Nova launcher just with Wayland and Pipewire but without Dalvik and Android SDK/NDK, and remaking all of that from scratch would be an insanely hard undertaking.
To put it another way,
Get a good base that is removed from Google, THEN do this project.
This project is required if you want to make a "good base", otherwise that "good base" would just be an empty TTY that you can't interact with because there's no on-screen keyboard; besides, that "base" is already there and has been for 20 years, what's missing is the drivers.
You have zero understanding of how this all works and is out together, so I'm going to ignore you.
It's so sad to see that voice of reason is trampled over like this. To see how bad is running Linux on phones, just ask the grapheneos folks. Linux phones have looong way to go compared to AOSP.
It matches my understanding of the Android situation. What is your issue?
I've built and run Mobile NixOS on my OnePlus 6 (without modem, fingerprint or GPU accel support but meh) before it became officially supported (this was relatively easy, compared to most other vendors, but did require a bunch of hacking to get the Linux fork OnePlus provides to work with the Nix kernel compilation machinery and the NixOS userspace).
I have also implemented initial support for running NixOS proper on Librem 5, packaged/fixed some stuff 1 2 3 (and more which didn't make it to nixpkgs) to make it semi-daily-usable with Plasma Mobile, and daily-used it for a couple of weeks and then on and off for a couple of months.
I know how mobile Linux works, from the bootloader to the kernel to the userspace to the DE to apps that run on it. I also have a cursory understanding of how Android works, enough to know that it's not feasible to build "a base that replaces AOSP", let alone make it work with vendor-provided driver blobs and Android apps. What manufacturers actually do is take AOSP, patch it to fit their needs/work with their shitty drivers, and ship it on the device as a bunch of blobs because it's Apache-licensed.
You hacked out a bare running Nix config for a phone...cool. I wouldn't call it an implementation of anything because all you did was hammer out configs, but good for you. Now you have a phone where half the hardware doesn't work, but Nix runs, so super awesome for you. Must be a great user experience.
Even in your comments on your link, you're proving my point. Without a solid BASE, and a DRIVER LAYER, you won't have a successful project to push a UI of anything, because packaging themall together doesn't make sense. All the major phone vendors know this, and have moved in that direction for awhile.
Why you came in here with your links to something that is literally saying the same thing as I am as if you are proving a point to somebody, I have no idea.
all you did was hammer out configs
Yeah, that's my point, all the software is there already, with a little bit of persuasion and glue it runs fairly well together. I'm not claiming I wrote actual drivers or whatever. What I did was figured out how to adapt the existing software to work on NixOS, so you can just take your desktop NixOS config, add a couple lines to it, and run it on the phone.
Now you have a phone where half the hardware doesn’t work
All hardware on Librem 5 worked with NixOS as I expected. The reason I'm not dailying it anymore is because the hardware kinda sucks, it's outdated and slow. If I could get the same software stack running on more modern hardware I'd gladly use it. Perhaps the battery life could be improved if the power management was better, but that's about my only complaint software-wise.
Without a solid BASE, and a DRIVER LAYER, you won’t have a successful project to push a UI of anything
I'm not sure what you mean by "solid BASE". Do you want to rewrite all of the existing software that implements the "desktop Linux" userspace? Who would be doing this and why, when existing stuff mostly works?
"DRIVER LAYER" in the FOSS world is just Linux. Drivers can live in the Linux tree or as small patches on top of it, with common open interfaces allowing compatibility between software and hardware. Just like they have been doing on the desktop for the past 30 years. The problem is plain: there are no open-source drivers or documentation for most phone hardware. Vendors don't have this issue because they have access to private documentation and the sources of proprietary drivers. Writing FOSS drivers requires reverse-engineering the proprietary drivers, which is very resource-intensive. The proprietary drivers that are there lock you into a particular Linux version (usually a very particular Linux version, and there's no way to solve this with any driver layer, at least without sacrificing performance and resource usage) and sometimes have proprietary interfaces with the userspace as well, which aren't easy to write a compat layer for (if that's what you're proposing). And in any case, if you are fine with proprietary stuff running in EL1, why not just run Android?
All this is completely orthogonal to making a DE on top of open standards, which is the point of open standards. For hardware that works with (mostly) mainline Linux, desktop userspace with plasma-mobile/phosh on top work well enough already. For hardware that doesn't, adding support is a lot of work, not because of any issues with the DE or userspace, but because hardware manufacturers don't publish the driver sources.
Pretty cool stuff hoesntly, and thanks for all the explanations. I have a question how did you deal with device trees, was that public available or did you make your own?
I have a question how did you deal with device trees, was that public available
Yes: https://source.puri.sm/Librem5/linux/-/tree/pureos/latest/arch/arm64/boot/dts/freescale
Purism are cool people and they have indeed built a smartphone that's as open as possible. The problem is that it's slow :( Not really their fault.
What is wrong with you? Why are you like this? Did you have a bad childhood? So fucking rude. Opportunity to educate but instead you discriminate. Only thing your comment shows is that YOU know nothing.
Not sure what you mean. Isn't the base just GNU/Linux?
Sort of. Whatever hardware these are intended to run on require something like 3X the driver code (at least in the case of the Android Linux kernel, according to Greg Kroah-Hartman). Phones tend to have more specialized and proprietary hardware, so you can't just take the standard Linux kernel, use it there, and call it a day.
But I'd be surprised if the people working on this weren't aware of that fact, and I hope they are working on abstracting the hardware layers more so that every mobile Linux project doesn't have to start from scratch every time.
Edit: source (YouTube, sorry) for the claim about how much driver code is required for mobile devices.
Phones tend to have more specialized and proprietary hardware, so you can’t just take the standard Linux kernel, use it there, and call it a day.
Eh, you sort of can on some phones, e.g. OnePlus 5 and 6; on some others it's just a couple dozen patches away from working.
But I’d be surprised if the people working on this weren’t aware of that fact, and I hope they are working on abstracting the hardware layers more so that every mobile Linux project doesn’t have to start from scratch every time.
The problem with other phones isn't "abstracting the hardware" (this is done by the Linux kernel), it's reverse-engineering the drivers so that they run on whatever kernel you want and use the open standards required by the "desktop linux" userspace. In fact, if you look at the "supported devices" list for all those mobile Linux distros you'll find a fairly similar set; that's simply all devices for which manufacturer's (or reverse-engineered) drivers are available. It's not like FOSS people are writing drivers specifically for their distro, which wouldn't work with any other - only corporate Android vendors do that!
I highly doubt that those "couple dozen" patches are trivial though. Even Pixel devices can't run the vanilla mainline kernel without a bunch of added code to make it work with the hardware (see: the Greg KH interview I linked).
And abstracting the hardware is what you do when you make drivers, so this is a distinction without a difference.
And abstracting the hardware is what you do when you make drivers
Yes, what I'm saying is that Mobile Linux people are typically doing just that, sometimes also trying to upstream it as well. I don't see how else they could be "working on abstracting the hardware".
That would make sense, though I was asking about the "solid base", not the "driver layer".
I mean, Linux is the driver layer, and you mentioned GNU (userspace) / Linux (hardware layer), and the Linux part of that solid base can't just be the vanilla Linux kernel that you'd run on a computer.
Yeah I could've phrased that better. I was thinking more process management, coreutils, networking, device interfaces, rendering, window manager, etc.
The base for Android is also Linux. But there is another layer. That is AOSP, which is comparable to your distro, then there's another layer of your UI (ie: MIUI, One UI, Nothing UI, Pixel UI, etc) which is comparable to your DE on Linux.
That second layer is what they're referring to. Currently everyone is just playing with the third layer (the DE), to my knowledge.
That is AOSP, which is comparable to your distro
AOSP is more than your distro, it's like the combination of all the gubbins that make your desktop computer work - rendering layer, compositor, unified device interfaces (like bluetooth or the battery), network management, audio, etc; whereas a typical Linux distro is simply a combination of all these already existing things.
It's just an analogy to get the point across. These details aren't really important.
Isn't that the UI layer they was referring to? I would think that the AOSP layer as summarized by balsoft is the solid base, which in Plasma mobile is GNU/Linux plus some basic stuff in the DE.
Naw
could you explain?
Do you think Android is "just" Linux?
Like the other commenter, you have no idea how this works. The people up voting me do.
Do you think Android is "just" Linux?
No? It's not even much Linux besides the kernel. By my second sentence I meant "Isn't [Plasma Mobile's solid] base just GNU/Linux?"
KDE is not a functional Linux distribution. It's a desktop environment.
So, no, it's not Linux at all.
Okay, what more needs to be in postmarketOS Plasma in order so that it has a "solid base"?
Literally in my post.
Sorry that I couldn't see where you included that. Could you do me a favor and quote what components exactly need to have work done for a solid base? (brownie points if they refer to postmarketOS's Plasma Mobile as a starting point) Note that I'm already aware of the driver layer issues. I'm really curious about this solid base you mention.