Three signs that Wayland is becoming the favored way to get a GUI on Linux(theregister.com)
theregister.com
Three signs that Wayland is becoming the favored way to get a GUI on Linux
https://www.theregister.com/2023/07/13/wayland_is_coming/
71 comments
It's a pain because of how much legacy content is made to target Xorg and that there isn't just one central authority or toolkit. You have decades of applications and dozens of toolkits that speak to the X Window Server.
Unlike Windows and macOS, where you link agaisnt the system toolkits, so when Microsoft/Apple want to change their protocol, they update these toolkits.
Any protocol that wasn't X on Linux is always going to be a pain to replace, the biggest issue with Wayland adoption is that it isn't X, yet X is not appropriate for how modern graphics works (why Android does not use it, and uses a system similar to Wayland).
Edit: To add on, regarding things like emulated input etc, on other operating systems there are usually standardised protocols for doing this, where on X it just allowed anything (you don't want windows reading the input sent to other windows, think banking). So new protocols have to be invented here, and then support added for them, in many cases the protocol also works on X with an updated window manager/compositor.
Unlike Windows and macOS, where you link agaisnt the system toolkits, so when Microsoft/Apple want to change their protocol, they update these toolkits.
Any protocol that wasn't X on Linux is always going to be a pain to replace, the biggest issue with Wayland adoption is that it isn't X, yet X is not appropriate for how modern graphics works (why Android does not use it, and uses a system similar to Wayland).
Edit: To add on, regarding things like emulated input etc, on other operating systems there are usually standardised protocols for doing this, where on X it just allowed anything (you don't want windows reading the input sent to other windows, think banking). So new protocols have to be invented here, and then support added for them, in many cases the protocol also works on X with an updated window manager/compositor.
You can run Xorg applications on Wayland via XWayland.
The experience is very straightforward, you run the application and it show up as a regular window. There's no tinkering or setup required.
I run Steam and many games. Only ONE game natively runs on Wayland (factorio), the others all use XWayland and work fine.
The experience is very straightforward, you run the application and it show up as a regular window. There's no tinkering or setup required.
I run Steam and many games. Only ONE game natively runs on Wayland (factorio), the others all use XWayland and work fine.
XWayland on Nvidia is still poo, but it's a complicated issue with no easy fix, that isn't a problem with Wayland itself.
No. The Wayland design is crap through-and-through. To a large extent it was intentionally meant to break things, what with its insane security model ideas.
It's not just a matter of "getting the wrinkles ironed out".
It's not just a matter of "getting the wrinkles ironed out".
Do you even know anything about the Wayland design?
Wayland is more about just getting surfaces from A => B and management of those surfaces, it doesn't really do anything shockingly different from how something like macOS does it.
Wayland is more about just getting surfaces from A => B and management of those surfaces, it doesn't really do anything shockingly different from how something like macOS does it.
macOS actually works when I try to use it though. Wayland always has huge issues. What explains that?
Try reading my original comment, it explains it perfectly.
That tiny billionaire dollar company backing it?
What is crappy about the design?
Not a success? It's now the default on most biggest Linux distros like Ubuntu and Fedora.
The tiling WM ecosystem in particular is thriving on Wayland with sway and hyprland, and I personally haven't had any issues with screen recording with OBS (I use hyprland).
Most of the stuff said in the list you linked is "said-X11-only software is not compatible with Wayland" but nothing is said about alternatives : for example instead of redshift I use gammastep.
The tiling WM ecosystem in particular is thriving on Wayland with sway and hyprland, and I personally haven't had any issues with screen recording with OBS (I use hyprland).
Most of the stuff said in the list you linked is "said-X11-only software is not compatible with Wayland" but nothing is said about alternatives : for example instead of redshift I use gammastep.
As "just a user" in terms of using Linux as a DE, I personally had no gains, just losses.
For example, I wanted to create a tool to use my old smartphone as a trackpad. After a short time I realized my approach won't work on wayland. I started delving in the available options, /dev/uinput, libevdev etc., and realized it will be to much pain. No (generic) accessibility¹ support means no generic way to do that, and just for my setup it is too much work.
So I dropped that. Then I have a set of tools I use for quite some time, amongst which are AnyDesk, TeamViewer, Blue Recorder, Steam. These either don't work, work only with wlroots, or work via the X11 shim.
¹ for me just a nuisance, for all the people who really need accessibility support, well ...
For example, I wanted to create a tool to use my old smartphone as a trackpad. After a short time I realized my approach won't work on wayland. I started delving in the available options, /dev/uinput, libevdev etc., and realized it will be to much pain. No (generic) accessibility¹ support means no generic way to do that, and just for my setup it is too much work.
So I dropped that. Then I have a set of tools I use for quite some time, amongst which are AnyDesk, TeamViewer, Blue Recorder, Steam. These either don't work, work only with wlroots, or work via the X11 shim.
¹ for me just a nuisance, for all the people who really need accessibility support, well ...
> I personally had no gains, just losses.
Depends.
Screen tearing gets worse at higher refresh rates and resolutions under Xorg.
Additionally fractional scaling and mixed DPI's are something Xorg was having great difficulty supporting.
It also gets quite slow (high CPU and especially memory transfers) at high refresh rates and resolutions; I mean, you benefit from this without noticing.
You'll notice a loss in functionality (like screen recording) much more than you'll see a benefit like "this will actually work at 8k 120Hz"; but it's not true that there's no gains.
Wayland is fine, it fixes a lot of legacy that holds the ecosystem back, people don't like it overwhelmingly because changing esoteric and hacky software that is core to basically everything will be difficult and take time.
It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
Depends.
Screen tearing gets worse at higher refresh rates and resolutions under Xorg.
Additionally fractional scaling and mixed DPI's are something Xorg was having great difficulty supporting.
It also gets quite slow (high CPU and especially memory transfers) at high refresh rates and resolutions; I mean, you benefit from this without noticing.
You'll notice a loss in functionality (like screen recording) much more than you'll see a benefit like "this will actually work at 8k 120Hz"; but it's not true that there's no gains.
Wayland is fine, it fixes a lot of legacy that holds the ecosystem back, people don't like it overwhelmingly because changing esoteric and hacky software that is core to basically everything will be difficult and take time.
It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
You're right and I don't debate any of your points. And no it doesn't shock me that big distros use Wayland already.
On the other hand, my points still stand I think. And regarding esoteric and hacky software: I don't think accessibility as a base functionality should require hacky and esoteric stuff, it should be a first class citizen in a 2023 window manager (?).
And I also want to remind how Linux (and, ironically, Microsoft) grew so strong: they are really, really careful with deprecating old stuff. As hacky that stuff may be. Up for debate if this is net good, sure.
On the other hand, my points still stand I think. And regarding esoteric and hacky software: I don't think accessibility as a base functionality should require hacky and esoteric stuff, it should be a first class citizen in a 2023 window manager (?).
And I also want to remind how Linux (and, ironically, Microsoft) grew so strong: they are really, really careful with deprecating old stuff. As hacky that stuff may be. Up for debate if this is net good, sure.
> it should be a first class citizen in a 2023 window manager
It should be, but linux is built by hobbyists in their free time — it is hard enough to get to a working state, let alone adding accessibility, even if it is the first on the list.
It should be, but linux is built by hobbyists in their free time — it is hard enough to get to a working state, let alone adding accessibility, even if it is the first on the list.
Screen tearing is a function of the device driver, it's not inherent to X11.
> Screen tearing gets worse at higher refresh rates and resolutions under Xorg.
No, it gets better, the same as aliasing does with higher resolution. That, and VRR hardware in the monitor, are the correct way to fix tearing in this day and age. V-sync is kludgey false dharma.
> It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
Sure, but it might shock you how much smoother your desktop can be if you disable compositing (on X, anyway). Many never have, and you can't in GNOME (of course). ;D I'm not sure if Wayland supports that in itself, however.
No, it gets better, the same as aliasing does with higher resolution. That, and VRR hardware in the monitor, are the correct way to fix tearing in this day and age. V-sync is kludgey false dharma.
> It might shock you to know though that GNOME and Fedora users are already using Wayland on the popular distros, the transition was completely seamless for those users.
Sure, but it might shock you how much smoother your desktop can be if you disable compositing (on X, anyway). Many never have, and you can't in GNOME (of course). ;D I'm not sure if Wayland supports that in itself, however.
You'll probably going to ned to look at using libei
https://gitlab.freedesktop.org/libinput/libei
https://gitlab.freedesktop.org/libinput/libei
Thanks, looks interesting!
If you want to create a tool to use your smartphone as a trackpad, this is the protocol that you're looking for: https://wayland.app/protocols/wlr-virtual-pointer-unstable-v...
It's only a wlroots protocol for now, and I won't deny that this is definitely one of the fields that still need some more refinement/stabilisation.
It's only a wlroots protocol for now, and I won't deny that this is definitely one of the fields that still need some more refinement/stabilisation.
Exactly and the assertion that it's 'very well designed' needs examining - maybe there's a reason there's been such slow adoption.
The reasons are no mystery. As a sibling to your comment said, many programs have been written as if X was going to exist forever, with direct calls to X all over the place. Plus X is mature with a million accumulated bug-fixes, so naturally it takes time to produce a reasonable contender.
Also X works with the leading GPU manufacturer. Wayland does not.
Adoption and "well designed" have never had any correlation, historically speaking.
Inertia to change, marketing, and making good business deals and have almost always been the more important factors for adoption of any technology in the past decades.
Inertia to change, marketing, and making good business deals and have almost always been the more important factors for adoption of any technology in the past decades.
Wayland was created in 2008 and has afaik never supported and still doesn't support anything other than 3x8 bit implicit sRGB graphics.
It does support a lot of other formats. Here's a brief list: https://wayland.app/protocols/wayland#wl_shm:enum:format
There's plenty of formats that are more than 3x8 bit.
There's also been a lot of work recently in getting HDR through (also this requires work in other parts of the Linux graphics stack too).
There's plenty of formats that are more than 3x8 bit.
There's also been a lot of work recently in getting HDR through (also this requires work in other parts of the Linux graphics stack too).
Just because it's been 15 years and it hasn't reached 100% adoption/parity doesn't mean it's not a success. The feeling around it when it started was that it's going to many many years for it to reach that and I'd say it's en route.
I don't understand the criticism Wayland gets. If you don't like it just don't use it. X.org is fine. Wait for it to get the features/quality you expect.
Wayland people _are_ the X.org people. You can't force them to continue developing a technology they don't believe it and not moving forward.
I don't understand the criticism Wayland gets. If you don't like it just don't use it. X.org is fine. Wait for it to get the features/quality you expect.
Wayland people _are_ the X.org people. You can't force them to continue developing a technology they don't believe it and not moving forward.
I just disabled Wayland on Fedora 38 because of a bug where no videomode is set after login with GDM or switching TTYs. Basic Intel graphics, no proprietary drivers, all stock configs. I'll have to ssh in and purge/reinstall everything, I suppose.
Wayland has caused me no other issues, and while Xorg does hold a special place in my heart, it made me chuckle a bit when I realized I'd become the equivalent of the old-timer still skeptical that ext4 is ready for primetime.
Wayland has caused me no other issues, and while Xorg does hold a special place in my heart, it made me chuckle a bit when I realized I'd become the equivalent of the old-timer still skeptical that ext4 is ready for primetime.
They thought they could ignore Nvidia because open source and it turns out they couldn’t.
Ignoring Nvidia?
Nvidia has been plumbing support for the APIs Wayland display servers typically use into their driver, not the other way around.
Nvidia has been plumbing support for the APIs Wayland display servers typically use into their driver, not the other way around.
Yes, that's the issue I'm pointing. Now it's 15 years later, Nvidia is still not done and Wayland has seen little adoption.
Lol not a success? Unhinged take.
One of the big issues with Wayland is the (intentional) fragmentation. Each "Wayland compositor" is really its own window system, with its own peculiarities. This forces applications that would have been trivial to implement on X to either limit support to only a single "compositor", or suffer explosion of compositor-interfacing code.
IMO this, on its own, means that pushing Wayland is intentional sabotage of "desktop Linux", because the fragmentation could be deadly for the ecosystem. It's fine, if perhaps short-sighted, for the big corps and desktops that do the pushing, of course, because they're fine with supporting just a single "compositor".
IMO this, on its own, means that pushing Wayland is intentional sabotage of "desktop Linux", because the fragmentation could be deadly for the ecosystem. It's fine, if perhaps short-sighted, for the big corps and desktops that do the pushing, of course, because they're fine with supporting just a single "compositor".
> systemd
"It removes fragmentation, could be deadly for the ecosystem"
> wayland
"It adds fragmentation, could be deadly for the ecosystem"
Both are now the standard on the most of the biggest linux distributions, so maybe it's not that big of a deal?
"It removes fragmentation, could be deadly for the ecosystem"
> wayland
"It adds fragmentation, could be deadly for the ecosystem"
Both are now the standard on the most of the biggest linux distributions, so maybe it's not that big of a deal?
It seems to me like this was Wayland's fatal mistake, honestly. They left window management as an "exercise for the reader" (so to speak) because they didn't think that window management was a "serious" domain, and didn't understand how issues could arise from fragmentation there. So we traded the decades of cruft and fragmentation within the X11 spec for baked-in fragmentation at the DE level. I expect that we'll never reach a Mac-like utopia where you can set global keyboard shortcuts for window management (such as next/previous tab) at the OS level, and have it work across Wayland apps, because of this.
Yeah, I’m sure desktop linux was looking so good before Wayland that it needed some expensive sabotage mission from an Apple-Microsoft-FBI collaboration.
Come on, literally noone outside the 3% cares at all about linux desktop.
Come on, literally noone outside the 3% cares at all about linux desktop.
> Come on, literally noone outside the 3% cares at all about linux desktop.
I care. Wayland doesn't help.
I care. Wayland doesn't help.
...and the first sentence of the article calls it "Wayland display server", which it quite obviously is not.
What's your point, though? Seems nit-picky.
Wayland is not a display server and there's no such thing as "the Wayland display server". It's a protocol that's used between clients and display servers ("compositors" in Wayland parlance). Various projects build their own Wayland compositors, as opposed to X11 world where even though there were several implementations of X11 servers, pretty much everyone has used Xorg for many years now. Part of the X11 protocol was that window managers were separated from display server; most Wayland servers don't separate those though, so usually you end up with Wayland compositor provided by DE you use.
Most Wayland servers also support X11, by the way (usually through XWayland, which is part of Xorg).
Most Wayland servers also support X11, by the way (usually through XWayland, which is part of Xorg).
There’s nothing really stopping a wayland compositor from having and supporting a separate window manager, it’s just easier to not have it separate.
Window managers is a Xism that some DEs brought into the Wayland world (e.g kde) where some have not (e.g gnome).
It’s worth noting that a Wayland display server has to implement far less than an X server and as the article mentions there are things like wlroots that do a large chunk of it for you.
Window managers is a Xism that some DEs brought into the Wayland world (e.g kde) where some have not (e.g gnome).
It’s worth noting that a Wayland display server has to implement far less than an X server and as the article mentions there are things like wlroots that do a large chunk of it for you.
> There’s nothing really stopping a wayland compositor from having and supporting a separate window manager, it’s just easier to not have it separate.
That's why I said "most" and "usually". That said, while it's certainly possible, I haven't seen any implementation that did it yet.
> Window managers is a Xism that some DEs brought into the Wayland world (e.g kde)
KDE does not separate its window manager from its compositor (KWin) at all. What it separates is its shell (Plasma). In the GNOME world, mobile shell (phosh) and phoc are separated in similar way.
That's why I said "most" and "usually". That said, while it's certainly possible, I haven't seen any implementation that did it yet.
> Window managers is a Xism that some DEs brought into the Wayland world (e.g kde)
KDE does not separate its window manager from its compositor (KWin) at all. What it separates is its shell (Plasma). In the GNOME world, mobile shell (phosh) and phoc are separated in similar way.
Recently switched to Hyprland (a Wayland tiling window manager) on NixOS. It's beautiful! As a former i3 user, I'm very happy with it. It looks really nice out of the box (especially compared to i3's default appearance) and has a lot of very interesting features.
I especially enjoy Hyprland's implementation of special workspaces, which allows me to hide specific application windows and summon them on-demand with a keybinding.
My Hyprland config is here for anyone interested: https://github.com/heywoodlh/nixos-configs/blob/master/roles...
I especially enjoy Hyprland's implementation of special workspaces, which allows me to hide specific application windows and summon them on-demand with a keybinding.
My Hyprland config is here for anyone interested: https://github.com/heywoodlh/nixos-configs/blob/master/roles...
Fractional scaling is still experimental and CPU consuming in Wayland. I didn't even investigate further as that is a must have feature for me.
I can only offer anecdotal evidence, but here it goes. Used to have plenty of issues with scaling under Wayland, particular with my nvidia gpu. Now I am running an intel-only machine (yes I would prefer AMD) with a scaling factor of 1.5, and it runs very well. It's a very efficient machine, too, using only around 6W at idle, sometimes dipping below 5W.
When talking Wayland, there are no generalities because there is no program called "Wayland" -- can you specify which compositor you used? GNOME, KDE, or a wlroots-based one?
What is a good wlroots based compositor (non tiling)?
An incomplete list of compositors (they forgot hyprland):
https://github.com/solarkraft/awesome-wlroots#compositors
Among non-tiling ones are: hopalong, labwc, laikawm, tinybox, waybox, wayfire.
https://github.com/solarkraft/awesome-wlroots#compositors
Among non-tiling ones are: hopalong, labwc, laikawm, tinybox, waybox, wayfire.
Labwc is kind of openboxish https://github.com/labwc/labwc
Thanks... the screenshot looks good (and the setting to disable rounded corners is right there).
I'm running gnome.
The state of fractional scaling on Linux is abysymal.
On KDE it is very bearable.Scales very well, almost like Windows, not quite but better than Gnome by a large margin.
Lots of things are possible with wayland that was never possible with X11, just because it's a much more modern graphics stack; https://www.youtube.com/watch?v=wNL6eIoksd8
Note that the XFree86 developers themselves have abandoned XFree86 development.
Note that the XFree86 developers themselves have abandoned XFree86 development.
My laptop is a Dell Precision M4800 -- not the newest but is perfectly fast enough for what I need to do. I run KDE under X usually. Tried wayland for the first time recently and there was huge input lag with moving the mouse. I found it unusable. Other people have similar problems [1] [2]. For me at least wayland is a no go until the performance matches X.
[1] https://www.reddit.com/r/kde/comments/1335gj5/mouse_feels_la... [2] https://www.reddit.com/r/wayland/comments/wj7jji/mouse_lag_o...
[1] https://www.reddit.com/r/kde/comments/1335gj5/mouse_feels_la... [2] https://www.reddit.com/r/wayland/comments/wj7jji/mouse_lag_o...
That is KDE’s Wayland implementation. If you find safari slow, http is not at fault. Other browsers might be fast - or in this case: gnome, wlroots based ones like sway often improve performance.
For what it’s worth, KDE is quite behind in terms of wayland. It has gotten a lot better, but it is not a good fit for evaluating wayland itself.
For what it’s worth, KDE is quite behind in terms of wayland. It has gotten a lot better, but it is not a good fit for evaluating wayland itself.
I'd never heard of this Budgie desktop environment before. Anyone familiar with it? What's its deal? I'm a GNOME 2 -> Cinnamon guy, but i'm always slightly nervous that Cinnamon on Fedora is a second-class citizen and/or a dead end.
Does zoom screen sharing works with it?
For me it's a non starter if that's not fixed.
I have a nvidia gpu, so probably it's a nonstarter fullstop, damn nvidia
For me it's a non starter if that's not fixed.
I have a nvidia gpu, so probably it's a nonstarter fullstop, damn nvidia
tried KDE on Wayland. Di not like the way fonts looked like -fatter and blurrier, as if it was not properly snapping at pixel grid. Reverted to X11.
does wayland have a good tiling window manager that supports nvidia gpus yet?
I'm using Sway with my 3080 and nvidia drivers.
Why does the window manager require any type of GPU?
Because Nvidia doesn't implement APIs used by display servers and requires them to write code that's specific to their closed driver.
> APIs used by display servers
Used by the kernel. When you are using proprietary nvidia drivers you literally binary patch your xserver executable. That will obviously not work with other executables.
Used by the kernel. When you are using proprietary nvidia drivers you literally binary patch your xserver executable. That will obviously not work with other executables.
Because window managers don't exist on Wayland. What used to be a window manager is now an entire display server. Talk about well-designed.
due to changes of how Nvidia handles things I think all maintained WM do so by now, through idk. if this applies to both Nvidia drivers or only one of them.
i tried sway recently with those changes, but it still needed the —unsupported-gpu flag and had lots of flickering. i thought there might be an alternative i don't know about
I've had some luck with Hyprland (after following https://wiki.hyprland.org/Nvidia/) but it does take some hacks, and I'd imagine results will vary.
i was more charitable about trying unofficial/unsupported nvidia setups that require hacks in the past, but not any more. they take extra work to set up initially, constantly break on updates, and leave a minefield of unknown unknowns that rear their heads when you’re trying to work. the result is a compounding amount of wasted time.
official support is the way to go for me, so i’m back on X for the time being
official support is the way to go for me, so i’m back on X for the time being
I'm using wlroots-nvidia package in arch for a few months and made swaywm totally usable.
I'm using a ryzen laptop with external display via the nvidia GPU. All good!
I'm using a ryzen laptop with external display via the nvidia GPU. All good!
XWayland is still completely broken on Nvidia too, due to disagreements and lack of progress on supporting explicit sync in the graphics driver protocols.
[1] https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d...