Does Wayland really break everything?
Does Wayland really break everything?
I’ve written some other posts on Wayland recently, and it’s time for another one! Feel free to skip it it you aren’t interested in a discussion of Wayland and platforms. Many may …
X11 was dead walking a long time ago. Not enough people put in the effort for Wayland earlier an now they are shocked there are bits missing.
Permanently Deleted
Wayland didn't break everything, but Nvidia 545 certainly did
Holy smokes, it was so bad for me I switched to AMD a week later
Haha actually same! I went out to a pawn shop and found an Rx 5500 for $75
Holy fuck facts. I'm pretty sure Nvidia never said it was stable tho but a lot of distros updated to it.
I will preface that Xorg is obviously an unmaintainable mess of legacy decisions and legacy code, and I have both a machine that runs Hyprland and a machine that usually starts Plasma in Wayland mode so the Wayland situation getting to be more-or-less adequate with persistent irritations here and there... but Wayland is trauma-driven-development. It's former xorg developers minimizing their level of responsibility for actual platform code, but controlling the protocol spec, and in the position to give up on X in time with their preferred successor.
Essentially all of the platform is being outsourced to other libraries and toolkits, who are all doing their own incompatible things (Which is why we have like 8 xdg-desktop-portal back-ends with different sets of deficiencies, because portals were probably designed at the wrong level of abstraction), and all have to figure out how to work around the limitations in the protocols. Or they can spend years bikeshedding about extensions over theoretical security concerns in features that every other remotely modern platform supports.
Some of that outsourcing has been extremely successful, like Pipewire.
Some attempts have been less successful, like the ongoing lack of a reasonable way to handle input plumbing in a Wayland environment (think auto-type and network kvm functionality) because they seem to have imagined their libinput prototype spun out of Weston would serve as complete generic input plumbing, and it's barely adequate for common hardware devices - hopefully it's not too late to get something adequate widely standardized upon, but I'm increasingly afraid we missed the window of opportunity.
Some things that had to be standardized to actually work - like session management - have been intentionally abdicated, and now KDE and Gnome have each become married to their own mutually-incompatible half solution, so we're probably boned on that ever working properly until the next "start over to escape our old bad decisions" cycle.... which, if history holds, isn't that far away.
We're 15 years in to Wayland, and only in the last few years has it made it from "barely a tech demo" through "Linux in the early 2000s" broken, and in the last year to "problems with specific features" broken ... and it is only 4 years younger than the xf86->xorg fork.
I don't know why but most of this comment made me chuckle and the final paragraph had me laughing like crazy. I agree with almost everything you've said but the tone is so humorously black. I love it. Thanks.
I'll be using your trauma-driven-development concept from now on
Your issue is you're assuming all things must be standardized in a monolithic fashion.
The whole point of Wayland is that monoliths are bad in an environment as diverse as the Linux desktop.
Either libinput will be improved or it will be replaced as needed.
I'd argue portals are deficient because Wayland implementations in general are not complete. An org like KDE or GNOME has a fair bit of man power but they're still in a position where they need to keep X11 functional and they need to carry forward decades of features. Even if Wayland was flawless from the onset that's a huge undertaking.
Wayland is one part of what needs to be a collection of specifications, but the point is to have a specification instead of an implementation. You can actually have implementations that make different trade-offs and optimize different use cases that way.
That doesn't prelude something like mir or wlroots acting as a base layer for desktops that don't want to build up from the specification ... but it does allow KDE to write a compositor that does exactly what KDE needs/wants ... instead of the X11 mess where you can "turn the compositor off" which results in effectively two classes of desktop, one of which is used for gaming, the other for general desktop use ... or any of its various other issues.
They don't have to be specified in a monolithic fashion, but some things - like the input plumbing and session management examples I made - do have to be specified for for software to work when running under different compositors. FD.o basically exists because we already learned this lesson with other compat problems, and solved it without putting it in the X monolith - it's why things like ICCM and EWMH happened; there were more details than were in the existing APIs that everyone needed to agree on to make software interoperate.
Competing implementations are great, but once you have significant inertia behind competing implementations which are not compatible or at least interoperable, you've fragmented the already-small Linux market share into a maze of partially-incompatible micro-platforms. We're not going to have compositing and non-compositing, we're going to have 3ish (KDE/Qt [kde], Gnome/Gtk who aren't even doing documented protocols, and Everyone else - mostly [wlr] extensions) incompatible sets of protocols for basic functionality.
Looking at the slow bitter process to extend or replace components once implementations that rely on them exist, that's not something to count on. Remember how it took 15 years of contention to eventually transition to D-Bus after CORBA/Bonobo and DCOP? That's whats about to happen with things like the incompatible gtk and qt session management schemes. And that resolution was forced by the old HAL system using it, not the other parties involved getting their shit together of their own accord.
One place we're about to see innovation is wayland-stack-bypassing workarounds. Key remapping is currently in that category, the wayland protocols suite punted.... so instead, keyd sniffing all the HID traffic at the evdev and/or uinput layer and outputting the rule-edited streams to virtual HID devices. That one does have a certain global elegance (works on ttys!), but it's also layering violations with privileged processes.
So we're calling just doing one thing "trauma-driven-development" now? Yeah, Wayland doesn't do everything Xorg does. That's a good thing. Xorg is a dying, dysfunctional mess because it does a thousand different totally unrelated things and nobody understands all of them and how they're all tied together. We're probably going to run into the same problem again eventually with systemd. Feature creep is toxic for open source software.
Wayland has problems, but not being X12 isn't one of them.
Wayland isn't perfect, but it's definitely getting there.
I think one of the biggest migration problems is that things have to move from the windowing system to the desktop environments, and they're slowly adapting to it.
I switched a few months ago to see how bad it is. Never found anything not work so I'm still using it.
For me, yes: Wayland doesn't work at all and the only answer I can get is that it's because of Nvidia. That's stupid because until some update broke it, it worked. Most apps were just very buggy.
@Fleppensteijn @leopold its a Nvidia issue.
For years Nvidia tried pushing an alternative Linux driver called EGL, everyone told them it couldn't support Wayland
Eventually Nvidia tried to implement EGL backends to Gnome and KDE (this resulted in the buggy apps). Nvidia then declared their new cards would support GBM.
This leaves the 10xx-30xx cards stuck on EGL with no one supporting the EGL backends. Nvidia have made it so GBM support can't be added by outsiders to those cards either.
@Fleppensteijn @leopold @stevecrox
For troubleshooting, I recommend
For trouble shooting recommend https://community.kde.org/Plasma/Wayland/Nvidia, checking whether all kwin backends are installed (kwin-wayland-backend-* on Ubuntu). Sometimes there's also a problem with the missing OpenGL backends of Qt. An easy check to see whether there is a problem with the proprietary driver is to try out whether the problem also exists using nouveau.@Fleppensteijn @leopold @stevecrox
All of Wayland is based on EGL. What you are referring to are EGLStreams vs GBM which are both libraries using EGL. Nvidia drivers now support GBM for all supported GPUs via a support library that comes with the driver (libnvidia-egl-gbm https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gbm.html). There should be no difference in the GPU generation used.
as long as software I use daily doesn't work on it as transparently as it did to me as an end user on xorg then yes, to me as the enduser, Wayland does break things and no, Wayland is not ready
I am an enduser. I don't care about the specifics, I expect things to work and not suddenly break.
For all the "year of the linux desktop" shouting, nobody wants to truly really think about or consider non-dev daily driver endusers who just want things to continue to work like they always have
I've been wondering for a while if Wayland supports remote display like X11/Xorg did
Waypipe
Fantastic read
lokalize (Translation tool) is, only application for me, not working with Wayland at all (There is bug reported about it). I am using KDE with Wayland on my daily laptop.