- cross-posted to:
- news
- linux@lemmy.ml
- cross-posted to:
- news
- linux@lemmy.ml
Wayland. It comes up a lot: āBug X fixed in the Plasma Wayland session.ā āThe Plasma Wayland session has now gained support for feature Y.ā And itās in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. Iāve read a lot of nervousness and fear about it lately.
So today, letās talk about it! What is Wayland?
Wayland is a set of protocols that govern how a compositor draws stuff on the screen, and how apps interact with the compositorās drawing-stuff-on-the-screen infrastructure. Itās similar to the HTTP and SMTP protocols that govern how web browsers and email clients send and receive web pages and data.
Wayland also includes an implementation of those protocols in a set of extremely lightweight libraries called libwayland-client and libwayland-server that offer stable and versioned APIs. Apps and compositors such as KDEās KWin and GNOMEās Mutter use those APIs to do stuff. Why does Wayland exist?
In a nutshell, because X11āthe thing itās replacingāis dead.
X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world. Why did X die?
The fundamental X11 development model was to have a heavyweight window serverācalled Xorgāwhich would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isnāt a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.
But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.
In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. Itās stable today because itās been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that canāt adapt die. Projects that depend on them then die as well. How is Wayland any better?
Wayland was conceived of by X developers who wanted to avoid repeating their own mistakes. In addition to a lot of technical differences, by being a minimal set of protocols and two extremely thin client and server libraries, all the heavy lifting was delegated to individual compositors, which became the window servers of their environments. A new feature added to one would not destabilize any other compositors. Compositors were also free to implement new features via private protocols outside of the standard ones that apps only targeting that compositor could use. Wait, that sounds like it sucks
Wayland has not been without its problems, itās true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Waylandās minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to workāsuch as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on. Compositors all needed to come up with ways to do these things themselves. And that need for each compositor to implement everything itself fragments development efforts and disadvantages small teams without the expertise of heavy-hitting graphics developers. These are real problems and we shouldnāt sweep them under the rug. Yes, but there are solutions
Over time the minimal core protocols have been extended to cover whatās needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.
In addition, the problem of fragmentation of effort is being solved by wlroots, a library of Wayland implementations that you can use to build a Wayland compositor. We donāt use it in KDEās KWin compositor because we already did most of that work ourselves before wlroots existed, but itās a big benefit to anyone writing a new compositor from scratch today. And thereās a chance we might port KWin to use wlroots in the future. Why is the adoption taking so long?
The fact that Waylandās minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008. We didnāt see the same problem with other newer projects like Systemd and PipeWire which were adopted much faster.
And unfortunately, shepherding new protocols through the approval process to fix this problem is a grueling political exercise. It demands empathy and compromise with people from other projects who approach the problem youāre trying to solve from a fundamentally different perspective. Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. For a long time, the urgency of pushing through it was low because X wasnāt dead yet.
So it took over a 15 years and resulted in Waylandās dirty laundry being aired in public for that whole time. And that sucks. Butā¦ weāre there now. Standard protocols now exist for just about everything anyone needs. The few remaining obvious omissions (like screen color calibration) are being actively worked on as a matter of priority. āAre we there yet?ā
Plasma and KDE apps work great on Wayland, especially in the upcoming Plasma 6 release. Like I said, there are still a few omissions, but those holes are being plugged very quickly these days.
Most 3rd-party apps that arenāt Wayland-native also work fine via the XWayland compatibility layer. But there are some that donāt, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.
A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didnāt do the porting work. Well, itās not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland. Thatās understandable. But this time itās for real, and the time to port is now. For any protocols that still arenāt good enough and need revision, app developersā input is needed to revise them or even propose new ones. This process takes a long time, so better to start sooner rather than later. But itās not just gonna go away. Which brings us to Fedora KDE
Fedora has always been a āleading edgeā distro that pushes forward the technical state of the art on Linux by adopting new technology once itās mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.
It should be clear that Fedoraās target audience consists of people who are excited about change. If this is you, all of these projects should seem exciting and cool! If notā¦ then Fedora isnāt for you. And thatās fine. The Linux world has approximately five hundred bajillion distros. Whatās that you say? Only about 20 of them are any good? Well, fair enough, but even if that pulled-out-of-someoneās-butt number is accurate, there are still 19 distros that arenāt Fedora! Reinstalling your OS is unpleasant, but itās important to choose the right one that suits your needs and preferences. Choice comes with the responsibility of choosing wisely.
Maybe youāre afraid that Fedora is a ācanary in the coalmineā that shows the way everything is going to go. And you wouldnāt be wrong about that, but transitions still take time. Distros that intentionally ship old software like Ubuntu LTS or Debian Stable will let you keep using X11 for years and years. Arch will probably keep shipping X11 for a while too. You have options. By the time Ubuntu LTS removes X11 too, everything will be fully ready. Putting it all together
Wayland is a replacement for X11, which is dead. Despite a rocky development process, itās ready enough for Plasma and KDE apps that Fedora KDE is pushing it pretty hard. Many 3rd-party apps are already Wayland-native, but many are not, and they need to put in the work to port to Wayland. If anything they need is still missing, they need to step up to be part of the process of adding it. This process is happening, and isnāt going to stop happening. We need to work together to make it happen faster and more smoothly.
So what happens to āssh -Xā with wayland apps?
Can you put together a tldr? Iām glad your writing this but itās to much for me to take in all at once š
-
Fedora KDE plans to drop the Plasma X11 session, in favor of Wayland
-
Because X11 is bloated, insecure, and in a development freeze since many years.
-
Wayland is simple, secure, minimal; developed by former X11 devs.
-
Challenges:
-
Waylandās minimal core protocols lacked essential features.
-
Fragmentation in development efforts occurred.
-
Protocol approval was political and time-consuming.
-
Current State:
-
Standard protocols for most requirements are now available.
-
Plasma and KDE apps run well on Wayland with the upcoming Plasma 6 release.
-
Many 3rd-party apps work via the XWayland compatibility layer, but some need to be ported to Wayland.
-
Conclusion:
-
Fedora aims to drop the Plasma X11 session entirely, if you donāt like it then switch disros.
-
Many 3rd-party apps are already Wayland-ready, but many are not, and collaboration is needed to expedite this transition.
Because Wayland is bloated, insecure, and in a development freeze since many years.
Maybe you meant X11?
Corrected, thanks!
-
To be clear, Iām not the author. The summary below looks reasonable though.
āany feature added to support any use case could break everything else that everyone else usedā
So now we get tons of implementations of the same feature which are different and have their own issues separately instead of one central implementation and issues people can work on together.
Wayland is a mistake.
Written as if no other software has ever run into that problem beforeā¦ Isnāt that the point of writing good tests that cover the use cases?