F41 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)

Project Discussion Change Proposals
,
1

:link: KDE Plasma Mobile Spin and Fedora Kinoite Mobile

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

A Fedora Spin using KDE Plasma Mobile and a Fedora Kinoite Mobile Bootable Container image.

:link: Owner

:link: Detailed Description

Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile brings its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops.

We propose to create a Fedora KDE Plasma Mobile spin and the corresponding Atomic variant: Kinoite Mobile (only Bootable Container images, no classic ostree variant).

:link: Feedback

Feedback has been positive thus far. As KDE Plasma Mobile has taken shape in Fedora, more and more people have asked for a spin so it is easier to setup on their machines.

:link: Benefit to Fedora

KDE Plasma Mobile will give Fedora a strong showing in the mobile market. Many other distributions that targeted the mobile market have concentrated on cellphones. We believe that by targeting all touchscreen devices, we can bring more users into the Fedora community.

:link: Scope

  • Proposal owners:

    • Spin configuration:
    • Work with RelEng to build:
    • Test Day coordination:

  • Other developers: N/A

  • Release engineering: Will submit issue once this is approved. #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: Will submit issue once this is approved.

  • Alignment with the Fedora Strategy: Yes.

:link: Upgrade/compatibility impact

N/A (not a System Wide Change)

:link: How To Test

Proper Fedora KDE Plasma Mobile Spin:

  1. Boot the Fedora KDE Plasma Mobile Spin ISO image either on bare-metal or in a virtual machine (V.M.).

  2. Confirm successful boot into a configured KDE Plasma Mobile environment with basic packages available.

  3. Launch Anaconda installer.

  4. Confirm no major issues with windows and display. The installed system uses sddm as the login manager and comes preinstalled with KDE Plasma Mobile as the default desktop environment and with default applications present for most use cases.

Repeat with Kinoite Mobile.

:link: User Experience

Users are able to consume KDE Plasma Mobile from https://spins.fedoraproject.org instead of installing another desktop and then manually installing KDE Plasma Mobile after the initial installation. Similarly for Kinoite Mobile.

The Spin should remain as minimal as possible and only include small supplements on top of making the default configuration workable. We should make the user experience as easy and simple as possible without defining too many opinions.

:link: Dependencies

N/A (not a System Wide Change)

:link: Contingency Plan

  • Contingency mechanism: Push this off to the next Fedora release
  • Contingency deadline: Beta Freeze
  • Blocks release? No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

This release brings the Fedora KDE Plasma Mobile Spin and its corresponding Atomic variant: Kinoite Mobile. Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile and Kinoite Mobile bring its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops.

Last edited by @ngompa 2024-06-16T18:35:58Z

4 Likes
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

1 Like
3

I love the idea, but I have reservations about new spins related to maintaining & alignment of packages and configurations:

We have a lot of spins, but although we still give our users the impression they are all equal but with different desktop environments, they actually have much bigger differences: I love the KDE Spin, which is well managed from the SIG in a way that ensures maintaining of the critical packages that are shipped with it, and that comes with some default configuration tailored for its target audience whereas system parts are aligned to each other (I tend to use the firewall as “indication”: Workstation and KDE come with a pre-configured firewall, at least some other spins don’t).

But when I checked the last time somewhen in 2023, we had spins whose major packages of the desktop environment itself have not been updated for over a year, while they came “blank” without alignment or adjustment/tailoring of configurations, which can impose noteworthy risks on users. Still we call it spin. So the question is what type of spin this will be.

If KDE Plasma Mobile and Kinoite Mobile will be maintained in the same manner as Kinoite and KDE Spin, I am 100% for this and I thank you for your efforts and contributions. I love it! And if it fits some hardware I have available, I will be happy to help with testing & issue reporting.

But if this cannot be guaranteed, and if there are risks as described, then I would be for postponing until this can be ensured. I hope that makes some sense :wink:

In any case, also thanks for bringing the topic into discussion!

1 Like
4

What devices/phones will this work with?

postmartketOS has Plasma Mobile images and can be installed on a good range of devices. I don’t think it’s beneficial for Fedora to be reinventing the wheel for a more-limited device list. I also don’t prefer to see Fedora doing it’s own thing entirely separate from pmOS infrastructure and fragmenting development. VoLTE is a fun adventure on OnePlus 6. What’s Fedora going to do about that, assuming they target OP6 at all?

If it’s being provided as just a desktop install image for people that want Plasma Mobile, that seems silly for another “official” spin. I could barely log into GNOME the past few Fedora versions; does the man-power really exist to be maintaining all these niche spins? And if it does, I think it should be put towards higher-priority things
 like being able to log-in consistently!

Can’t Plasma Mobile be drop-in installable on KDE? Why have an entire desktop distro for a mobile interface?

1 Like
5

I appreciate your concern.
This is being done by the KDE SIG, not as something separate. We already have many of the mobile packages being updated with all of the other KDE packages.
We will be trying our best not to let this Spin become dormant.

1 Like
6

Thanks for the quick response :wink: Looking forward to it!

( → vote adjusted :+1: )

7

What devices/phones will this work with?

We are not really going after the phone market. Fedora itself cannot install, without modification, on any phone but the PinePhone. That is why we are targeting “all touchscreen devices”. That include tablets and 2-in-1 laptops.
If you want specific names, I’m hoping to have it work well on the PineTab2 and Lenovo Yoga. But there are many other 2-in-1 laptops that work with Fedora.

Right now, there isn’t a good linux keyboardless experience on those machines.

postmartketOS has Plasma Mobile images

We do not believe we will be fragmenting development, quite the opposite. We believe that we will be able to get more developers working on Plamsa Mobile. The Fedora KDE SIG has a reputation of working and helping upstream. We want to continue that tradition with helping Plasma Mobile upstream.

As I said above, we are not targeting the phones that postmarketOS is. And they are doing a great job. That is how I installed Plasma Mobile on my Pixel 3a. But I find that I cannot contribute, because I spend all my time figuring out the development system, and no time in the actual Plasma Mobile code.

I could barely log into GNOME, does the man-power exist for more spins?

Fedora is a volunteer community. There isn’t a finite set of man-power to split between projects.
There are some projects that a company might sponsor some developers to work on, and some projects that are comprised completely of volunteers. There are projects that are a combination of the two.
So, having the KDE SIG work on a Plasma Mobile Spin, takes nothing away from GNOME, or any other Fedora desktop.

Can’t Plasma Mobile be drop-in installable on KDE? Why have an entire desktop distro for a mobile interface?

You can do that, and we have instructions on how to put Plasma Mobile on any Fedora machine.
https://fedoraproject.org/wiki/SIGs/KDE/Mobile
But our Plasma Mobile users are getting tired of having to re-customize their machines each time they install them.

This also isn’t a new “desktop distro”, it is a new spin. That means we are presenting what is already in Fedora, but with a new way to install it.

2 Likes
8

This is the plan. The KDE SIG will maintain the KDE Mobile variant similarly to how we maintain the current KDE & Kinoite ones.

2 Likes
9

Happy to hear that :slight_smile: I just adjusted my vote a minute ago to strongly in favor :+1: :smiley: Thanks for this contribution & efforts!

1 Like
10

This is my main concern as well.

We ran into this with the Phosh spin. Without setting expectations,
users expect that this is a moble spin, so it works on lots of mobile
devices, only to be disappointed when it does not.

Also, without clear enumeration of what hardware is targeted, it makes
it really hard to test or see when it is / is not ready.

I see downthread it’s noted that pinetab2 and x86 2-in-1 devices would
be supported, but
 is it really worth making a full fedora spin for
pinetab2 users and a few 2 in 1 users who aren’t just using a normal
desktop? Perhaps something produced on the side would be a better fit
for now for that?

To be clear I think it’s awesome to work on userspace and get packages
into fedora and enable remixes and someday when more things have
upstream kernel support, then do a spin, but I don’t think it’s worth
the trouble right now.

1 Like
11

We ran into this with the Phosh spin. Without setting expectations,
users expect that this is a moble spin, so it works on lots of mobile
devices, only to be disappointed when it does not.

Also, without clear enumeration of what hardware is targeted, it makes
it really hard to test or see when it is / is not ready.

You bring up a very good point. Users expectation. It would be a very good idea to do one of those grids of “This is the hardware that has been tested” x “These are the functions that work” And I believe this is what we are going to have to do.

But that is exactly why I want to make a spin. So that users can take the live CD and we can have a little test-suite or something. Plug it into the device they want to test, and it let’s them know what functions and what doesn’t. Then if they want to install, push the button and off they go.

Right now, we have a very limited amount of machines we can test on, because there is a limited amount of people willing to do what it takes to set it up. With a spin setup, we can broaden that list. Even if people don’t want to install it, I can boot up their machine, test it, and put it on the tested grid.

2 Likes
12

interesting points.

Hardware support will likely be a problem. I was also thinking about the difficulty of being legally restricted. Android is notorious for using Linux and bundling in proprietary vendor drivers.

So I expect the hardware support of Fedora to be more limited than that of an unrestricted distro.

Then about the performance, Fedora is not the lightest. PostmarketOS uses Alpine with musl and busybox instead of glibc and gnu coreutils, which supposedly saves memory etc.

I would love to see more tailored kernel variants though, ripping out all those strange old drivers.

To the security point, I think phones are a good learning field too.

Using a Google Pixel with GrapheneOS, all apps sandboxed, atomic OS updates, verified boot, hardware attestation using the secure element, filesystem encryption using the secure element


this will not be comparable at all, but lets improve!

Support spans are limited, many devices “supported” by postmarketOS and others dont get firmware updates anymore, as these need to be signed by the vendors.

All in all, good luck! I have a suitable OnePlus 6 (found it, lol) and am happy to test.

Having a community OS, rather than “whatever Google decides to change today in AOSP” is very very nice.

13

We ran into this with the Phosh spin. Without setting expectations,
users expect that this is a moble spin, so it works on lots of mobile
devices, only to be disappointed when it does not.

Also, without clear enumeration of what hardware is targeted, it makes
it really hard to test or see when it is / is not ready.

You bring up a very good point. Users expectation. It would be a very good idea to do one of those grids of “This is the hardware that has been tested” x “These are the functions that work” And I believe this is what we are going to have to do.

Yeah, but such a matrix is really hard. :frowning:

But that is exactly why I want to make a spin. So that users can take the live CD and we can have a little test-suite or something. Plug it into the device they want to test, and it let’s them know what functions and what doesn’t. Then if they want to install, push the button and off they go.

Sure, thats a great goal, but
 what hardware would they be able to
actually boot on? How many would look into it for a while before finally
figuring out that it wouldn’t work on their device.

Right now, we have a very limited amount of machines we can test on, because there is a limited amount of people willing to do what it takes to set it up. With a spin setup, we can broaden that list. Even if people don’t want to install it, I can boot up their machine, test it, and put it on the tested grid.

I don’t think it’s just a matter of more people.

The problem in the mobile space is that there’s very limited upstream
support for any mobile devices. Mobile device makers just slap a bunch
of local patches on a custom kernel for their needs and nothing gets
upstreamed. :frowning:

In those cases where it does (The pinephone pro probibly is close to
somewhat working as is the pinetab 2), they are really old devices now
and slow and not ones end users are very excited by.

Anyhow, I’ll stop here, but I think a remix until we have some
desireable/obtainable hardware with upstream support would be a better
move than another official spin.

1 Like
14

This change proposal has now been submitted to FESCo with ticket #3235 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like
15

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

2 Likes
16

@boredsquirrel and @Espionage724, the fact that you’re asking whether this shall support mobile devices appears to demonstrate a severe miscommunication (lack of specificity, mostly) on Fedora’s part, and a lack of knowledge about this subject on yours. I’ll attempt to assist:

Because development for (mobile, usually ARM-CPU) devices with unstandardised firmware (non-UEFI) is a monumental undertaking that cannot be feasibly duplicated. postmarketOS manages to provide support for these devices by using non-upstream (especially, for the kernels, out-of-tree) modifications. These include patches, shims, and entirely custom and proprietary kernels, from OEMs.

This is because devices that come preloaded with AOSP adhere to its boot chain, which, to my knowledge, cannot be EFI-compliant in the form that its specification describes. At the least, it is complex (akin to XBOX’s) so no manufacturer wants to implement EFI support on a device whose hardware is not designed to be user-modified.

They would still have to implement that that boot sequence atop, activateable solely when running AOSP. That would be a lot of work, for no reward, because it’s not as simple as creating an EFI and installing BlissOS atop it, because that shan’t pass SafetyNet or Google’s evaluation suite (of 300 000 tests).

Consequently, PMOS has to reverse-engineer the entire hardware and boot stack each time they intend to support a device. Luckily, significant commonalities exist between most devices, so effort can be reused. However, differences always exist too, in hardware and boot firmware implementation. This means that Fedora would need to:

  1. Acquire (from the OEM? fat chance) and/or reverse-engineer (without electrically damaging the device) a list of device trees, because the firmware shall not discover them and provide them to the OS like EFI does.

  2. Acquire proprietary driver blobs, and use them (I don’t believe Fedora uses proprietary software, even for drivers) or reverse-engineer them like Nouveau does. Unless the quality of these drivers are excellent, they can’t be upstreamed, so merely getting them to work isn’t adequate, unless you want to literally duplicate PMOS.

  3. Create a new installer that doesn’t merely write an .ISO’s content to a USB stick, but adds the aforementioned device-specific modifications in the AOSP recovery format, and write that.

Having Fedora assist in this endeavour would be incredible. I’d support it. But it’s definitely not something they intend to do, and I wholeheartedly understand why.

1 Like
17

I dont understand where you are going with that comment.

Thanks for the technical input, do you know if ARM Chromebooks (with u-boot) have a similar method?

Android uses UKI and system partitions, a recovery system, verified and measured boot, a lockable bootloader etc.

Having support for Plasma Mobile packages sounds nice, but I wonder how the end result would look like. Will Fedora grab PostMarketOS build scripts, convert complex nonstandard things (like the kernel) to RPMs and replace the packages with RPMs?

18

It depends on the Chromebook. Some have used a ‘standard’ methodology but a lot are built by similar teams as phone teams. The main issue is that most of these books were built with an expected lifetime of 1-2 years. [Which is longer than the expected lifetime of a phone which was 6 months to 12 months.] That meant there was little urge to spend time getting the board into the mainstream kernel (it can take a year and then expected maintenance for years) when the entire SoC and associated board will be end of production before that occurs.

There have been rules in various countries to change this, but it is not clear how much they are being followed or how much various firms are just going to pay the fines for cost of doing business.

1 Like
19

@boredsquirrel, summarily, that it is incredibly hopeful thinking to expect that Fedora shall ever support devices designed for OSes that aren’t meant to be replaced. These include devices preloaded with i(Pad)OS, macOS, AOSP, and ChromiumOS (and their derivatives).

No. Apologies. That comment basically contains the limits of my knowledge, for my specialties are NT and desktop Linux-based OSes. AOSP has a complex architecture.

As aforestated, this very probably shan’t occur. Are you asking what the CI configuration would be if they did try, theoretically?

20

Are you working on this proposal?