I have a ThinkPad T60 that I still use for a most of my personal tasks. X works fine. Wayland doesn't. Nobody involved with Wayland development seems to care. That's fair enough, but I see no reason to throw out a working device that runs fine with Slackware 15 just because the only display server that supports it is X.
To be honest as a mere user Wayland just works. But I had experienced some odd situations that received no attention whatsoever. While with X there was plenty of attention over these details, I do think it was honed over years of inefficiency on the Linux desktop.
I don't see any alternative in sight and can't seem to see a way back to X at all.
I have never had any problems whatsoever with X. Switching to wayland for a couple days however and everything went to the gutter, text in in most application was pixelated, had to go against the wave because I have an nvidia GPU and had to install an unnecessary amount of other things just to be able to share my screen.
Ubuntu even tried to switch to wayland two times and had to revert their decision.
I'm not really sure how people in their right mind say wayland is good. Maybe I'm just doing something wrong here, but the experience of installing and forgetting is non existent with wayland, it feels like a clunky experimental wannabe X alternative.
Mind you, this was a couple months ago on arch Linux with sway.
Of course GNOME would work well: GNOME has dedicated Nvidia management code that was deliberately left out of Wayland and wlroots codebases. The only reason that someone would do this is to bait people into using their "more complete" desktop. This is why Wayland is failing.
I really like this article, particularly this point:
> Wayland's lack of feature parity with Xorg cripples it.
This is something I've bible-thumped Wayland advocates over for years. wlroots is dead-on-arrival in the eyes of smaller DE/WM devs. Nobody wants to update their entire system's display server, and then be forced to rewrite entire portions of userland and the OS just to get their desktop working similarly as it was on Xorg, with less hardware support.
That's a problem. It's something that Wayland advocates will defend as "a work in progress", but when is that work due? Wayland has been in development for nearly 10 years now, and with each passing year it increasingly feels like this is a scam designed to bootstrap the Mutter shell. Face it: Sway works but it's hardly a DE, and KDE is functional on specific hardware and lacks several features. Wayland is a failure for everyone but the GNOME foundation, who I think intended this as a power-grab. In reality, we're left with an XKCD-worthy "two competing standards" situation.
People often cite a fractured desktop as the reason why Linux never takes off. Well, it's projects like Wayland that cause the worst fractures. We were promised a better Display Server, and what we got doesn't even compete with what we had in MacOS Sierra. I hate to be vitriolic towards software, but it's really pathetic.
Once you realize that Wayland is essentially a GNOME project, it will all make sense. Take for example how windows have to draw their own decorations. That's a GNOME-ism.
If Wayland is the future of the Linux desktop, it would seem that there will be one true reference compositor (GNOME's Mutter) with a number of other projects struggling to adapt to the various gaps left by Wayland's incompleteness.
For example, screen sharing on Zoom works with GNOME Wayland but not the other compositors because it targets a GNOME API. If the Linux desktop starts to fracture, what's the incentive to bring support to your less common WM/compositor?
Yes!!! So many people are utterly oblivious to this, and the number of people I see trying to defend this as a "community project" worries me. Make no mistake: Wayland (much like GTK4 and libadwaita) is another piece of software designed to give the GNOME foundation leverage. Perhaps the insult to the injury is that even with ownership of large components of desktop Linux, the GNOME foundation refuses to create a complete desktop.
Not only Wayland and GTK, but systemd, flatpak and basically all "standards" shipped from freedesktop.org, mainly sponsored by one company: Red Hat.
The problem is not only people think on these projects like "community projects", but the developers that build software upon GTK and the GNOME stack, because they know GNOME Foundation doesn't not care about 3rd party devs.
The "big desktop" concept always felt a little weird to me-- derived from the era where we people freaking out about the license status of KDE/Qt and using that to justify the entire GNOME ecosystem.
It's completely unlike the traditional Unix/X11 model-- here's an entire suite of toolkits and software, and you can pick best-of-breed. If you want to style it all to look similar, tooling exists. If you want your word processor to follow GTK conventions and your web browser to look like Motif, more power to you.
I feel like the original "desktop" model was to provide a basic subset of software with a consistent look and feel-- more or less getting you to feature-parity with the pack-in software in a Windows 95 install. It's realistically the upper bound on what can be offered.
If you go bigger-- as GNOME is doing by hitting the windowing infrastructure itself-- you're asking to support and rebuild the entire world in your image. You also create a hostility with the rest of the universe. I've tended to avoid GNOME/KDE related utilities because I don't want to turn "oh, here's one cool package I want" into 45 minutes of pulling an entire desktop environment down to support it. And that's with abundant resources to spare-- if I was fitting stuff on a first-generation Raspberry Pi with a tiny storage card, it's a complete showstopper.
The main problem with Wayland is not technical but political.
It follows the same forced adoption tactics than systemd.
People don't use it because it lacks many features compared to X and other implemented features do not work as good as on X.
So what do they do? They make Wayland, which is incomplete and beta quality, the default graphic engine of GNOME, which is the default desktop environment of 90% of Linux distributions.
And when people complain about this, the only thing they say is X is dead, Wayland is the future.
IMO application sandboxing is very important, something that everyone should be able to take for granted in 2022. But the right approach is usually virtualization. If you omit functionality that people want, they come up with an (insecure) workaround and the workaround becomes required for common applications to work. If you deny requests by a program when policy does not permit them, by laziness or malice applications will require excessive permissions to function, and users will comply to get their apps working. Instead, every API must appear to be working to the greater extent possible, but sandbox all important effects and coeffects by default. So eg attempting to screen share from a program not authorized to do so either (a) prompts the user what to share or (b) shows an empty desktop with just that program.
There's two schools of thought regarding high DPI displays, the Apple way, and the Windows way.
The Apple way tries to make the DPI change transparent to the application, resizing behind the hood when necessary, and only using integer scales, requiring increased-size assets that are used on-demand.
Windows allows the program to opt into handling the high DPI by itself, obviously producing precise behavior in that case. For compatibility, it will either scale smaller windows up framebuffer-wise, or increase the font size, using the limited resolution independence it has had from the beginning.
In the end, Windows' behavior turned out to be less error-prone. For a little while it seemed like it would be a disaster, pushing the onus onto the developers, but it turned out fine in the end. Personally, I didn't think just making a clean separation like that was the right idea, but I was proven wrong.
Wayland uses the MacOS approach. It allows the program to provide increased resolution buffers at integral scales. This forces fractional scales into framebuffer scaling. The application can't output at a pixel-precise level.
In X11, both of the popular toolkits, Gtk and Qt, simply take the DPI provided and draw widgets bigger, kind of like Windows. It isn't perfect. For example, Gtk only really "supports" integral scales, but themes have been doing dynamic resizing forever, so tweaking the DPI can get perfect fractional sizing aside from some line widths. Older theme engines on Qt might also have a few glitches. But I'm convinced this is definitely the way to go. You're not hiding the fractional DPI from the program. It can be as sharp as it wants.
> Wayland uses the MacOS approach. It allows the program to provide increased resolution buffers at integral scales. This forces fractional scales into framebuffer scaling.
There is work underway[0] to implement a protocol (wp-fractional-scale-v1) to support fractional scaling as well, which in combination with wp-viewport will allow fractional scaling without framebuffer scaling. Experimental support exists in wlroots, sway, kwin (KDE), and Mutter (GNOME).
I still find myself reflexively mistrustful of Wayland because there's no real multi-OS implementation. Apart from some Steam games, there's nothing tying me to Linux as opposed to e.g. OpenBSD.
23 comments
[ 3.0 ms ] story [ 60.8 ms ] threadI don't see any alternative in sight and can't seem to see a way back to X at all.
Ubuntu even tried to switch to wayland two times and had to revert their decision.
I'm not really sure how people in their right mind say wayland is good. Maybe I'm just doing something wrong here, but the experience of installing and forgetting is non existent with wayland, it feels like a clunky experimental wannabe X alternative.
Mind you, this was a couple months ago on arch Linux with sway.
Better to test with a WM that's more compatible, even GNOME would work better in your scenario.
> Wayland's lack of feature parity with Xorg cripples it.
This is something I've bible-thumped Wayland advocates over for years. wlroots is dead-on-arrival in the eyes of smaller DE/WM devs. Nobody wants to update their entire system's display server, and then be forced to rewrite entire portions of userland and the OS just to get their desktop working similarly as it was on Xorg, with less hardware support.
That's a problem. It's something that Wayland advocates will defend as "a work in progress", but when is that work due? Wayland has been in development for nearly 10 years now, and with each passing year it increasingly feels like this is a scam designed to bootstrap the Mutter shell. Face it: Sway works but it's hardly a DE, and KDE is functional on specific hardware and lacks several features. Wayland is a failure for everyone but the GNOME foundation, who I think intended this as a power-grab. In reality, we're left with an XKCD-worthy "two competing standards" situation.
People often cite a fractured desktop as the reason why Linux never takes off. Well, it's projects like Wayland that cause the worst fractures. We were promised a better Display Server, and what we got doesn't even compete with what we had in MacOS Sierra. I hate to be vitriolic towards software, but it's really pathetic.
If Wayland is the future of the Linux desktop, it would seem that there will be one true reference compositor (GNOME's Mutter) with a number of other projects struggling to adapt to the various gaps left by Wayland's incompleteness.
For example, screen sharing on Zoom works with GNOME Wayland but not the other compositors because it targets a GNOME API. If the Linux desktop starts to fracture, what's the incentive to bring support to your less common WM/compositor?
The problem is not only people think on these projects like "community projects", but the developers that build software upon GTK and the GNOME stack, because they know GNOME Foundation doesn't not care about 3rd party devs.
It's completely unlike the traditional Unix/X11 model-- here's an entire suite of toolkits and software, and you can pick best-of-breed. If you want to style it all to look similar, tooling exists. If you want your word processor to follow GTK conventions and your web browser to look like Motif, more power to you.
I feel like the original "desktop" model was to provide a basic subset of software with a consistent look and feel-- more or less getting you to feature-parity with the pack-in software in a Windows 95 install. It's realistically the upper bound on what can be offered.
If you go bigger-- as GNOME is doing by hitting the windowing infrastructure itself-- you're asking to support and rebuild the entire world in your image. You also create a hostility with the rest of the universe. I've tended to avoid GNOME/KDE related utilities because I don't want to turn "oh, here's one cool package I want" into 45 minutes of pulling an entire desktop environment down to support it. And that's with abundant resources to spare-- if I was fitting stuff on a first-generation Raspberry Pi with a tiny storage card, it's a complete showstopper.
It follows the same forced adoption tactics than systemd.
People don't use it because it lacks many features compared to X and other implemented features do not work as good as on X.
So what do they do? They make Wayland, which is incomplete and beta quality, the default graphic engine of GNOME, which is the default desktop environment of 90% of Linux distributions.
And when people complain about this, the only thing they say is X is dead, Wayland is the future.
The Apple way tries to make the DPI change transparent to the application, resizing behind the hood when necessary, and only using integer scales, requiring increased-size assets that are used on-demand.
Windows allows the program to opt into handling the high DPI by itself, obviously producing precise behavior in that case. For compatibility, it will either scale smaller windows up framebuffer-wise, or increase the font size, using the limited resolution independence it has had from the beginning.
In the end, Windows' behavior turned out to be less error-prone. For a little while it seemed like it would be a disaster, pushing the onus onto the developers, but it turned out fine in the end. Personally, I didn't think just making a clean separation like that was the right idea, but I was proven wrong.
Wayland uses the MacOS approach. It allows the program to provide increased resolution buffers at integral scales. This forces fractional scales into framebuffer scaling. The application can't output at a pixel-precise level.
In X11, both of the popular toolkits, Gtk and Qt, simply take the DPI provided and draw widgets bigger, kind of like Windows. It isn't perfect. For example, Gtk only really "supports" integral scales, but themes have been doing dynamic resizing forever, so tweaking the DPI can get perfect fractional sizing aside from some line widths. Older theme engines on Qt might also have a few glitches. But I'm convinced this is definitely the way to go. You're not hiding the fractional DPI from the program. It can be as sharp as it wants.
There is work underway[0] to implement a protocol (wp-fractional-scale-v1) to support fractional scaling as well, which in combination with wp-viewport will allow fractional scaling without framebuffer scaling. Experimental support exists in wlroots, sway, kwin (KDE), and Mutter (GNOME).
[0] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...