What’s wrong with Wayland? I get the hate for systemd, even though I love it dearly, but I get the hate. But what’s wrong with Wayland? It’s amazing as far as I have used it. I started using with when Fedora 40 shipped plasma 6.
I still have weird glitches where applications don’t seem to update on screen (chrome and firefox, both natively doing wayland).
Lack of any solution for programmatic geometry interaction. This one has been afflicted with ‘perfect is enemy of good’, as the X way of allowing manual coordinates be specified is seen as potentially too limiting (reconciling geometry with scaling, non-traditional displays), so they do nothing instead of proposing an alternative.
The different security choices also curtail functionality. Great, better security for input, uh oh, less flexibility in input solutions. The ‘share your screen’ was a mess for a long time (and might be for some others still). Good the share your screen has a better security model, but frustrating when it happened.
Inconsistent experience between Wayland implementations. Since Wayland is a reference rather than a singular server, Plasma, Gnome, and others can act a little different. Like one supporting server side decorations and another being so philosophically opposed to the concept that they refuse to cater to it. While a compositing window manager effectively owned much of the hard work even in X, the X behavior between compositors were fairly consistent.
I’ve been using Plasma as a Wayland compositor after many failed attempts, and it still has papercuts.
I’ll preface this by saying that I’m a Wayland user (Hyprland, then KDE Plasma, and I’ll be giving Cosmic a fair shot), and don’t see myself returning to X and having to choose between massive screen tearing and massive input lag.
Wayland is missing many features that are required for some people or some applications. There’s no way for a multi-window application to tell the compositor where to place the windows, for example to have one window snap to and follow the other. Color profiles were implemented very recently. Wayland’s isolation of applications, while a significant improvement to security, has made remote input software and xdotool-like programs highly dependent on third-party interoperability solutions (specifically dbus and XDG Desktop Portal). The same isolation broke most accessibility tools like screen readers. Dockable windows, like the toolbars in QT Creator or QOwnNotes, are often difficult or impossible to dock back into the main window.
Because Wayland compositors have to implement all protocols (as opposed to deferring to the X.Org server; which is why wlroots is such a big deal) or rely on XDG Desktop Portal (which has never worked right for me), feature parity between compositors is never guaranteed, and especially problematic with GNOME dragging its heels.
Wayland is nowhere near feature parity with X11 today, and that is a legitimate prohibitive issue for many people. Wayland will never reach total feature parity with X11 in some areas, and that will always be prohibitive for some people.
But the worst (in my opinion) is the development process of the Wayland protocols. The proposal discussion threads read like the best and/or worst sitcom you’ve ever seen. It took them several months of back-and-forth just short of ad hominem attacks to decide how a window should set its icon. Several months for a pissing WINDOW ICON!
It’s missing a lot of features that Wayland “developers” (spec writers) don’t want to add because they personally don’t need them. For the few features they actually add, they leave it to WM developers to implement them, thus creating different incompatible implementations.
For one thing they were so obsessed with security as a concept devleoping it that they completely ignored the use case of screen-readers for the visually impaired and prevent apps from accessing text from other apps and as far as I know it is still an issue.
What’s wrong with Wayland? I get the hate for systemd, even though I love it dearly, but I get the hate. But what’s wrong with Wayland? It’s amazing as far as I have used it. I started using with when Fedora 40 shipped plasma 6.
I still have weird glitches where applications don’t seem to update on screen (chrome and firefox, both natively doing wayland).
Lack of any solution for programmatic geometry interaction. This one has been afflicted with ‘perfect is enemy of good’, as the X way of allowing manual coordinates be specified is seen as potentially too limiting (reconciling geometry with scaling, non-traditional displays), so they do nothing instead of proposing an alternative.
The different security choices also curtail functionality. Great, better security for input, uh oh, less flexibility in input solutions. The ‘share your screen’ was a mess for a long time (and might be for some others still). Good the share your screen has a better security model, but frustrating when it happened.
Inconsistent experience between Wayland implementations. Since Wayland is a reference rather than a singular server, Plasma, Gnome, and others can act a little different. Like one supporting server side decorations and another being so philosophically opposed to the concept that they refuse to cater to it. While a compositing window manager effectively owned much of the hard work even in X, the X behavior between compositors were fairly consistent.
I’ve been using Plasma as a Wayland compositor after many failed attempts, and it still has papercuts.
I’ll preface this by saying that I’m a Wayland user (Hyprland, then KDE Plasma, and I’ll be giving Cosmic a fair shot), and don’t see myself returning to X and having to choose between massive screen tearing and massive input lag.
Wayland is missing many features that are required for some people or some applications. There’s no way for a multi-window application to tell the compositor where to place the windows, for example to have one window snap to and follow the other. Color profiles were implemented very recently. Wayland’s isolation of applications, while a significant improvement to security, has made remote input software and
xdotool-like programs highly dependent on third-party interoperability solutions (specifically dbus and XDG Desktop Portal). The same isolation broke most accessibility tools like screen readers. Dockable windows, like the toolbars in QT Creator or QOwnNotes, are often difficult or impossible to dock back into the main window.Because Wayland compositors have to implement all protocols (as opposed to deferring to the X.Org server; which is why wlroots is such a big deal) or rely on XDG Desktop Portal (which has never worked right for me), feature parity between compositors is never guaranteed, and especially problematic with GNOME dragging its heels.
Wayland is nowhere near feature parity with X11 today, and that is a legitimate prohibitive issue for many people. Wayland will never reach total feature parity with X11 in some areas, and that will always be prohibitive for some people.
But the worst (in my opinion) is the development process of the Wayland protocols. The proposal discussion threads read like the best and/or worst sitcom you’ve ever seen. It took them several months of back-and-forth just short of ad hominem attacks to decide how a window should set its icon. Several months for a pissing WINDOW ICON!
Well, Fedora 40 here as well and it just doesn’t work on my computer. Sure, Nvidia, blah blah blah. X does work flawlessly on my machine, though.
It’s missing a lot of features that Wayland “developers” (spec writers) don’t want to add because they personally don’t need them. For the few features they actually add, they leave it to WM developers to implement them, thus creating different incompatible implementations.
For one thing they were so obsessed with security as a concept devleoping it that they completely ignored the use case of screen-readers for the visually impaired and prevent apps from accessing text from other apps and as far as I know it is still an issue.
Various mildly understandable to braindead reasons