Wayland is unfortunately the only game in town, no matter how flawed it is.
I think that’s the core of why people are so upset with Wayland: they disagree with Wayland’s design decisions, but don’t have any alternatives. For how vocal Linux users are about Wayland ruining their lives, I’ve seen very little effort put into resurrecting alternatives such as Mir or writing an alternative.
Now, as KDE and Gnome are planning to eventually move away from X.org, there’s no more time to write any alternatives before it’s too late. The only way for people who don’t like Wayland to continue using the latest version of their favourite software, is to fight Wayland at every step, in hopes of keeping X11 around for as long as possible.
I’m fairly sure many of the people angry at Wayland don’t have problems with Wayland per se, but just don’t want to learn new tools or make minor changes to their workflow.
There are still issues with running Wayland on many computers, most of them involving Nvidia hardware, but on most computers Wayland is a perfectly sane default these days.
I think the main problem is that Wayland is not a drop in replacement.
Every software needs to support Wayland, new environment flags need to be created, flags must be used with electron apps…
Nvidia support has been spotty and some functionality has not yet been implemented. I use a custom .xcompose file, which doesn’t work on electron apps. Let me know if there’s a better way to mimic window’s dead keys.
Overall, it’s hard for an end user to change from a solution that is working perfectly to a solution that requires a ton of work and doesn’t yet have the same functionality.
Everyone can understand that Wayland is the future but depending on your needs and hardware the current experience can be great or terrible.
Sure but as someone starting with a new system Wayland just works. Example multitouch works right away on Wayland and if I remember correctly needs configuration on x11.
The only flag I had to set was one for Firefox, and that has become enabled by default these days. XWayland solves all of the difficult mess as far as I can tell, including dealing with Electron applications.
I suppose the difficulty of migration depends on how complex your setup, but for most distros, switching to Wayland is no more difficult than selecting it in a dropdown on the login screen and installing a different screen recorder (because those are often written specifically for X.org or Wayland’s APIs, and rarely for both).
I had to set a ton more. Without the ozone flags my electron apps flicker and have this sync problem that appears to eat letters while I type them. Different electron apps use different configuration files, it’s a mess.
I wouldn’t consider my setup to be complex enough for the amount of trouble I had to make the system work under Wayland.
I’m using an Nvidia GPU, I’m sure things would be more streamlined if I had something else.
How strange, with how many of the programs I run I would’ve expected to have the same issues on my end as well. Blaming Nvidia is usually a solid bet, but I didn’t have any of these issues with Ubuntus’s Wayland support on my GTX1080, and Ubuntu tends to be a few years behind on package versions.
I’m unfamiliar with the ozone flags, a cursory Google search says it enables the (optional, for some reason) Wayland backend for Electron stuff, which people with fractional scaling seemingly need to do to get good rendering (because X11 doesn’t really do fractional scaling either so XWayland can’t compensate).
I wonder why Electron would default to X11 when started under a Wayland session.
A switch from X11 to Wayland is not just a minor change to your workflow though unless you used all defaults before.
It requires you to replace your window manager, all the little tools related to things like clipboard, automation, screen locking,…
And you would have to do pretty much all of that up front to be able to use Wayland long enough to know if it even works on a permanent basis for you. That is a lot of work to put into a project that has a sketchy history of people claiming for nearly a decade now that it works just fine for everything while clearly not working fine for all use cases.
I suppose it’s more difficult if your desktop environment doesn’t support Wayland, so you’d have to replace it entirely. I can imagine that’s a pain, but that’s not exactly the typical use case.
Luckily, I doubt X.org will be abandoned any time soon, so the minority stuck in their old X.org exclusive environments will be able to use their programs unchanged for years to come. Eventually X.org users will be in the same position Wayland users were in years ago (having to apply workarounds for missing APIs to keep everything running smoothly) but I doubt that’ll happen soon.
Clipboards work out of the box in the Wayland compositors I’ve used (Gnome, KDE, Deck UI), as does screen locking. Most automation also works, at least between X11 applications running under XWayland, but that’s the “workflow” thing I mentioned; xdotool needs to be replaced by ydotool and maybe some DBus calls, depending on your setup, but a few aliases and an afternoon of work should work around those problems when the time to switch eventually comes.
I believe xsel and xclip can be replaced pretty easily with wl-clipboard or one of the alternatives for that.
I don’t use multi-clipboards myself, so I couldn’t tell you what to use as an alternative. I think CopyQ supports Wayland? Or maybe you need to cook something up with one of the Wayland <-> X11 clipboard sync tools.
The point wasn’t so much that there are no replacements, more that every script and every shortcut and everything else using them will have to be changed to work with the Wayland alternative.
I think that’s the core of why people are so upset with Wayland: they disagree with Wayland’s design decisions, but don’t have any alternatives. For how vocal Linux users are about Wayland ruining their lives, I’ve seen very little effort put into resurrecting alternatives such as Mir or writing an alternative.
Now, as KDE and Gnome are planning to eventually move away from X.org, there’s no more time to write any alternatives before it’s too late. The only way for people who don’t like Wayland to continue using the latest version of their favourite software, is to fight Wayland at every step, in hopes of keeping X11 around for as long as possible.
I’m fairly sure many of the people angry at Wayland don’t have problems with Wayland per se, but just don’t want to learn new tools or make minor changes to their workflow.
There are still issues with running Wayland on many computers, most of them involving Nvidia hardware, but on most computers Wayland is a perfectly sane default these days.
I think the main problem is that Wayland is not a drop in replacement.
Every software needs to support Wayland, new environment flags need to be created, flags must be used with electron apps…
Nvidia support has been spotty and some functionality has not yet been implemented. I use a custom .xcompose file, which doesn’t work on electron apps. Let me know if there’s a better way to mimic window’s dead keys.
Overall, it’s hard for an end user to change from a solution that is working perfectly to a solution that requires a ton of work and doesn’t yet have the same functionality.
Everyone can understand that Wayland is the future but depending on your needs and hardware the current experience can be great or terrible.
Sure but as someone starting with a new system Wayland just works. Example multitouch works right away on Wayland and if I remember correctly needs configuration on x11.
“just works” depends on your needs. There is. Polarizing opinion on the Wayland vs x11 because the experiences are also very polarizing.
The only flag I had to set was one for Firefox, and that has become enabled by default these days. XWayland solves all of the difficult mess as far as I can tell, including dealing with Electron applications.
I suppose the difficulty of migration depends on how complex your setup, but for most distros, switching to Wayland is no more difficult than selecting it in a dropdown on the login screen and installing a different screen recorder (because those are often written specifically for X.org or Wayland’s APIs, and rarely for both).
I had to set a ton more. Without the ozone flags my electron apps flicker and have this sync problem that appears to eat letters while I type them. Different electron apps use different configuration files, it’s a mess.
I wouldn’t consider my setup to be complex enough for the amount of trouble I had to make the system work under Wayland.
I’m using an Nvidia GPU, I’m sure things would be more streamlined if I had something else.
How strange, with how many of the programs I run I would’ve expected to have the same issues on my end as well. Blaming Nvidia is usually a solid bet, but I didn’t have any of these issues with Ubuntus’s Wayland support on my GTX1080, and Ubuntu tends to be a few years behind on package versions.
I’m unfamiliar with the ozone flags, a cursory Google search says it enables the (optional, for some reason) Wayland backend for Electron stuff, which people with fractional scaling seemingly need to do to get good rendering (because X11 doesn’t really do fractional scaling either so XWayland can’t compensate).
I wonder why Electron would default to X11 when started under a Wayland session.
A switch from X11 to Wayland is not just a minor change to your workflow though unless you used all defaults before.
It requires you to replace your window manager, all the little tools related to things like clipboard, automation, screen locking,…
And you would have to do pretty much all of that up front to be able to use Wayland long enough to know if it even works on a permanent basis for you. That is a lot of work to put into a project that has a sketchy history of people claiming for nearly a decade now that it works just fine for everything while clearly not working fine for all use cases.
I suppose it’s more difficult if your desktop environment doesn’t support Wayland, so you’d have to replace it entirely. I can imagine that’s a pain, but that’s not exactly the typical use case.
Luckily, I doubt X.org will be abandoned any time soon, so the minority stuck in their old X.org exclusive environments will be able to use their programs unchanged for years to come. Eventually X.org users will be in the same position Wayland users were in years ago (having to apply workarounds for missing APIs to keep everything running smoothly) but I doubt that’ll happen soon.
Clipboards work out of the box in the Wayland compositors I’ve used (Gnome, KDE, Deck UI), as does screen locking. Most automation also works, at least between X11 applications running under XWayland, but that’s the “workflow” thing I mentioned;
xdotoolneeds to be replaced byydotooland maybe some DBus calls, depending on your setup, but a few aliases and an afternoon of work should work around those problems when the time to switch eventually comes.I was talking about tools like xsel or xclip or clipboard managers for multiple clipboards.
I believe
xselandxclipcan be replaced pretty easily withwl-clipboardor one of the alternatives for that.I don’t use multi-clipboards myself, so I couldn’t tell you what to use as an alternative. I think CopyQ supports Wayland? Or maybe you need to cook something up with one of the Wayland <-> X11 clipboard sync tools.
The point wasn’t so much that there are no replacements, more that every script and every shortcut and everything else using them will have to be changed to work with the Wayland alternative.
You use requires but those are not requirements. It applies to some cases.
Sketchy history? Seems biased.