At this point I don't know who it is for, but it's not for users.
wayland doesn't have that need.
All on X, though. I appreciate the principles behind Wayland, but sadly not the implementation.
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.
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 :'(
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.
30 years ago, a client shouldn't crash the server. Yes, things evolve ...
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-...
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_...>
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 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.
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.
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.
There's thousands of Linux distros. I'd assume most of them are not super close to the Wayland folks.
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.
They are a big Monty Python fan. Wait, you meant frame ?
Not annotating when you yourself are screen sharing, but when someone else is screen sharing you can draw on their screen(aka annotating)?
If I were to switch to Wayland and have to go back to the webapp for Zoom, that would be annoying.
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:
media.ffmpeg.disable-software-fallback=true
media.ffmpeg.vaapi.enabled=true
media.gmp.decoder.enabled=false
media.gpu-process-decoder=true
media.gpu-process-encoder=true
media.hardware-video-decoding.force-enabled=true
media.hardware-video-encoding.force-enabled=true
media.webrtc.hw.h264.enabled=true
media.webrtc.software_encoder.fallback=false
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.
They're a mess everywhere for legal reasons. The solution is what Chrome and many other apps do: just ship codecs with the app.
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.
Not if you install Chrome, Brave, Vivaldi, etc... like most users...
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...
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...
Sorry, my earlier posts were all talking about hardware decoding, so I had assumed that it was implied that I was talking about hardware decoding in this reply too. But I see that I never actually mentioned that anywhere, so my bad.
- 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
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.
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.