180
KDE Plasma Mobile — The Dev Log: April 2024 - June 2025 (plasma-mobile.org)
submitted 1 year ago by to c/linux@lemmy.ml
49 comments fedilink hide all child comments
 

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 are viewing a single comment's thread
view the rest of the comments
[–] 20 points 1 year ago* (9 children)

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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [+] -20 points 1 year ago (8 children)

    You have zero understanding of how this all works and is out together, so I'm going to ignore you.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 13 points 1 year ago* (last edited 1 year ago) (4 children)

    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 proprietary Android apps (which is what you're proposing?). 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [+] -8 points 1 year ago (3 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 9 points 1 year ago* (last edited 1 year ago) (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 8 points 1 year ago (1 child)

    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?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •