FWIW, I have been test-driving KDE Plasma 6 beta 1 on Fedora Rawhide (40) for a few hours now, obviously on Wayland - because I really like KDE, and I really like Fedora.
I like KDE and Fedora so much, that I run them inside VMware Workstation on Windows 11, just so that I do not have to use Windows 11 too much, that I only get that VPN connection wired up that I totally depend on.
Alas.
KDE Plasma 6 beta 1 on Wayland, inside VMware Workstation 17.5, is very beta, and for me all it’s about integration with VMware Workstation:
guest resizing + full-screening does not work, can hang the desktop
upcoming kernels will make KDE disable workarounds and switch to atomic mode-setting - and that, today, causes Linux kernel oopses in atomic cursor support
the whole clipboard story of Wayland, XWayland, and VMware tools integration with the VM host’s clipboard is … full of major friction (of course VMware is one major contributor here with only supporting X11 integration)
With the above, I do not see any chance that KDE Plasma 6 final will be “ready” in strictly Wayland-only packaging, F40 or not. There are just not enough days (calendar time!) to fix and QA those deficiencies, leave alone availability of technical resources! I am even trying to poke at KDE git master, and while adding logging statements is easy enough, understanding and adjusting the complete DRM-based system integration is simply much too much to do in passing.
So, that leaves X11 as something that works quite well when run on VMware Workstation.
But, alas, there is nothing in rawhide that dnf provides kwin_x11. That really hurts. I could understand not installing this by default, packaging this as a “legacy” or “unsupported” package. But not making available such a package is too much … nudging … for me.
I’d really appreciate it if F40 could package kwin_x11 in some shape and enable users to activate X11 sessions for KDE (any version of KDE, to be honest, I’d be totally content with 5.27, too!).
Are there bug reports with the Linux kernel, KDE, and VMware about these that we can track? Detailed bug reports can result in fairly quick fixes around issues like this in the various relevant upstreams.
Keeping in mind that this is unsupported and the KDE SIG is not handling bug reports related to the X11 session, here’s a COPR that offers the X11 session packages. It tracks Dist-Git and builds automatically in line with them. This COPR may or may not stick around, but here you go.
VMware virtual machine integration is challenging in general - vmware/open-vm-tools: Official repository of VMware open-vm-tools project (github.com) is the source of truth for all of that, VMware at least shows some presence, but the overall topic of “what’s your Wayland story” is swept under the rug, in a way. In a way, this is understandable, given the way things are implemented right now, and the architectural challenges posed by Wayland + XWayland for the benefit / sake of security. Personally, I suspect that VMware will not invest anything into Wayland - but, luckily, the host backdoor is reasonably well-documented, so given time, capacity, and competence, this would be feasible to transport into a Wayland world. IIUC, all this applies to KDE and GNOME alike (and any other Wayland compositor), but I have to admit that I basically don’t have reasonable experience working with anything but KDE Plasma.
Much appreciated, thank you!
I’ll add the repo to my experimental Rawhide + Plasma 6 virtual machine; this will give me a consistent channel in addition to whatever my experiments with a self-built Plasma Desktop from git master deliver.
1 thing that is blocking me is legacy drivers for current hardware that is still produced : 2253865 – Removal of Xorg breaks the ability to use a desktop environment on Aspeed ast2500 display completely (black screen until hard reboot). Of course, userspace modesetting was made obsolete long ago, but it was still working. As a result no wayland compositiors works at all : you have to hard reboot to get working console again just as Xorg that use kernel modesetting generic drivers (by the way even in console mode the generic drivers are reducing blanking on Analog outputs which cause problems even on flat displays). (the official kernel ᴅʀᴍ driver is only for console mode and mark the screen/card as busy for all application which makes Wayland and not finding any displays)
And not even talking about bankrupted companies.
Looking into the issue, it seems there is a driver in the kernel, but if it’s not complete enough to run a Wayland compositor, that does need to be addressed. I’ve retargeted this bug to the kernel package. Hopefully the right folks can help you to resolve this issue.
You can add generic kernel drivers to the case of having Fedora working in console only mode. I’m rather appealing to support old userspace only drivers much like Xwayland and maintain Xorg meanwhile.
Althrough unrelated, please note Freebsd is dropped by the manufacturer (not even a console driver that time leaving only the Xorg 1).
I am a Fedora KDE user and basically like this idea. Several commenters have suggesting elevating the KDE spin to equal ‘workstation’ status with GNOME; something that could even be chosen at installation. That, IMHO, is the best option.
I agree with the original post that Plasma provides a more intuitive user experience out of the box for most people. GNOME looks great and definitely has more polish, but its default settings are puzzling and almost everyone I know who uses it adjusts it to match their workflow, rather than adjusting their workflow to match GNOME defaults. Most new users are not going to want to install Tweaks to add window titlebar buttons, or figure out how to install Dash to Dock, etc. Personally, I think Plasma is the future of the Linux desktop and it would be great for Fedora to make it a first-class offering.
One thing that is a bit concerning with Plasma is that I’ve noticed recent version upgrades seem to use MUCH more RAM than older versions. I used to have a Debian 11 KDE system which idled at less than 500MB after booting. Now Fedora KDE uses 4-6x that much RAM at idle. Lots of variables here, I realize, but…