I’m not super familiar with the Fedora procedures, so I have a question:
If you provide those X11 packages in the official Fedora KDE repos, does the fact these packages were provided necessarily mean that they are officially supported or can you still say they are not officially supported?
Red Hat for example completely removed all Plasma packages from their repositories after they announced they wouldn’t support the Plasma session. I don’t know if this was immediately after or if it took a while.
Or do you plan to provide these packages in a third party repo?
From what I gather from all of this discussion, the biggest burden on the SIG isn’t the making of packages, but rather their support.
there really is no legitimate reason to have both Activities and Virtual Desktops.
I disagree, I use both of them. I have seperate “activies” for
seperate activities (like Studying, Programming, etc.). I use virtual
desktops too, in each activity I have a grid of 3x3 virtual destops so
that I can place windows at different places and move easily. I love
this workflow.
So yes, there are “legitimate reasons” to have both.
You are right, fortunately Linux is not only Fedora, there are many big distros in the wild based on Debian, Arch, openSUSE,*BSD… and for the moment none of them officially declared any attempt to drop/restrict X11 on KDE desktop.
Truthfully, the arguments they gave for dropping X11 are not convincing at all, because from what I know they are not directly responsible for fixing Plasma desktop’s bugs on X11 which we should be thankful for KDE Plasma team for doing it.
Plasma desktop is much bigger than a single distro, and what I wish for the team is not to rush to meet the needs of that specific distro, and takes their time to fix and migrate the platform to Qt6, because for now Plasma 5.27 is really stable and solid and can be supported as LTS for much longer, and we can wait for the team to perfectly finish the migrating even if the process takes more than the schedule.
Unfortunately these are the reasons why I, as 3d artist and graphic designer, had to leave Linux entirely after 10 years of exclusively using it.
Main issue for me is that many 3d app (propriety) I use, that support Linux, did not even start work to adapt their apps to work with Wayland. Right now, they just crash when I try to start them. Like Foundry apps and Houdini, 3DCoat. So far only app I see some work towards Wayland is Blender, but I am not using it that much anyway. Will Unreal work? Unity? Does Godot work, anyone tried? They will probably port at some point, some will just leave Linux world, but how many years I need to wait, gain?
Linux is good for office usage and for development, outside of it, it is nightmare, does not matter is it KDE or Gnome.
Almost no apps need to be ported to be Wayland native in order to work in a Wayland session, they work just fine through X11. Apps that do crash on startup are probably mixing toolkit and direct xcb usage (like Kdenlive did in the past) and can be fixed with simple things like setting QT_QPA_PLATFORM=xcb in their .desktop files until the developers fix those issues.
And yes, Unreal does work - better yet, the very first release of the Unreal Engine 5 editor launched with native Wayland support. Unity has experimental Wayland support as well, and Godot has a merge request for it too (and both work with Xwayland until their ports are complete).
Having only recently finally switched to Linux out of necessity, this talk about Wayland really stresses me out. It was very much faster for me than X11 (using MESA/open source GPU drivers since the official NVIDIA closed-source ones kept freezing my machine), and I really liked it, but sadly nothing works in it and both my browsers (Vivaldi and Firefox) froze completely in it. So I had to go back to the X11 edition of KDE Plasma. The thought of Wayland being not only the default but the only choice in this very unfinished state is absurd to me.
(Really also Windows 8 and 10, but especially Windows 11, is so far beyond the very outer limits of any sane person that it was seriously either Linux or not using a computer at all anymore. The total disrespect of the user in every way (not “just” in terms of privacy) made me physically ill, and I’m somebody who grew up with Windows 3.x and loved it until XP. I started trying to switch to Linux in early 2000 but it was only 23 years later that Windows had become literally unusable and it was no longer a matter of choice to keep using it.)
Using X-11 is not the end of the world. Right now, I am running X-11 on my desktop PC because of the nVidia card. Wayland will run it, but there are some issues. Will I be able to use Wayland in 6 months? Quite possibly, yes. The progress made in the past few months alone has been amazing. I don’t expect this progress to end.
So, don’t panic over this. It’s not happening tomorrow.
This is more an Nvidia issue than Wayland. The Nvidias Mesa driver has been in a rough place for a long time unless your GPU is very old or very new due to lack of cooperation from Nvidia and they’ve done amazing with what they have done but the experience for it isn’t great yet. Nvidia only very recently started playing even a little nice with Wayland on their proprietary driver and that’s not anyone’s fault but Nvidias. AMD, Intel, and pretty much any other GPU vendor are in a very good place with Wayland, Minus the issue at hand obviously. In some instances the Wayland session fixes a number of problems the X11 session has (multi monitor problems for instance) but specifics are DE/compositor specific and that is a bit beyond the discussion here.
There’s actually some good news on this front! As a consequence of NVIDIA opening up their driver code last year and reorganizing how their GPU firmware works for GTX 16/RTX 20 (Turing) and newer GPUs, nouveau has been revitalized as a project and this week patches for support for the new firmware have been posted. This will make the NVIDIA proprietary driver essentially superfluous for most people, since nouveau will have access to the full capabilities of the hardware just like the proprietary one through using the exact same firmware.
Its just unfortunate this leaves everything between kepler and turing high and dry with no real option but the proprietary driver as nouveau is mostly useless for them due to still lacking reclocking and there are many of those still in the wild as gtx900/1000 are fairly long lived GPUs. Those people still are at the mercy of if Nvidia decides to make Wayland not suck for them or they can use X11 and have a decent experience.
My understanding is that NVIDIA has queued significant improvements for Wayland support for their proprietary driver over the next couple of driver releases. But yes, the ultimate point is that we’re at the mercy of NVIDIA for the proprietary driver for those users.
But that was also the case when Linux users transitioned from fglrx to AMDGPU a decade ago. The gap was narrower and the OSS drivers did not suck as much, sure, but it was still a problem then too.
The fact that there’s improvements at all to the situation should be celebrated, though. Would I like it to be even more? Sure, but I’ll take what I can get.
Ive been trying to think if there is any way to make a workable solution for at least sRGB based workflows on Wayland till the full protocol is worked out. Admittedly my knowledge on implementing this is stuff is VERY limited as im more a user but would a shader based approach similar to Reshade or vkBasalts lut shader be possible?
Here is the basic idea
Assume sRGB in applications and on surfaces
maintain VCGT loading for applying gamma modifcations (or maybe bake VCGT into lut if performance is same?)
allow users to load 3D luts created with i.e displaycal (without the VCGT baked into it) and apply the lut to the user session through a shader.
This is likely rather ham fisted and my limited understanding of this may leave me talking out my rear here. This would apply to everything on screen but seeing as the applications themselves cant actually apply corrections anyway on wayland this shouldnt be an issue. Im not sure of the time this would take to implement/ or if its even a good idea.
Lucky there’s still a place to criticize Fedora’s decision to drop the Xorg Plasma session in Fedora 40, as it can’t be done in Fedora KDE Matrix channel.
backends/drm: support applying icc profiles with color management (!4471) · Merge requests · Plasma / KWin · GitLab implements pretty much that. Only caveat is that I made the assumption that the ICC profile isn’t complex enough to require a 3D LUT - I extract the primaries, whitepoint and VCGT tag and apply those.
It seems to work with example profiles that are preinstalled on my system, as in, it changes the colors to be more desaturated and blue-ish if I apply an Adobe RGB profile, but I don’t have a colorimeter so I can’t check if it’s actually accurate or bugfree.
Does this require Plasma 6? If its possible to use the current Plasma i can test if this actually works with my displays. I might also maybe just move to Plasma 6 and see what bugs i can run into if it needs P6
