Hopefully forever tbh until a proper alternative to XWayland arrives:
XWayland is essentially the missing mid-level "Wayland client library" which fills the feature gaps caused by missing extensions of the underlying Wayland implementation and it provides a common and fully featured GTK/KDE-agnostic window managemnt layer. Until the Wayland project releases a client library 'for the rest of us' with a similar intent, XWayland is still very much needed for applications that don't want to or cannot link against GTK or KDE for various reasons.
Agree. It sometimes feels like it gets forgotten in the wayland vs xorg divide.
One of the nice things about flatpak (another contentious topic), is that for GUI apps where it matters I can trivially set whether I want to prefer xwayland vs wayland, and keep compatibility. It's very nice for the few apps that are still xorg hardcoded and with flatseal, or KDE app settings I don't need to mess with setting the environment variables myself.
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.
> 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.
Consider that if every DE wrote their own Xorg implementation the story would be the same.
A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
I spent some time in the last week fixing lowdpi font rendering in cosmic, enabling me to switch to it. I then discovered that cosmic-comp's VRR had a terrible feedback path causing conformant applications to stutter badly, so I have large patch stack rewiring full screen feedback, tranche compatibility, fence timing and so on (it's fucking buttery now though, which is nice). That then showed up some input processing bugs becoming visible via playing videos in firefox, leading further to me discovering that cross-plane locking was causing frame drops too. Now I've got a giant stack of shit I need to cleanup and upstream - but the end result (along with the freetype render patches I got into Firefox a while back) is a better DE than I've had on Linux in decades. Maybe if upstreaming goes well I'll do MPO for an encore.
> 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.
See above, the WM did not need to embed the compositor. That's not a protocol requirement, it's and implementer choice. I actually really wish it didn't. Of all the aforementioned patches only two are in Smithay. As I was actually fixing compositing for the workflow I just had to suffer through I would have had to restart pretty much the whole session anyway - though in fact the later stages of my workflow I was only directly killing cosmic-comp and cosmic-session was automatically restarting it all. No really good way to recover the surfaces though, so apps still need to restart.
This is not unlike the _another_ bug stream I tracked down this evening, where cosmic-applets would fail to display tray icons on both displays correctly - that turned out to be a bug where one icon provider was unresponsive to part of the protocol, coupled with a synchronous dispatch from the event handle into that blocking return call. Perhaps more interestingly though that manifest during diagnosis something I've seen a lot in other DE chains where tray icons for auto-started electron apps were highly sketchy - well a common electron wrapper gives up entirely on the first whiff of an error with the dbus interface and doesn't retry.
Years ago I gave up on Linux DE's because reconfiguring xft, gnome, etc was too much of a time sink. How far I've come, now I'm back :'(
> A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
Dude, because that is how wayland is designed. X is a display server. Wayland is a protocol with implementation. If you want tiling, you have to roll your own, with ALL the protocols that are needed. It's up to clients to render. It was one of the fundamental critiques people had of the whole thing. 15 years in, and it's still the same. Need Vulkan rendering? See you in two years. And then every single WM has to implement it. Not even the basic premise of fractional scaling is solved properly, except in the one use case which is single monitor usage.
It's not about collaboration. wlroots was an attempt at having a standardized layer, and many protocols made it back into upstream actually. But even there, no two wlroots compositors are the same. We used to call these WMs, because the compositor layer could be separate on X. Anyway, bugs persist for years, some parts are never fixed, lots of basic features that existed in X for decades needed people to implement in their own compositor report back and then create a standardized protocol. So KDE has their own, gnome has their own, Hyprland recently rolled their own, etc.
And then there is of course gnome, which seems to want to break random basic functionality for no good reason(hello tray icons). Gnome of course didn't use to be like that.
But a plug, the absolute best wlroots based compositor I have used is mangowm[1][2]. You report a bug in the morning and in the afternoon dreammaomao has a solution for it. Of course I'm exaggerating a bit, but I think I've used pretty much every major Wayland compositor extensively so far.
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.
Sure, but people don't really care about that. They care about it working, and if it works better under one environment than another, they'll blame the environment where it doesn't work as well. That's just natural.
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.
Yup pretty much. Desktop sharing on Chromium based browsers is fine (probably others but I can't vouch for them), it's fine on OBS Studio, portals work, etc...
But there's a contingent of Linux users that thinks anything new = bad so they'll find the most dogshit app that doesn't work and trot it out as proof that the new thing is bad.
For me zoom works out of the box on kde + wayland. But an app as popular as zoom working correctly for everyone is table stakes.
The fact some people are encountering issues just means that something in the transition wasn't perfect. Given the huge lift involved, it could have been a lot worse. I just wish there was clearer communication and strategies for transition from the wayland folks, and less fearmongering and entrenching from both sides.
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.
Are you doing that with xorg or Wayland? If with xorg, have you verified that VRR is working? [0] If you've verified it, how'd you make it work? It'd be quite nice to have both multi-monitor and VRR... unless I have to make some terrible tradeoff to make it happen.
[0] My go-to is using the "scrolling bars" mode of this LÖVE program [1] to make judder at update rates that aren't an -er- even fraction of the screen's refresh rate pretty easy to spot... but if you have something that works for you, that's good.
I would never, ever, ever, use X in 2026 for general use. There would have to be some kind of niche and important business reason.
X, for all the teeth gnashing, is effectively a virtually dead, and virtually unsupported technology at this point. There are some small pockets here and there of people that really want or need it, and a few of those people are also working on tweaks and patches, but it's a tiny handful compared to the people and money and companies working on or with Wayland at this point. I know some people here are very upset about that.
Years and years ago Wayland sucked ass. Now? Performance and stability have been great on modern distros with modern kernels and GPUs. If performance was substantially worse or more clumsy to use with Wayland vs X, then I'd certainly be using X, but that's just not the case for me in 2026.
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.
I tried using the Zoom webapp on Firefox, on X11, for quite a while, but eventually I gave up and started using the native app. The web app is slow and burns CPU (and my laptop fans start going nuts), and for some reason the quality of the video that's coming out of my camera looks much worse on the webapp. (This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.)
If I were to switch to Wayland and have to go back to the webapp for Zoom, that would be annoying.
(I'm not sure if all of those are necessary, but that's what I'm currently using.)
Then in Linux, make sure that you have the full versions of all the codecs installed; in Fedora, you need to install "mesa-va-drivers-freeworld" and "ffmpeg" from rpmfusion (and uninstall "mesa-va-drivers" and "ffmpeg-free" from the regular repos); for other distros, the steps should be similar.
But after all that, my Firefox uses only 20% of a single CPU to run Zoom, so my laptop is cool and the fan stays off.
(I agree that it's really annoying that all of these steps are needed just to make video work well, but they're orthogonal to Wayland, and would be needed with X11 in the browser too.)
> This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.
Google Meet probably uses VP9 or AV1 (since both are developed by Google), and those are both patent-free so should have no issues on Linux. Whereas Microsoft Teams and Zoom only use h264, which for patent reasons is limited to software-only by default [0]. I'm guessing that Zoom Linux application likely embeds the relevant codecs, which would be why it works there without any extra steps.
Sure, I understand why most Linux distros omit proprietary codecs (and mostly agree with it). But to the average user, it's not easy to explain why h264 videos play out-of-the-box on Windows and macOS, while you need to first run some arcane terminal commands on Linux. And hardware decoding is even more confusing, because you would assume that the hardware manufacturer would have already paid any necessary royalties, but of course things can't be so simple [0].
But AV1 is starting to become fairly popular, and most of the h264 patents have expired, so this should all hopefully be a non-issue in a few years.
1. Most Linux distros install Firefox by default while very few install Chromium, so I suspect that most Linux users use Firefox (even though Chrome is far more popular in general).
2. On Fedora, openSUSE, and similar distros, the Mesa in the main repos is built without h264 hardware decoding support, so no applications will be able to use hardware decoding unless you run some terminal commands. That being said, the more user-friendly distros tend to have this enabled by default.
3. Chromium doesn't officially support hardware decoding on Linux at all [0], whereas Firefox does. (Hardware decoding still works, it's just not officially supported.)
4. Up until a few months ago [1], you had to start Chromium with some special flags [2] to enable hardware decoding.
5. Hardware decoding should be enabled in Firefox by default, so those "about:config" flags for Firefox that I mentioned above shouldn't be necessary in most cases, but since it wasn't working for the OP, I suggested those flags to force-enable it. (A few years ago, hardware decoding would crash occasionally, and Firefox automatically disables it if it has ever crashed in the past before. It's super stable now, but old installations will often have it disabled due to bugs that were fixed years ago.)
- Pipewire or Pulseaudio has nothing to do with XWayland, let alone Wayland (Pulseaudio is somewhat legacy and may not be maintained as well as it used to be)
- Zoom (the last time I checked, a while ago) wasn't really well implemented on Linux (came before xdg-desktop-portal, which has standardised screen sharing across DEs and only really prioritised the GNOME specific extensions.
- The engineering effort to properly support screen sharing on Linux is a _bit_ more complicated than other platforms as we have many DEs
- Browser based screen sharing is generally the best option on Linux imho
> - The engineering effort to properly support screen sharing on Linux is a _bit_ more complicated than other platforms as we have many DEs
It didn't have to be this way, but somehow the Wayland clique did not realize - or just dug their head in the sand - that things like screenshots or screen sharing are basic table stakes. Instead, they created an academic replacement for X11 and left it upon the community to plug the most obvious gaps.
Understandably, actual users tend to get kind of pissed when you break their computer without offering any replacement except "just quit your job and don't use Zoom" or "wait 10 years for Gnome to add protocol foobar to support it, but they will force you to use this half baked crap beforehand anyway".
Thankfully Windows and macOS have been doing their darndest to regress. Otherwise desktop Linux wouldn't stand a chance with such harebrained management. Only after a decade of biting teeth Wayland is finally ready for most.
Wayland simplified it significantly. Screen sharing is now done through xdg, and it's standardized. Meaning, you don't need to rewrite frail screensharing code for multiple desktops. You just use xdg and then boom - it works across every distro, every window manager, every compositor, every GPU.
Screensharing on X was hacky, and each application did their own thing to capture the screen. So sometimes it would work, sometimes it wouldn't, sometimes it would have horrible performance, sometimes your specific GPU would break it, etc. Some apps handled it better than others as well. Wayland solves this.
Yes that does mean you need to use xdg standards instead of the old code that barely worked. Yes that does mean some apps will take forever to adopt it because they don't care. But it is actually a better system.
And there's other really cool xdg protocols, too, that enable a type of cross platform design that was never possible on X.
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.
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
it seems that there are only two additional significant contributors (an anonymous "stefan1111" and Alan Coopersmith, an X.org member who maintains the Solaris port), and a larger number of people who contributed a couple of commits here and there - and Enrico Weigelt (metux)'s commits are about three times as many as everyone else's combined. So, it is still very much his project, although not exclusively.
As for your links: You point to some exchanges which indicate problematic opinions, and an exchange which indicates, or at least, in which the project founder is accused of being somewhat reckless in making changes. The first kind of are legitimate to point out, and would make me wary of befriending him, but not directly relevant to his technical capabilities. The second kind is more worrying. Do you have a link to someone analyzing/considering the changes made to Xlibre relative to Xorg?
Be that as it may - while this does not sway me into belief in Wayland, it does introduce a grain of salt into my view of the X side of things, and thank you for that.
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.
Not the person you're replying to, but years ago Metux used to send PRs to a different project that I maintain. He was difficult to work with, insisted that his way was the right way when I wanted something else, and his code quality was usually middling at best. Some of his PRs were of the annoying "tidy this up" form, where it felt like someone who just wanted more commits in a repo and lines in `git blame`.
I hope his xlibre project is successful, but my opinion of the project is certainly tainted by my past interactions with him.
I don't doubt you. I think it's a good way to look at it. I appreciate what he's trying to do with Xlibre but I would never work in that environment with or without him.
As I said to the other guy I just hope this is better than what we have and I'll take about anything at this rate. I don't care to deal with people on that level anymore, which is why I stopped developing OSS over 10 years ago; everyone has their opinions about the code, if they can't solve that they fight over politics to "justify" forking and the downward spiral ever goes downward.
> Ah yes, [...] some nothing burger about Metux pushing code that could break things.
Not could break, did break. Multiple times. When a contributor repeatedly submits broken and untested PRs, the correct solution isn't to let him keep trying as often as he wants.
In context if you read what I said I didn't imply Metux was the best out there; I was highlighting how absolutely terrible Wayland is and how I will take anything at this point.
Citations from people who want the whole platform die. (Actually they get paid for that, it's their dayjob to kill X11, but it can be their personal belief as well)
Yep, it is important to remember Metux was a sole guy supporting Xorg for many years while everybody else outright refused to touch the codebase. Then they blamed Metux for "breaking compatibility." While this sounds like a plausible reason, long time Linux users could recall that every major X release broke something in one way or another. It's just how it is, there is no way around it. They blamed Metux for doing something that cannot be avoided while maintaining the project, and claimed that Xorg must burn.
They also claimed features like namespaces would be impossible to implement in Xorg, which was later proven false as Xlibre brought XNamespaces -- as well as HDR and seat management. :)
I'm personally a Wayland user because I have AMD iGPU and use whatever comes by default, but I couldn't imagine Nvidia users having the same experience as me, even with their new drivers. I know it sucks because I used to own Nvidia. Removing Xorg while Nvidia users make up the majority is insane.
IIRC they blamed Metux for unnecessarily breaking BC, e.g. renaming & moving around symbols when it wasn't necessary and didn't improve features or fix bugs.
When you're working on something this foundational, BC breaks should always have a good reason, and he repeatedly didn't give any. This causes churn for all downstream consumers.
> It's just how it is, there is no way around it.
There literally is a way around it: not doing unnecessary BC breaks.
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.
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.
The hard part is knowing where to draw the line between relatively stable infrastructure items that don't benefit from duplication, and flexible items that are likely to benefit from specialization and competition.
X11 made the right choice in putting graphics drivers in the "stable infrastructure" stuff and display toolkits and window managers in the "specialize and compete" section.
I'm sort of pleased about that we're finally trying to replicate this division with the River ecosystem, building a standard compositor that we can plug in different actual window management logic into it, but that makes River itself a huge single point of failure-- if it has a bum release or fails to keep up with trends and extensions, it takes down a lot of the ecosystem, but perhaps not enough to be a five-alarm fire the way Xorg or XF86 back in the day would have been.
I think the flexibility issues is more that you can't easily do things that used to be trivial. Try to spin up a bunch of headless wayland gnome sessions with VNC on a modern linux distro running on a server, it basically can't be done. This was trivial in the past, you just launched an X11 server for each one and handed it to VNC and you were done.
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.
I use KDE and have for 10+ years. In my experience, kwin is the most stable and performant it's ever been. I don't notice anything at all, ever. Under X, it was common to get stuttering, tears, and dropped frames. Not anymore. I mean I run 2 204hz 1440p monitors. And it's perfect, always.
I'm not saying you're wrong, but it's clear that basics of window management are not universally broken under Wayland. It works well for me and has for a couple of years.
> 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
So you think we should have one protocol for people who have HDR etc and another for those that don't?
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 don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.
I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.
Yep. Sucks. It's the only thing I miss about gaming on Windows. Hopefully xlibre will be adding that in.
> ...VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration...
I know that the first two work fine on xorg [0]. It's not entirely clear what you're talking about with the third, but I know that xorg supports compositor bypass for windows so that programs can interact with the graphics card without the windowing system getting in the way. Like, I think this is a thing people were talking about working on back when Compiz and its wobbly windows was new and exciting.
If that isn't what you mean by your third thing, perhaps you'd be interested in specifying what video acceleration mechanism xorg doesn't have?
> ...support for tiled GPUs.
Doesn't that only matter for Apple Silicon(TM) machines, and maybe some ARM machines with integrated graphics? If folks want that, it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork. Can you show me a feature or features of xorg that makes it impossible.. other than FDO's tactical neglect?
EDIT: Actually, I dimly recall some old hardware that I think was supported by DRM that did tiled rendering. Maybe it was some PowerVR stuff? If my memory isn't failing me, then there's the counter to claims that it's impossible for xorg to support. :P
[0] Source: Me having these work just fine for quite a long time now on my personal machines that run xorg.
You will also need toolkits/games to add support for any additional protocol, which I doubt they will.
> It's not entirely clear what you're talking about with the third
Zero-copy video means you can play vides in web pages hardware accelerated and have no copy of the video frame required to send it to the display. This saves a lot of power.
> it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork
Compositing with Xorgs model and applying any kind of screen effect would be extremely painful on tiling GPU because of how the screen is passed back and fourth to the compositor. Given compositing in Wayland compositors is passive, it does not have that issue.
Notice how Wayland on the RPi had performance that it simply couldn't gain under Xorg.
> Me having these work just fine for quite a long time now on my personal machines that run xorg
Good for you. But we have modern hardware and demands that simply Xorg doesn't meet and the protocol is archaic that adding support isn't worth it.
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.
> Wayland is only a protocol. Whoever wants to support it can.
I'm kinda tired of this line that I see everywhere. The bottom line is that most people develop for Linux, and don't consider the BSDs, and so things end up broken, or not working at all. The popular libraries for writing Wayland compositors consider Linux first, and BSD support is bolted on later.
The end result is that it's just more work for everyone. X11 could have been fixed, it's just no one wanted to do so in time to head off the Wayland work. XLibre and Phoenix might have ended up working out if they'd been started 10-15 years ago, but Wayland has too much momentum now, for better or worse.
(Source: I am a Wayland compositor maintainer who would love it if his stuff would work on the BSDs, but I don't have the time or energy to install a BSD and test and fix.)
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.
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.
There were years where, to my understanding, they were deliberately not accepting features or patches to push Wayland, which is kind of frustrating, because it misses the point of a competitive ecosystem. Like on one hand if they're deliberately sabotaging Xorg for Wayland it implies Wayland must actually be a lot better, but on the flip side if Linus had sabotaged linux in favor of seL4 we'd all be worse off, even though kernel engineers often regard microkernels as a "better architecture".
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
Lol, we don't talk about xlibre here. Announcments and reviews are banned.
Waiting for dang to argue the 7th time that is not somehow his personal decision to ban xlibre that he's set up a system where a couple of nazis with automated scripts can hide an article which requires his manual attention to put (which he doesn't do)
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.
Likely, but more the point I'm making is we're now approaching a point where this kind of issue is solvable with resources in reach of a small company / wealthy individual.
Nice. XWayland has been a key transitional piece we'll still need for a while.
Hopefully forever tbh until a proper alternative to XWayland arrives:
XWayland is essentially the missing mid-level "Wayland client library" which fills the feature gaps caused by missing extensions of the underlying Wayland implementation and it provides a common and fully featured GTK/KDE-agnostic window managemnt layer. Until the Wayland project releases a client library 'for the rest of us' with a similar intent, XWayland is still very much needed for applications that don't want to or cannot link against GTK or KDE for various reasons.
Agree. It sometimes feels like it gets forgotten in the wayland vs xorg divide.
One of the nice things about flatpak (another contentious topic), is that for GUI apps where it matters I can trivially set whether I want to prefer xwayland vs wayland, and keep compatibility. It's very nice for the few apps that are still xorg hardcoded and with flatseal, or KDE app settings I don't need to mess with setting the environment variables myself.
> EGLStream support is removed
Wait, does this mean Nvidia won't have GPU acceleration for apps under XWayland anymore? Or is EGLStream not what I think it is?
Nvidia finally started supporting GBM in 2021. IIUC EGLStream is more vestigial now and can be removed.
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.
I'm not sure that Zoom is the highest quality software. I find it crashy and weird under either X or Wayland.
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.
> 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.
Consider that if every DE wrote their own Xorg implementation the story would be the same.
A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
I spent some time in the last week fixing lowdpi font rendering in cosmic, enabling me to switch to it. I then discovered that cosmic-comp's VRR had a terrible feedback path causing conformant applications to stutter badly, so I have large patch stack rewiring full screen feedback, tranche compatibility, fence timing and so on (it's fucking buttery now though, which is nice). That then showed up some input processing bugs becoming visible via playing videos in firefox, leading further to me discovering that cross-plane locking was causing frame drops too. Now I've got a giant stack of shit I need to cleanup and upstream - but the end result (along with the freetype render patches I got into Firefox a while back) is a better DE than I've had on Linux in decades. Maybe if upstreaming goes well I'll do MPO for an encore.
> 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.
See above, the WM did not need to embed the compositor. That's not a protocol requirement, it's and implementer choice. I actually really wish it didn't. Of all the aforementioned patches only two are in Smithay. As I was actually fixing compositing for the workflow I just had to suffer through I would have had to restart pretty much the whole session anyway - though in fact the later stages of my workflow I was only directly killing cosmic-comp and cosmic-session was automatically restarting it all. No really good way to recover the surfaces though, so apps still need to restart.
This is not unlike the _another_ bug stream I tracked down this evening, where cosmic-applets would fail to display tray icons on both displays correctly - that turned out to be a bug where one icon provider was unresponsive to part of the protocol, coupled with a synchronous dispatch from the event handle into that blocking return call. Perhaps more interestingly though that manifest during diagnosis something I've seen a lot in other DE chains where tray icons for auto-started electron apps were highly sketchy - well a common electron wrapper gives up entirely on the first whiff of an error with the dbus interface and doesn't retry.
Years ago I gave up on Linux DE's because reconfiguring xft, gnome, etc was too much of a time sink. How far I've come, now I'm back :'(
> A key question is why everyone is writing their own compositor, this is not about the protocol design, it's about the state of collaboration.
Dude, because that is how wayland is designed. X is a display server. Wayland is a protocol with implementation. If you want tiling, you have to roll your own, with ALL the protocols that are needed. It's up to clients to render. It was one of the fundamental critiques people had of the whole thing. 15 years in, and it's still the same. Need Vulkan rendering? See you in two years. And then every single WM has to implement it. Not even the basic premise of fractional scaling is solved properly, except in the one use case which is single monitor usage.
It's not about collaboration. wlroots was an attempt at having a standardized layer, and many protocols made it back into upstream actually. But even there, no two wlroots compositors are the same. We used to call these WMs, because the compositor layer could be separate on X. Anyway, bugs persist for years, some parts are never fixed, lots of basic features that existed in X for decades needed people to implement in their own compositor report back and then create a standardized protocol. So KDE has their own, gnome has their own, Hyprland recently rolled their own, etc.
And then there is of course gnome, which seems to want to break random basic functionality for no good reason(hello tray icons). Gnome of course didn't use to be like that.
But a plug, the absolute best wlroots based compositor I have used is mangowm[1][2]. You report a bug in the morning and in the afternoon dreammaomao has a solution for it. Of course I'm exaggerating a bit, but I think I've used pretty much every major Wayland compositor extensively so far.
[1] https://mangowm.github.io/
[2] https://github.com/mangowm/mango
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.)
Yes, though you'd be inclined to suspect the audio stack having the bug rather than the display compositor.
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.
Sure, but people don't really care about that. They care about it working, and if it works better under one environment than another, they'll blame the environment where it doesn't work as well. That's just natural.
zoom users often have little choice but to use zoom.
wayland doesn't have that need.
> not sure that Zoom is the highest quality software
30 years ago, a client shouldn't crash the server. Yes, things evolve ...
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.
Isn't the issue just the zoom desktop app?
> Isn't the issue just the zoom desktop app?
Yup pretty much. Desktop sharing on Chromium based browsers is fine (probably others but I can't vouch for them), it's fine on OBS Studio, portals work, etc...
But there's a contingent of Linux users that thinks anything new = bad so they'll find the most dogshit app that doesn't work and trot it out as proof that the new thing is bad.
For me zoom works out of the box on kde + wayland. But an app as popular as zoom working correctly for everyone is table stakes.
The fact some people are encountering issues just means that something in the transition wasn't perfect. Given the huge lift involved, it could have been a lot worse. I just wish there was clearer communication and strategies for transition from the wayland folks, and less fearmongering and entrenching from both sides.
> The fact some people are encountering issues just means that something in the transition wasn't perfect.
There's thousands of Linux distros. I'd assume most of them are not super close to the Wayland folks.
Screen share doesn’t work on my setup. Difficultly: nvidia
What are you using instead of Cosmic? (for X)
Whatever environment Pop!Os defaults to if you tell it not to use wayland
Majority of that gaming progress was made by Valve for Steam Deck. And Steam Deck uses Wayland
So what are the Pop!Is guys doing wrong? Their plain X environment has none of the gaming issues wayland has
they wrote a whole DE from scratch. It's gonna take awhile for it be up to snuff for everything.
You are using alpha level DE made by a tiny company in their free time.
> Plus all the progress with gaming that has been made on Linux, wayland ruins.
You're way behind.
Wayland is fine. Wayland + VRR is even better.
XWayland otoh is quite bad.
https://marco-nett.de/blog/measuring-input-latency-on-linux-...
> Wayland + VRR is even better.
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.
[1] <https://wiki.archlinux.org/index.php?title=Variable_refresh_...>
I am running Fedora 44 with a mix of monitors using vrr and and no vrr on AMD 9060 XT with mixed refresh rates. No issues.
Ooh!
Are you doing that with xorg or Wayland? If with xorg, have you verified that VRR is working? [0] If you've verified it, how'd you make it work? It'd be quite nice to have both multi-monitor and VRR... unless I have to make some terrible tradeoff to make it happen.
[0] My go-to is using the "scrolling bars" mode of this LÖVE program [1] to make judder at update rates that aren't an -er- even fraction of the screen's refresh rate pretty easy to spot... but if you have something that works for you, that's good.
[1] <https://github.com/Nixola/VRRTest/releases/tag/v2.0.0>
Wayland, X was removed long ago.
I game on this rig with proton.
I would never, ever, ever, use X in 2026 for general use. There would have to be some kind of niche and important business reason.
X, for all the teeth gnashing, is effectively a virtually dead, and virtually unsupported technology at this point. There are some small pockets here and there of people that really want or need it, and a few of those people are also working on tweaks and patches, but it's a tiny handful compared to the people and money and companies working on or with Wayland at this point. I know some people here are very upset about that.
Years and years ago Wayland sucked ass. Now? Performance and stability have been great on modern distros with modern kernels and GPUs. If performance was substantially worse or more clumsy to use with Wayland vs X, then I'd certainly be using X, but that's just not the case for me in 2026.
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.
Like. How.
Wayland's raison d'etre was “every frame is perfect.” Input was an afterthought.
> every frame is perfect.
They are a big Monty Python fan. Wait, you meant frame ?
I've been screensharing using the Zoom web application (via Firefox) on Wayland for almost 5 years now, and it's always worked well for me personally.
Does screen annotation work on it? It's loss in the wayland version of zoom has been a major pain for me at work.
Not annotating when you yourself are screen sharing, but when someone else is screen sharing you can draw on their screen(aka annotating)?
Sorry, but I've never tried that before, so I'm not sure. (I didn't even know that Zoom had that feature at all!)
I tried using the Zoom webapp on Firefox, on X11, for quite a while, but eventually I gave up and started using the native app. The web app is slow and burns CPU (and my laptop fans start going nuts), and for some reason the quality of the video that's coming out of my camera looks much worse on the webapp. (This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.)
If I were to switch to Wayland and have to go back to the webapp for Zoom, that would be annoying.
> The web app is slow and burns CPU (and my laptop fans start going nuts)
Ah yeah, that's because codecs are (still) a mess on Linux. In Firefox, navigate to about:config, then make sure that the following are set:
(I'm not sure if all of those are necessary, but that's what I'm currently using.)Then in Linux, make sure that you have the full versions of all the codecs installed; in Fedora, you need to install "mesa-va-drivers-freeworld" and "ffmpeg" from rpmfusion (and uninstall "mesa-va-drivers" and "ffmpeg-free" from the regular repos); for other distros, the steps should be similar.
But after all that, my Firefox uses only 20% of a single CPU to run Zoom, so my laptop is cool and the fan stays off.
(I agree that it's really annoying that all of these steps are needed just to make video work well, but they're orthogonal to Wayland, and would be needed with X11 in the browser too.)
> This isn't the case for Google Meet on Firefox, so it's something about Zoom's webapp.
Google Meet probably uses VP9 or AV1 (since both are developed by Google), and those are both patent-free so should have no issues on Linux. Whereas Microsoft Teams and Zoom only use h264, which for patent reasons is limited to software-only by default [0]. I'm guessing that Zoom Linux application likely embeds the relevant codecs, which would be why it works there without any extra steps.
[0]: https://en.wikipedia.org/wiki/OpenH264
> codecs are (still) a mess on Linux
They're a mess everywhere for legal reasons. The solution is what Chrome and many other apps do: just ship codecs with the app.
Sure, I understand why most Linux distros omit proprietary codecs (and mostly agree with it). But to the average user, it's not easy to explain why h264 videos play out-of-the-box on Windows and macOS, while you need to first run some arcane terminal commands on Linux. And hardware decoding is even more confusing, because you would assume that the hardware manufacturer would have already paid any necessary royalties, but of course things can't be so simple [0].
But AV1 is starting to become fairly popular, and most of the h264 patents have expired, so this should all hopefully be a non-issue in a few years.
[0]: https://lwn.net/Articles/910978/
> you need to first run some arcane terminal commands
Not if you install Chrome, Brave, Vivaldi, etc... like most users...
1. Most Linux distros install Firefox by default while very few install Chromium, so I suspect that most Linux users use Firefox (even though Chrome is far more popular in general).
2. On Fedora, openSUSE, and similar distros, the Mesa in the main repos is built without h264 hardware decoding support, so no applications will be able to use hardware decoding unless you run some terminal commands. That being said, the more user-friendly distros tend to have this enabled by default.
3. Chromium doesn't officially support hardware decoding on Linux at all [0], whereas Firefox does. (Hardware decoding still works, it's just not officially supported.)
4. Up until a few months ago [1], you had to start Chromium with some special flags [2] to enable hardware decoding.
5. Hardware decoding should be enabled in Firefox by default, so those "about:config" flags for Firefox that I mentioned above shouldn't be necessary in most cases, but since it wasn't working for the OP, I suggested those flags to force-enable it. (A few years ago, hardware decoding would crash occasionally, and Firefox automatically disables it if it has ever crashed in the past before. It's super stable now, but old installations will often have it disabled due to bugs that were fixed years ago.)
[0]: https://chromium.googlesource.com/chromium/src/+/master/docs...
[1]: https://issues.chromium.org/issues/40225939#comment67
[2]: https://wiki.archlinux.org/title/Chromium#Hardware_video_acc...
So moving goalposts... Normies don't care about hardware decoding, they care that the thing plays.
Also Windows doesn't have 100% codec coverage either: https://learn.microsoft.com/en-us/windows/apps/develop/media...
Hence Chrome and others shipping codecs...
A couple of points:
- Pipewire or Pulseaudio has nothing to do with XWayland, let alone Wayland (Pulseaudio is somewhat legacy and may not be maintained as well as it used to be)
- Zoom (the last time I checked, a while ago) wasn't really well implemented on Linux (came before xdg-desktop-portal, which has standardised screen sharing across DEs and only really prioritised the GNOME specific extensions.
- The engineering effort to properly support screen sharing on Linux is a _bit_ more complicated than other platforms as we have many DEs
- Browser based screen sharing is generally the best option on Linux imho
> - The engineering effort to properly support screen sharing on Linux is a _bit_ more complicated than other platforms as we have many DEs
It didn't have to be this way, but somehow the Wayland clique did not realize - or just dug their head in the sand - that things like screenshots or screen sharing are basic table stakes. Instead, they created an academic replacement for X11 and left it upon the community to plug the most obvious gaps.
Understandably, actual users tend to get kind of pissed when you break their computer without offering any replacement except "just quit your job and don't use Zoom" or "wait 10 years for Gnome to add protocol foobar to support it, but they will force you to use this half baked crap beforehand anyway".
Thankfully Windows and macOS have been doing their darndest to regress. Otherwise desktop Linux wouldn't stand a chance with such harebrained management. Only after a decade of biting teeth Wayland is finally ready for most.
Wayland simplified it significantly. Screen sharing is now done through xdg, and it's standardized. Meaning, you don't need to rewrite frail screensharing code for multiple desktops. You just use xdg and then boom - it works across every distro, every window manager, every compositor, every GPU.
Screensharing on X was hacky, and each application did their own thing to capture the screen. So sometimes it would work, sometimes it wouldn't, sometimes it would have horrible performance, sometimes your specific GPU would break it, etc. Some apps handled it better than others as well. Wayland solves this.
Yes that does mean you need to use xdg standards instead of the old code that barely worked. Yes that does mean some apps will take forever to adopt it because they don't care. But it is actually a better system.
And there's other really cool xdg protocols, too, that enable a type of cross platform design that was never possible on X.
Try browser zoom
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.
Do we really need the editorializing in the title?
I am not a fan of Wayland. I've not really bought the value proposition; and see also:
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d...
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
[1] https://gitlab.freedesktop.org/xorg/xserver/-/work_items/179...
[2] https://lkml.org/lkml/2021/6/10/957
[3] https://web.archive.org/web/20190404153507/https://lists.dyn...
I was about to reply that it is now a project with many contributions, but looking here:
https://github.com/X11Libre/xserver/graphs/contributors?from...
it seems that there are only two additional significant contributors (an anonymous "stefan1111" and Alan Coopersmith, an X.org member who maintains the Solaris port), and a larger number of people who contributed a couple of commits here and there - and Enrico Weigelt (metux)'s commits are about three times as many as everyone else's combined. So, it is still very much his project, although not exclusively.
As for your links: You point to some exchanges which indicate problematic opinions, and an exchange which indicates, or at least, in which the project founder is accused of being somewhat reckless in making changes. The first kind of are legitimate to point out, and would make me wary of befriending him, but not directly relevant to his technical capabilities. The second kind is more worrying. Do you have a link to someone analyzing/considering the changes made to Xlibre relative to Xorg?
Be that as it may - while this does not sway me into belief in Wayland, it does introduce a grain of salt into my view of the X side of things, and thank you for that.
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.
Not the person you're replying to, but years ago Metux used to send PRs to a different project that I maintain. He was difficult to work with, insisted that his way was the right way when I wanted something else, and his code quality was usually middling at best. Some of his PRs were of the annoying "tidy this up" form, where it felt like someone who just wanted more commits in a repo and lines in `git blame`.
I hope his xlibre project is successful, but my opinion of the project is certainly tainted by my past interactions with him.
I don't doubt you. I think it's a good way to look at it. I appreciate what he's trying to do with Xlibre but I would never work in that environment with or without him.
As I said to the other guy I just hope this is better than what we have and I'll take about anything at this rate. I don't care to deal with people on that level anymore, which is why I stopped developing OSS over 10 years ago; everyone has their opinions about the code, if they can't solve that they fight over politics to "justify" forking and the downward spiral ever goes downward.
> Ah yes, [...] some nothing burger about Metux pushing code that could break things.
Not could break, did break. Multiple times. When a contributor repeatedly submits broken and untested PRs, the correct solution isn't to let him keep trying as often as he wants.
idk man, it seems like a bunch of glass houses.
In context if you read what I said I didn't imply Metux was the best out there; I was highlighting how absolutely terrible Wayland is and how I will take anything at this point.
What applications?
That's quite a disingenuous response to something I said with citations and no direct stated opinions on the person.
Be better
Citations from people who want the whole platform die. (Actually they get paid for that, it's their dayjob to kill X11, but it can be their personal belief as well)
Yep, it is important to remember Metux was a sole guy supporting Xorg for many years while everybody else outright refused to touch the codebase. Then they blamed Metux for "breaking compatibility." While this sounds like a plausible reason, long time Linux users could recall that every major X release broke something in one way or another. It's just how it is, there is no way around it. They blamed Metux for doing something that cannot be avoided while maintaining the project, and claimed that Xorg must burn.
They also claimed features like namespaces would be impossible to implement in Xorg, which was later proven false as Xlibre brought XNamespaces -- as well as HDR and seat management. :)
I'm personally a Wayland user because I have AMD iGPU and use whatever comes by default, but I couldn't imagine Nvidia users having the same experience as me, even with their new drivers. I know it sucks because I used to own Nvidia. Removing Xorg while Nvidia users make up the majority is insane.
IIRC they blamed Metux for unnecessarily breaking BC, e.g. renaming & moving around symbols when it wasn't necessary and didn't improve features or fix bugs.
When you're working on something this foundational, BC breaks should always have a good reason, and he repeatedly didn't give any. This causes churn for all downstream consumers.
> It's just how it is, there is no way around it.
There literally is a way around it: not doing unnecessary BC breaks.
> Be better
What year are we in?
...Did we suddenly abandon bettering ourselves in 2026?
The "be better" comment was used exclusively by the worst people i knew for 4 years straight. So for me, absolutely.
It's condescending, unnecessary, and it is a polarizing comment people who are miserable leave to annoy the rest of us.
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.
That's a deliberate misreading of events but okay :)
> which destroys variety and flexibility
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.
[0]: https://en.wikipedia.org/wiki/List_of_display_servers#Waylan...
[1]: https://docs.freebsd.org/en/books/handbook/wayland/
[2]: https://xenocara.org/Wayland_on_OpenBSD.html#running-wayland
The hard part is knowing where to draw the line between relatively stable infrastructure items that don't benefit from duplication, and flexible items that are likely to benefit from specialization and competition.
X11 made the right choice in putting graphics drivers in the "stable infrastructure" stuff and display toolkits and window managers in the "specialize and compete" section.
I'm sort of pleased about that we're finally trying to replicate this division with the River ecosystem, building a standard compositor that we can plug in different actual window management logic into it, but that makes River itself a huge single point of failure-- if it has a bum release or fails to keep up with trends and extensions, it takes down a lot of the ecosystem, but perhaps not enough to be a five-alarm fire the way Xorg or XF86 back in the day would have been.
I think the flexibility issues is more that you can't easily do things that used to be trivial. Try to spin up a bunch of headless wayland gnome sessions with VNC on a modern linux distro running on a server, it basically can't be done. This was trivial in the past, you just launched an X11 server for each one and handed it to VNC and you were done.
HDR, VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration, support for tiled GPUs
Yeh... we should totally keep to X11.... especially when toolkits start to drop support.
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.
I use KDE and have for 10+ years. In my experience, kwin is the most stable and performant it's ever been. I don't notice anything at all, ever. Under X, it was common to get stuttering, tears, and dropped frames. Not anymore. I mean I run 2 204hz 1440p monitors. And it's perfect, always.
I'm not saying you're wrong, but it's clear that basics of window management are not universally broken under Wayland. It works well for me and has for a couple of years.
> 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
So you think we should have one protocol for people who have HDR etc and another for those that don't?
Multiple monitors care about this :)
Issue is not wayland but KDE from what I understand here
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.
You can't condemn a protocol because there are bad or buggy implementations.
HTML5 was not shitty because internet explorer was a shitty browser.
I don't condemn the protocol. I specifically mention the buggy implementation. I say that I use X11 because KDE's Wayland implementation is so buggy.
I want to use KDE. KDE was perfect for me before Wayland. I don't criticize Wayland here, I criticize KDE Wayland. And I'm worried because very soon KDE will delete X11 support.
Wish I could use it, I really tried! I have some HDR screens I want to actually run HDR on. But KDE Plasma + Wayland keep crashing out on me.
> especially when toolkits start to drop support.
Which toolkits are dropping support for X11?
AFAICR, few toolkits support Wayland (even though the two major ones, GTK and Qt, do).
> HDR...
Yep. Sucks. It's the only thing I miss about gaming on Windows. Hopefully xlibre will be adding that in.
> ...VRR, Mixed refresh rate/DPI displays, Zero-copy video acceleration...
I know that the first two work fine on xorg [0]. It's not entirely clear what you're talking about with the third, but I know that xorg supports compositor bypass for windows so that programs can interact with the graphics card without the windowing system getting in the way. Like, I think this is a thing people were talking about working on back when Compiz and its wobbly windows was new and exciting.
If that isn't what you mean by your third thing, perhaps you'd be interested in specifying what video acceleration mechanism xorg doesn't have?
> ...support for tiled GPUs.
Doesn't that only matter for Apple Silicon(TM) machines, and maybe some ARM machines with integrated graphics? If folks want that, it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork. Can you show me a feature or features of xorg that makes it impossible.. other than FDO's tactical neglect?
EDIT: Actually, I dimly recall some old hardware that I think was supported by DRM that did tiled rendering. Maybe it was some PowerVR stuff? If my memory isn't failing me, then there's the counter to claims that it's impossible for xorg to support. :P
[0] Source: Me having these work just fine for quite a long time now on my personal machines that run xorg.
> Hopefully xlibre will be adding that in.
You will also need toolkits/games to add support for any additional protocol, which I doubt they will.
> It's not entirely clear what you're talking about with the third
Zero-copy video means you can play vides in web pages hardware accelerated and have no copy of the video frame required to send it to the display. This saves a lot of power.
> it's "just" a matter of writing the drivers to make it happen and getting them into an xorg fork
Compositing with Xorgs model and applying any kind of screen effect would be extremely painful on tiling GPU because of how the screen is passed back and fourth to the compositor. Given compositing in Wayland compositors is passive, it does not have that issue.
Notice how Wayland on the RPi had performance that it simply couldn't gain under Xorg.
> Me having these work just fine for quite a long time now on my personal machines that run xorg
Good for you. But we have modern hardware and demands that simply Xorg doesn't meet and the protocol is archaic that adding support isn't worth it.
> and of course nothing would run on BSDes
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.
> Wayland is only a protocol. Whoever wants to support it can.
I'm kinda tired of this line that I see everywhere. The bottom line is that most people develop for Linux, and don't consider the BSDs, and so things end up broken, or not working at all. The popular libraries for writing Wayland compositors consider Linux first, and BSD support is bolted on later.
The end result is that it's just more work for everyone. X11 could have been fixed, it's just no one wanted to do so in time to head off the Wayland work. XLibre and Phoenix might have ended up working out if they'd been started 10-15 years ago, but Wayland has too much momentum now, for better or worse.
(Source: I am a Wayland compositor maintainer who would love it if his stuff would work on the BSDs, but I don't have the time or energy to install a BSD and test and fix.)
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.
> i agree about the loss of flexibility
The maintainer of Phoenix puts it very well[0]:
> The main issue with Wayland is not a technical one but in its philosophy. X11 is "mechanism over policy" while Wayland is "policy over mechanism".
[0] https://git.dec05eba.com/phoenix/about/
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.
> It's a shame xlibre didn't come around sooner
Xorg team had accepted Enrico's patches then did not release them. Classic saboteur handbook stuff
There were years where, to my understanding, they were deliberately not accepting features or patches to push Wayland, which is kind of frustrating, because it misses the point of a competitive ecosystem. Like on one hand if they're deliberately sabotaging Xorg for Wayland it implies Wayland must actually be a lot better, but on the flip side if Linus had sabotaged linux in favor of seL4 we'd all be worse off, even though kernel engineers often regard microkernels as a "better architecture".
> course nothing would run on BSDes
Ummmm, Wayland runs on FreeBSD...
https://docs.freebsd.org/en/books/handbook/wayland/
[flagged]
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
Lol, we don't talk about xlibre here. Announcments and reviews are banned.
Waiting for dang to argue the 7th time that is not somehow his personal decision to ban xlibre that he's set up a system where a couple of nazis with automated scripts can hide an article which requires his manual attention to put (which he doesn't do)
who care about political affiliation when software is done right? Opensource is Political neutral.
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.
Probably take more than $100k, X11/Wayland is a bit more complicated than the usual bit of software.
Likely, but more the point I'm making is we're now approaching a point where this kind of issue is solvable with resources in reach of a small company / wealthy individual.