Live data from Hacker News

Can I start using Wayland in 2026?

michael.stapelberg.ch

31–40 of 335 posts

Re: Can I start using Wayland in 2026?

#31
post #2

A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinven…

X.org picked the right level of abstraction (even if implementation could use a rewrite). No WM should care about handling raw inputs or forced to be proxy between driver and the app for the output (it could be, if it needed/wanted, but there is no reason to add another layer of abstraction and cycle-wasting for most use cases). And it shows in complexity and even in power use. Wayland basically failed to learn the l…

That's easy to say in hindsight. It is only with the specific failures of Wayland that we see which lessons it could have learned from X11.

Re: Can I start using Wayland in 2026?

#32
2026 is starting with half-baked NVidia drivers and missing functionality on linux? I am so surprised... did you try 17 different previous versions to get it running in true NV-Linux fashion?

This stuff has been flawless on AMD systems for a while a couple of years now, with the exception of the occasional archaic app that only runs on X11 (thus shoved in a container).

Re: Can I start using Wayland in 2026?

#33
At this point the primary thing that's keeping me from switching to Wayland (KDE) is lack of support for remote desktop software, especially with multiple monitors...

Hopefully AnyDesk and Remmina will address this issue before KDE ends it's mainline X11 support next year.

Re: Can I start using Wayland in 2026?

#34

I still don't know why I would want to use it. The benefits don't seem to outweigh the costs yet, and xorg is tried and true. So many Linux articles and forum posts about fixing problems with your desktop graphics start with "If you're using Wayland, go back to xorg, it'll probably fix the problem you're seeing." You don't always have to replace something that works with something that doesn't but is "modern." My gue…

I have essential workflows using x2x, xev, and xdotool. Apparently this kind of stuff is contrary to Wayland's security model, so I'm stuck on Xorg, and I'm ok with that.

Re: Can I start using Wayland in 2026?

#36

Earlier quoted context omitted.

I think then big part is maintenance, xorg doesn't look likely to be maintained long into the future in the way Wayland will be. And a lot of the Xorg maintainers are now working in Wayland. So good or bad idea, Wayland is slowly shifting to being the default in virtue of being the most maintained up to date compositor.

There's actually a very active fork of Xorg called Xlibre, started by a former Xorg contributor, which seeks to "revitalize and modernize" X: https://github.com/X11Libre/xserver?tab=readme-ov-file

This guy started that Xlibre fork over throwing a fit because he was told not to break Xorg with his contributions, and he ranted that he just wants to be able to merge whatever he wants. I would not trust the stability of that fork at all.

Re: Can I start using Wayland in 2026?

#37
post #29

I've been using Wayland (wlroots/swaywm) for a few years now and it's been flawless, even with an eGPU. But I'm also running all AMD hardware, that may be a factor. Life is too short for nvidia bullshit on Linux.

I am the same, now. But I did have it working previously on Nvidia and it was good enough. I’ve also used the TILE patch at work and that seemed pretty good on the 5k screens they have there.

I switched to get support for different scaling on different outputs and I have gone back.

Re: Can I start using Wayland in 2026?

#38
My experience is very similar. Just today, I was trying Wayland again but it didn't work out.

One of the obstacle that I faced is wrong resolution. On Xorg I could just add new mode and get up and running quickly. On Wayland, I have to either do some EDID changes or go through even worse.

Re: Can I start using Wayland in 2026?

#39
post #2

A rather big problem is that Wayland is just a protocol, not an implementation. There are many competing implementations, like Gnome, KDE and wlroots. The problems you have with one of them might not appear in another. The reference compositor, Weston, is not really usable as a daily driver. So while with Xorg you have a solid base, and desktops are implemented on top of that, with Wayland the each desktop is reinven…

> The problems you have with one of them might not appear in another. Because both have their own portal implementation/compositor with their own issues and service spec implementations. KDE has xdg-desktop-portal-kde, and GNOME has xdg-desktop-portal-gnome. On top of that each (still) has their own display server; KDE has KWin, and GNOME has Mutter. > The reference compositor, Weston, is not really usable as a daily…

The fact that we need the entire xdg-desktop-portal stack for screen sharing on browsers is a major annoyance. We now have a standardised extension for screencasting and screencopy (formerly it was not standard, but had been around for years), but browsers only support the Flatpak stack, which has a lot of moving parts and IPC. Doing out-of-band IPC for this is kind of pointless when the client and the server already have a Wayland connection to begin with.

Outside of the domain of Firefox/Chromium, screencasting is much seamless. But 90% of the screen-sharing happens in browsers.

Re: Can I start using Wayland in 2026?

#40
>nVidia refused to support the API that Wayland was using, insisting that their EGLStreams approach was superior

This is a common mischaracterizarion of what happened. This API, GBM, was a proprietary API that was a part of Mesa. Nvidia couldn't add GBM to their own driver as it is a Mesa concept. So instead Nvidia tried to make a vendor neutral solution that any graphics drivers could use which is where you see EGLStreams come into the picture. Such an EGL API was also useful for other nonwayland embedded usecases. In regards to Nvidia's proprietary driver's GBM support, Nvidia themselves had to add support to the Mesa project to support dynamically loading new backends that weren't precompiled into Mesa. Then they were able to make their own backend.

For some reason when this comes up people always phrase it in terms of Nvidia not supporting something instead of the freedesktop people not offering a way for the Nvidia driver to work, which is a prerequisite of Nvidia following such guidance.

Post reply on HN