F40 Change Proposal: KDE Plasma 6 (System Wide)

Project Discussion Change Proposals
,
1

Wiki Link

Announce Link

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.

:link: Summary

KDE Plasma 6 is successor to KDE Plasma 5 created by the KDE Community. It is based on Qt 6 and KDE Frameworks 6 and brings many changes and improvements over previous versions. For Fedora Linux, the transition to KDE Plasma 6 will also include dropping support for the X11 session entirely, leaving only Plasma Wayland as the sole offered desktop mode.

:link: Owner

:link: Detailed Description

KDE Plasma 6 is a new major version of the user experience environment from the KDE community. It includes both desktop and mobile environments. While there are some user experience improvements over KDE Plasma 5, the majority of the work is under the hood. Notably, the whole stack is now built on Qt 6. Qt 6 brings significant upgrades to QML and Qt Quick as well as support for Vulkan (in addition to OpenGL and OpenGL ES support introduced in Qt 5).

KDE Plasma 6.0 is expected to release in early February 2024. The frameworks (KDE Frameworks), shells (Plasma Desktop and Plasma Mobile), and applications (KDE Gear) are all expected to be ported to Qt 6 as part of the KDE Plasma 6 release. However, some applications may not make it in time and will be updated later.

This upgrade is also notable that for Fedora Linux (and Fedora Extra Packages for Enterprise Linux 10, once that materializes), KDE Plasma will not offer an X11 session. Fedora KDE has been fully Wayland by default from login (since Fedora Linux 38) to desktop (since Fedora Linux 34), and the SIG is confident in the quality and development around the Plasma Wayland experience to stand fully behind it.

:link: Feedback

:link: Why drop the X11 session?

Three reasons for this removal:

This will drastically reduce our support burden and give us the ability to focus on quality for the KDE Plasma stack and continue our feature-forward nature. The Fedora KDE SIG will maintain a single code stream for all supported distribution targets (Fedora Linux 40+, Fedora Extra Packages for Enterprise Linux 10+).

This also does not mean that X11 applications will not work in Plasma 6, as we will still support Xwayland for running X11 applications on Plasma Wayland.

:link: Could we keep Plasma 5 for X11?

No. The KDE Plasma stack is fairly large and comprehensive. The SIG does not have the resources to maintain the KDE Plasma 5 stack beyond the lifetime of upstream’s focus. It would also be fairly complex to do so, requiring a lot of downstream patching to resolve the conflicts between Plasma 5 and Plasma 6. The intent upstream is that KDE Plasma 5 will be EOL shortly after the release of KDE Plasma 6, so it would be very difficult to support ourselves.

:link: Will Plasma 6 be available for older Fedora and EPEL releases?

No. This major version upgrade is not getting backported. Some portions (KDE Frameworks and KDE Gear) may get backported as part of regular upgrades if Qt 5-based versions are not maintained upstream, but the Plasma Desktop and Plasma Mobile software will not. Notably, KDE Plasma 5 for older Fedora Linux releases (and Fedora Extra Packages for Enterprise Linux 9) are on Plasma 5.27 and will stay there.

:link: Benefit to Fedora

KDE Plasma is a very popular platform used as the basis for the Fedora KDE Spin, Fedora Kinoite, and the flagship Fedora Asahi Remix experiences. By bringing KDE Plasma 6 into Fedora, we demonstrate our leadership and commitment to bring the latest and greatest technologies from the KDE community to the world.

:link: Scope

  • Proposal owners:

    • Import Plasma 6 stack into F40/Rawhide (tracked as pagureio#fedora-kde/SIG#383)
      • Ensure kwin-x11 is obsoleted by kwin-wayland
      • Ensure plasma-workspace-x11 is obsoleted by plasma-workspace-wayland
    • Modify select KDE Frameworks 5 packages to be co-installable with KDE Frameworks 6 per upstream guidance.
    • Enable tracking the Plasma 6 stack in ELN for branching to EPEL 10 once CentOS Stream 10 is available.

  • Other developers:

    • Optional: Packagers with software that can choose to build against either Qt 5 or Qt 6 should make the switch to Qt 6. Community maintenance of Qt 5 will be drastically reduced once KDE Plasma 6 is released.

  • Release engineering: #11669

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

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives: N/A

:link: Upgrade/compatibility impact

Fedora Linux users using Plasma X11 upgrading to Plasma 6 will find themselves switched to Plasma Wayland automatically as the X11 session will no longer be available. The KDE SIG strives to ensure the upgrade path is smooth for all users. Configuration files will be migrated automatically after first login to Plasma 6.

:link: How To Test

A COPR with pre-release versions of Plasma 6 will be available from the KDE SIG in the near future. At the moment, we have a KDE Plasma 6 nightly COPR containing snapshot builds in various states. It is strongly advised that testing is done in a non-production environment using a Fedora spin that doesn’t include and use KDE Frameworks at all (such as the Fedora Budgie Spin) as the packages are unstable and are not co-installable with any Qt5+KF5 based environment at all.

Once packages are integrated into Rawhide, users should grab nightly composes of the Fedora KDE Spin and Fedora Kinoite to try it out.

:link: User Experience

The user experience provided by KDE Plasma 6 will not be significantly different from what users expect from KDE Plasma 5. The main change will be the removal of the X11 session, as everyone will be transitioned to the Wayland experience.

:link: Dependencies

Plasma 6 depends most notably on Qt 6 and KDE Frameworks 6 packages. Qt 6 is already available in Fedora Linux, and KDE Frameworks 6 is in the process of being imported.

:link: Contingency Plan

  • Contingency mechanism: KDE SIG will roll back the Plasma Desktop and Plasma Mobile packages to KDE Plasma 5. Doing so will require epoch bumps across the stack.
  • Contingency deadline: Beta freeze
  • Blocks release? Yes

:link: Documentation

There is not yet upstream release notes for Plasma 6.0, as it is not released yet.

:link: Release Notes

Fedora Linux now ships KDE Plasma 6.0, a new major version of the KDE user experience from the KDE community. As part of this change, KDE Plasma on Fedora Linux runs on the Wayland display technology. X11 applications are still supported on KDE Plasma.

3 Likes
2

The packager of KiCad packages have raise a concern in the devel list

1 Like
3

Maybe it’s just me but I still use way too many features that Wayland breaks for me to go all-in on this. Any chance of a MATE-style legacy KDE spin variant? At least for a while?

Still can’t screen record, still can’t X forward, some apps still can’t screen share, no support for NX/X2go, no support for Barrier keyboard sharing, etc. Every time I give Wayland another try I fall on my face at some daily tool I use that won’t work. Devs blame the apps instead of blaming Wayland. Frustrating.

1 Like
4

I share the preoccupations regarding Wayland, I’ve tried various times but I’ve always had problems with common screen-sharing / videoconferencing applications which made it impossible to use for my daily work.

5

To sum up my mailing list posts:

KDE upstream is still supporting X11 in Plasma 6. I see no reason to force Wayland upon all users. I am also going to submit separate plasma-x11 (kwin-x11, plasma-workspace-x11, etc.) packages if the KDE SIG refuses to ship the subpackages, and I do not see how the KDE SIG wants to stop me from doing that, nor how such a dictate would be compatible with the Fedora “Features” and “Friends” goals. And if they really manage to prevent that through some authoritarian mechanism, I will definitely be off for another distribution that does not force me to use something I do not want (which also means that all my packages will end up orphaned).

3 Likes
6

Let me try to address your points:

  • X11 forwarding is unaffected by this change. If your application launches as an X11 app, it would still forward as before. If you want to forward Wayland applications, the waypipe program works well for doing this. The way I use it with SSH is like so: waypipe ssh -X <user>@<host>. You want to use -X because it makes the SSH tunnel better for forwarding for waypipe too.
  • Barrier has been forked into Input-Leap, and the latter has Wayland support implemented. However, no initial release has been made, and the snapshot that @aekoroglu packaged doesn’t include that code. I’ll ask him to update it to the latest code so we can have that available.
  • While X2Go does not support Wayland, NoMachine does support it as of version 6.1. For completeness, TeamViewer also has support for Wayland environments.

EDIT: Also, I just remembered, RustDesk also now somewhat supports Wayland.

On my Plasma Wayland environment using Firefox (v117 from Fedora), I was able to successfully use the following conferencing platforms with screen sharing:

  • Google Meet
  • Jitsi Meet
  • Big Blue Button

I have additionally verified using Google Chrome (v116 from Google), that I was able to successfully use the following platforms with screen sharing:

  • Google Meet
  • Jitsi Meet
  • Big Blue Button
  • Microsoft Teams
  • Amazon Chime
  • Cisco WebEx
  • Zoom

With Zoom if you’re using the desktop application, there is a small workaround required: it needs to currently be tricked into thinking it’s running on GNOME to run the Wayland support code. This was not needed for a short time, but for some reason, they put it back.

To fix this, make a copy of the Zoom desktop file in /usr/share/applications and put it in ~/.local/share/applications, then edit the Exec= line in the new file to prepend XDG_CURRENT_DESKTOP=GNOME to the Zoom binary call. That will allow the Wayland code to work. The code works fine on KDE Plasma, since it uses the xdg-desktop-portal system. If you’re a customer of Zoom, please complain to them. Alas, I no longer am, so I have no stick I can wave to get them to fix things anymore.

If you are still having issues, please file bug reports about it to KDE so we can figure out what’s going on.

8 Likes
7

Interesting. I was not aware of that being a thing. (Though I still find it sad that this functionality, which X11 was built upon from grounds up, had to be bolted onto Wayland as an afterthought.)

Note that one can also force at least Qt applications to use the xcb backend and hence work with X11 forwarding by exporting QT_QPA_PLATFORM=xcb (unless you folks want to desupport that, too).

Unfortunately, that relies on libei, which is not yet supported by KDE Plasma.

But these are both proprietary software. Also, TeamViewer still considers Wayland experimental, as evidenced by the screenshot with the warning in the documentation page you linked to.

As for screensharing on Wayland, that does not work with Falkon due to the Qt5 QtWebEngine not supporting the system version of Pipewire (which is too new for it) and hence being built without Pipewire support. So this cannot be tested until we have Qt 6 Falkon (which exists in an unmerged upstream branch right now).

1 Like
8

Ah, I’m going to complain about dropping X11/Xorg support too.

I already expressed my reservations elsewhere, and I’m happy that people think it is going to work, but I use fedora kde as my daily driver and i’m here to say that as of a month or two ago, Wayland wasn’t working correctly with nvidia drivers in F38 and KDE on my Lenovo P1 optimus setup, which doesn’t have an option for disabling the nvidia.

Sure, it works fine with the integrated LCD, but I also have two different dock/monitor configurations and that barely works. For example, I expect it to automatically expand my desktop to the previous monitor configuration (multiple mixed portrait/landscape monitors) when it is attached to a given dock, as well as adjust the scaling properly. It’s not been able to accomplish that with wayland, without manually fittling with it when I switch screen configurations. Which happens multiple times a day as I dock/undock it. Using X11 it tends to work the majority of the time, but even then, it’s not reliable. Heck, that machine can’t even boot graphical.target 100% of the time, and I’ve not bothered to debug it because I have other things that can be debugged. And i’m running the zoom flatpak, and a bunch of other things that have also been problematic in F38 with wayland.

And this is not new, it will work for a kernel revision or two, then break for a revision or two. The whole graphics stack, like it or not, isn’t stable. My L14/amdgpu machine stopped being able to drive USB-C attached 4k monitors for about 6 months due to a kernel regression, which I did bisect (2158902 – 6.1+ kernels fail to bring MST attached graphics heads online with amdgpu). That is my personal machine with steam, and that wasn’t working under wayland last time I tried it either, but then again proton + random games are sorta hit/miss too.

So, fine, drop it from RHEL, just about no one uses RHEL as a workstation anyway. Is KDE even supported on RHEL?

But, I just don’t see how simply making wayland the default and leaving the X11 code in place as a fallback can cause more problems than it potentially solves by leaving it as a backup for those of us having wayland issues. To me this sounds like a case of leave it in place and revisit it in a year, if people don’t complain about it, then great do it, otherwise listen to the people still having issues, or add some ugh telemetry and wait for the number of X11 users to fall.

3 Likes
9

IMHO, Fedora should just ship X11 support (at least in subpackages in the repository, if they absolutely want to drop it from the live image) as long as upstream allows building it.

2 Likes
10

Thanks that tracking information is actually really helpful. I will hold out as long as I need to but it’s encouraging to see their party apps on track.

11

We (the KDE SIG) certainly can’t stop you from doing that. The KDE SIG will simply not maintain those packages.

5 Likes
13

Thanks for all the feedback here, it’s invaluable. The side goal of this change is to surface those use cases that are missing in the KDE Wayland session right now and this is helpful as we can go back to upstream with concrete feedback.

Note that Fedora 39 will still ship Plasma 5.27 with the X11 session as an option and it will be supported until Fedora 41 comes out, which should be about a year after the Fedora 39 release. You will thus be able to stay on the Plasma X11 session until then. Hopefully we can figure out those issues between now and next year.

3 Likes
15

Sorry but this is not how things work in open source in general. Independent contributors work on what they want, paid developers work on what their company pays them to work on.

Maybe creating a group, gathering funding and reaching out to a company doing open source contractual work would help move this forward.

See Where bugfixes and new features come from – Adventures in Linux and KDE.

1 Like
17

I think there is a misunderstanding here. Most of KDE SIG members are not paid to work on KDE maintenance in Fedora. I, for example, I’m not paid to do any KDE or Fedora Kinoite related work.

This proposal does not come from a company, it comes from us not having the free time to maintain X11 support and wanting to focus on fixing things in Wayland.

I’m not dismissing your feedback when I suggest you form a group to push and fund better color management in Wayland. I’m suggesting a path to get this work sufficient traction that someone would be able to tackle it.

18

(post deleted by author)

1 Like
19

“Just stick to F39” is not a long-term solution because it only buys us 7 months until EOL is reached. If anything, it will lead to a lot of users running an EOL Fedora for years. Or they will move to another distribution.

Is it really such a burden to keep building the X11 versions of Plasma and KWin? They are built from the same SRPMs as the Wayland ones, so it does not even require maintaining additional specfiles, unless you deliberately force them to be packaged separately by dropping support from the main SRPMs as planned in this Change.

In the end, I think the proposed Change will actually increase the overall maintenance burden in Fedora significantly: you get to drop a few lines of specfile, but someone else gets to maintain a specfile that is mostly a copy&paste of yours, just built with different CMake options, and needs to be kept in sync with your frequent Plasma updates (which you will even push to stable without waiting for the packages you do not support anymore to be updated, as recent kdepim and kf5-solid updates breaking blogilo, trojita and plasma-pk-updates until I fixed them have shown).

1 Like
20

I’m ok with these changes, but I don’t agree with dropping X11. Plasma Wayland has still significant annoyances and probably a lot of people still rely on X11 (including me).

21

Except that OpenGL ES support is not enabled in Fedora builds?
https://bugzilla.redhat.com/show_bug.cgi?id=2219445

1 Like
22

I want you to understand something: I care about your needs. For the past several years, I have been primarily focusing on creative professional work in Fedora KDE. This has been primarily oriented around game development and A/V production, but I also care about regular digital artists too.

I want to address your concerns head-on, so here we go…

  • On color management: KDE Plasma Wayland contains basic color profile and color calibration support, based on the stuff that was available in X11. We have colord integration and some things work now. Much more advanced color management is coming once the new Wayland protocol is finalized and kwin has an implementation. If you want to know more about what’s going on here, there’s much more detail about it.
  • On configuring graphics tablets, I’m not sure what you mean. I own a Wacom Intuos M and it “just works” out of the box in Plasma Wayland. If there’s something you’re missing with the newer tablet configuration KCM, please file bugs about it. Nobody can do anything about it without more information.
  • On Krita, my admittedly very basic use as someone who dabbles in digital art seems work fine in Plasma Wayland using the version of Krita packaged in the Fedora repositories (5.1.5 on Fedora 39). My tablet works, including all the pressure levels and such. I didn’t even get any warning about running in Wayland like I’ve heard other people talk about. If there are in fact issues, please file bugs about it.

Please understand that none of us in the Fedora KDE SIG are trying to ignore artists. We, in fact, want artists to leverage the awesomeness of the Plasma Wayland experience to create even better artwork beyond the limits of what X11 allowed. We’re not fully there yet, but from what I have been able to tell, we’re mostly at parity with where things are with X11.

A big part of this Change discussion is shaking out the remaining issues to prioritize with the upstream KDE community. This has been a difficult discussion to have when people say “just switch back to X11”, and we need to be able to have a conversation about what we need to do to make that excuse go away.

I want to thank you for participating in this discussion and highlighting your concerns, and I hope I’m able to demonstrate that I’m not brushing them away and that I do want your needs to be addressed in the Plasma Wayland world.

8 Likes
24

As stated in the bug report, that is because Qt makes it a mutually exclusive compile-time choice whether to use OpenGL or OpenGL ES, so it cannot be built with support for both.