I really don't like Wayland, I recently (last Friday) had to revert back to X because somehow they messed up enough that in Zoom screensharing during a meeting with XWayland can crash my audio drivers.
At this point I don't know who it is for, but it's not for users.
Yes, Zoom somehow turned into something like Skype, post acquisition.
But, at the same time. A design that requires everyone to implement their own protocols and everyone to refix the same bugs in their own compositor is inherintly bad.
I have been using Wayland as my daily driver. Some compositors lacked SHM support in their screen sharing, others have other issues. We only recently got proper text input support, and it took forever to fix in chrome and electron(it's been fixed for a few releases, but you'll still come across older electron software). How did they manage to make it so the cursor movement is dependent on the scaling mode in a way that client rendering library's need to be aware of it otherwise the cursor ends up in the wrong location by the way?.
In X, if the WM crashes, X is still running, and you can just restart the WM. In Wayland, if you hit a bug it takes everything down with it.
The first release was 14 years ago, we're still fixing screen sharing.
I just learned that despite all the boasting of fractional scaling support in Wayland, one of the base protocols, wl_output actually returns the same scaling mode for two screens even if they have a different scaling setting.
One thing I also never got is why the displays have to have absolute coordinates when you place them on a global coordinate system that is dependent on the scaling mode of the screen.
Also, KDE is the only WM that has managed to properly implement scaled Xwayland windows.
Yes, but if any application can break the entire system audio, that's a bug in more than just the application. (Granted, I'm curious why Wayland would trigger that, given that I would expect the audio stack to be the same regardless.)
Not a fan of Zoom by any stretch - but I have to use it all the time for work, regularly use it on three different machines and over some questionable network connections, and it's never crashed on me once that I can recall.
All on X, though. I appreciate the principles behind Wayland, but sadly not the implementation.
Me too. I really wanted to like Cosmic but the hassles wayland causes with ordinary things like zoom is just not worth it. Plus all the progress with gaming that has been made on Linux, wayland ruins. I’m back to X and get off my lawn etc.
What is the issue with zoom on wayland? Granted I only use on a web browser but I have entered numerous zoom calls these last 6 months without any issue.
On AMD hardware, VRR works fine on xorg and has for quite a long while now... so long as you have either a single active monitor (or maybe the restriction is just "don't have any active non-VRR monitors"). [0] I don't have Intel or Nvidia hardware so I can't test, but the Arch wiki says that they both work fine with VRR. [1]
The only Wayland feature that I've heard be commonly touted that xorg lacks is HDR support.
[0] I don't know which is it because I haven't bothered to go out and buy a second VRR-capable monitor.
Yeah, I still use KDE with X11 because they somehow messed up their window management with Wayland. My problems aren't even about rendering or any those features, but for some reason kwin_wayland's window management is very buggy. I'm still on 6.6 on the distribution that I use, so I don't know if it's fixed in 6.7, but I doubt it since it is here for a long time. Reported it here: https://bugs.kde.org/show_bug.cgi?id=524083
My main WM is Window Maker but i use KDE Plasma for secondary accounts when i want to try stuff without 'polluting' my main user account.
I can only use X11 with KDE Plasma because, for some unfathomable reason, if i launch `startplasma-wayland` pressing ANY key on my keyboard causes it to crash.
This. I even install a "Zoom Redirector" Firefox plugin so it automatically opens Zoom links in the web url. Screen sharing works great in Firefox. Zoom's native app just expects Xorg, and probably hasn't been tested at all on anything else. Crappy performance on Wayland is not really a Wayland problem.
Wayland should expired, Wayland is architectural failure plagued with bad design decisions, xlibre is gaining momentum and it is not broken piece of a pile
what's more - this seems like yet another RedHat/IBM project which destroys variety and flexibility in favor of their problematic choices, often with a degradation of functionality. systemd, Wayland, GNOME - and of course nothing would run on BSDes, heavens forbid.
With X11 seeing renewed, independent work via https://xlibre.net - why not embrace _that_ rather than go down the crooked Wayland path?
Given who founded Xlibre (Metux) has some...interesting history (he was banned from the X.org project due to poor code quality and practices [1]) I would say no
Metux himself also has some "fascinating" takes as archived from other projects such as the LKML [1] and Devuan [2] mailing lists
Ah yes, "he doesn't agree with me, therefore he must be [insane|incapable|inept]" argument tied in with some nothing burger about Metux pushing code that could break things.
While I'm over here having to move to Xorg as Wayland breaks my applications about once every two months. Breaking changes, poor code quality, LLMs, or maybe it's just that the devs of Wayland were more motivated by their own personal needs/wants then the Xorg users.
I can never get back the hours I lost troubleshooting graphics drivers only to realize that Wayland claimed it should work, but doesn't. I'll take whatever Metux gives me if it works, or from anyone else for that matter.
You're trying to cancel this guy's project on hackernews comments because he quoted winston churchhill in 2025 and didn't get a vaccine donut in 2019?
What do you get from it? Is he your enemy? Seems like you are trying to destroy him using this comment as attack vector. And this comment is well prepared and sourced and easily repeatable, so I presume you use multiple attack vectors like this.
Just an observation. And as an observer, this is annoying to see.
None of that matters if you don't have a HDR monitor, only have one monitor, and when absolute basics of window management are somehow broken under KDE Wayland. Why that even has anything to do with Wayland I don't know. I just know that it all works perfectly when I use KDE X11. Maybe other DEs/WMs have better Wayland implementations, I don't know.
Yeah, but it works under KDE+X11. Wayland it the thing that changes. I think KDE has it's own Wayland implementation? kwin_wayland is what is broken, probably. Why they broke it when porting it from X11 I don't know. But the effect is the same: Can't use it as of now.
i like the idea of wayland but i agree about the loss of flexibility. they seem very concerned about security and make screen sharing very complex now if you stray from the accepted path. systemd complicates this further with logind seat management etc. as a result our companies dev servers where we run a bunch of simultaneous VNCs and independent mate desktop sessions can really only work with X11 for now. There is a way to do it with nested cgroups running n number of systemd instances etc but its a pain and then we would have to use gnomes built in rdp thing which we dont want to use… anyway i actually vibe coded a way to get it working with wayland in containers with a dummy kernel video driver, my own fake logind etc. etc. etc. it was a harrowing experience but fun.
A number of wayland compositors are available in at least freebsd and openbsd (haven't checked on netbsd and dragonflybsd). Wayland is only a protocol. Whoever wants to support it can.
That's probably the worst argument that you could make against Wayland: there has only ever been a single X11 server in common use on the Linux desktop (first XFree86, now X.Org), but there are tons of independent Wayland "server" implementations (Weston, Mutter, KWin, wlroots, etc.) [0]. Lots of these are written in completely different languages and implement different extensions from each other, so there's way more variety and flexibility with Wayland than with X11.
The more common criticism that I've heard is that Wayland's variety and flexibility is actually bad, because it makes it harder to add extensions (since you need to implement it in multiple different projects, and not just the single X.Org codebase), and it means that applications potentially have to test against multiple implementations. (I don't necessarily agree with this criticism myself, but it's still a valid complaint.)
> and of course nothing would run on BSDes
FreeBSD [1] and OpenBSD [2] both have Wayland support.
Keith Packard and Alan Coopersmith, maybe, but the younger devs—those knowledgeable about graphics and GPUs anyway—no. There's no path forward for X11. It's a dead end.
Even Xwayland is just barely supported it seems. It was only intended as a compatibility layer for legacy applications. How long is such legacy support intended to continue? A decade? Two decades? The major toolkits now have Wayland code paths, and that's where the focus is. By 2030 their X code paths will be removed altogether.
Xlibre is a joke, maintained by an incompetent nazi.
I kind of wonder that too, I'm fine using wayland but it seemed like a huge user hassle for not many benefits (namely independent screen scaling which xlibre now supports). It's a shame xlibre didn't come around sooner, after years of pain wayland support has gotten a lot better, to the point I can more or less use either without issue.
At this point, I'm half convinced that someone with $100k in api spend of Fable tokens can create a better replacement for X11/Wayland, and patch all common open source apps to leverage it.
At this point I don't know who it is for, but it's not for users.
reply