All of this hassle, forcing so much more work on DE/WM devs, for the sake of 'better security' in scenarios that don't really apply to 99% of linux users, with the promise of 'better latency' which this very article proves is false.
I tried to be an early adopter of wayland ~ 5 years ago. Found all sorts of things broken, and I'm now using linux mint xfce edition, as hopefully by the time xfce drags itself to wayland, all the bugs and tooling will be a solved problem.
Linux is about choice, but unless you're ready to write a lot of things yourself, it's outside your control how well parts of the ecosystem are supported. For an average user it's unacceptable for your entire GUI to suddenly change in a way that requires relearning, something that Mac and Windows have avoided doing at least since 2000. Even Win8 or Mac26 wasn't so disruptive. It's possibly worse for an average Linux user because they aren't just concerned with how it looks but also compatibility with advanced things like X forwarding or VNC or CRD.
It however isn't about all or indeed any of those devs being obligated to support any particular choice. You can only buy a place at the table with money or sweat and merely using something isn't contributing and doesn't get you a vote.
Arguably the problem isn't the display server its the fact that general linux usage tends to require a little understanding of what's going on under the hood than is strictly speaking desirable for joe average user especially when something doesn't work. EG needing to understand that your choice of display server is making your zoom calls not work and then having to open that whole can of worms.
The fix is honestly more labor. The trivial way to acquire more labor is with money which is hampered by the fact that so little is paid. If you want more polished stuff pay more.
No. If you tell users they should switch to a new display server, you shouldn't be surprised if no one takes you up on it if you don't provide basic feature parity.
If you tell DE/WM devs they should use your new protocol, but say it's now their responsibility to do all these things that the old display server did for them, don't be surprised if it doesn't get much traction.
I don't for the life of me understand why wayland took off. It's provided no benefit to the average user, or DE/WM dev, and a whole lot of hassle.
Yeah, because it wasn't ready. Pretty much no one recommended using it back them, if you thought it was ready you were either misguided or misled. It's time to put your skepticism aside and give it another try, there is a pretty good chance it's going to work great now.
Even Valve Steam OS is now adopting it. It's a pretty good sign wayland is a viable replacement for X11, while bringing it own things.
It is completely counterfactual that "pretty much no one" was recommending it in 2021
Fast forward to 2021 and most users experience with wayland was that GDM (on some distros) would try to start on wayland mode but couldn't for some reason and would fallback to X11. Note: I do think that the distros that were pushing for this were being reckless with their users. Introducing it as an opt-in would be much better and would still lower the barrier for testing. Also, KDE didn't even offer a wayland mode, taking until 2024 for it to start defaulting to it and any other wayland desktop had to be sought after by the user.
So really, I think people only started to "suffer" wayland's wonky-ness for the last three to five years depending how you view it. And honestly the last year or two has been pretty usable.
- Effort spent writing sway that could have been spent improving i3
- Effort spent writing GNOME-Wayland that could have been spent improving GNOME
- Effort spent writing KDE-Wayland that could have been spent improving KDE (much of this work duplicated effort with GNOME-Wayland)
- Effort spent writing wlroots to try and mitigate the effort being wasted by people writing bespoke compositors
- Wine/Proton devs needing to waste time getting every windows application to work in Wayland
- Firefox needing to target both Wayland and X
- A bunch of graphical toolkits and window managers that were working perfectly fine but will now be "left behind" since they lack the maintainers to support a porting effort
- low-level toolkits like SDL needing to implement their own window decorations now that they're not guaranteed to be provided by the OS (what?!)
What Wayland proves to me is just how easy it is for a small number of developers to unintentionally sabotage productivity in a much larger project.
It's the epitome of science, comparing it to a generic vim vs emacs flamewar which is pure subjective opinion is pretty baseless.
It’s like going from 240Hz back to 60Hz, or even 240Hz to 120. People can tell.
There is a native Wayland driver for Wine/Proton but it's enabled through an environment variable, not by default. This will probably be default in Wine 12/Proton 12 because Valve wants to squeeze as much performance out of SteamOS as possible. The gaming mode UI runs under Valve's own Wayland compositor (gamescope) already, but games are currently in nested XWayland windows.
It has been ready for users whose sole usage is an editor a terminal and a browser on their single screen intel laptop as long as they didn't also open youtube since 2015.
Imagine the boss's nephew joins the firm. He knows less than nothing and is worse than useless everything he touches turns to shit. People understandably complain. After 10 years of development and other people's time he is now moderately capable at his job. People still bitch. They aren't lying or wrong. They just aren't current.
which is still half a frame at best so I think any blame here would be just on a particular game being slow on inputs
Only xwayland showed that result. The difference was only a couple milliseconds. That’s in the range where I start to doubt that people are feeling the latency difference. If it was 10-20ms I could believe it, but not when it’s a couple milliseconds.
The author of this post did a good job of getting all of the other confounding settings out of the way. It’s possible that the people complaining that Wayland was slow were starting from an unoptimized situation and as part of switching to some low latency variant they set all the correct settings.
A better way to interpret this data is to normalize by the vsync interval or the swap chain depth. The slowest config is 2 frames slower than the fastest. At 500Hz this is 4ms extra which is likely imperceptible to everyone but elite pro gamers. At 60Hz this is 34ms extra which is pretty noticeable to even casual gamers.
I certainly want my latency as low as I can get it. But I'm pretty skeptical that anyone is truly feeling the difference of a couple ms.
We notice latency. Neil Peart could almost get sample-precise timing, he was so godlike.
But I wouldn't necessarily say that people can notice it everywhere in every state of mind. The medium, context etc all matter a lot.
Compositing requires the GPU to do some extra work to draw the frame to be presented. This typically takes very little time (much less than a full frame period). Additionally, most wayland compositors will bypass that extra step if an application is full screen (wlroots calls it "direct scanout").
Also some wayland compositors keep track of timing and delay the final composition until right before it is time to present the frame in order to reduce latency.
What's probably happening is that other wayland compositors are slower than KDE Plasma wayland which he tested. And people report that experience. Some other wayland compositors might even be faster than plasma. But what is for sure is that every wayland is very different from every other wayland.
In any case the methodology in the post is sound and should be used for benchmarking in the future.