Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better off avoiding Wayland.
Wayland solves no issues I have but breaks almost everything I need. Even the most basic, most simple things (like xkill) - in this case with no obvious replacement. And usually it stays broken, because the Wayland folks mostly seem to care about Automotive, Gnome, maybe KDE - and alienating everyone else (e.g., people using just an X11 window manager or something like GNUstep) in the process.
The Wayland project seems to operate like they were starting a greenfield project, whereas at the same time they try to position Wayland as "the X11 successor", which would clearly require a lot of thought about not breaking, or at least providing a smooth upgrade path for, existing software.
In fact, it is merely an incompatible alternative, and not even one that has (nor wants to have) feature parity (missing features). And unlike X11 (the X Window System), Wayland protocol designers actively avoid the concept of "windows" (making up incomprehensible words like "xdg_toplevel" instead).
DO NOT USE A WAYLAND SESSION! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!
Please add more examples to the list.
Wayland seems to be made by people who do not care for existing software. They assume everyone is happy to either rewrite everything or to just use Gnome on Linux (rather than, say, twm with ROX Filer on NetBSD).
Edit: When I wrote the above, I didn't really realize what Wayland even was, I just noticed that some distributions (like Fedora) started pushing it onto me and things didn't work properly there. Today I realize that you can't "install Wayland", because unlike Xorg, there is not one "Wayland display server" but actually every desktop envrironment has its own. And maybe "the Wayland folks" don't "only care about Gnome", but then, any fix that is done in Gnome's Wayland implementation isn't automatically going to benefit all users of Wayland-based software, and possibly isn't even the implementation "the Wayland folks" would necessarily recommend.
Edit 12/2023: If something wants to replace X11 for desktop computers (such as professional Unix workstations), then it better support all needed features (and key concepts, like windows) for that use case. That people also have displays on their fridge doesn't matter the least bit in that context of discussion. Let's propose the missing Wayland protocols for full X11 feature parity.
Edit 08/2024: "Does Wayland becoming the defacto standard display server for Linux serve to marginalize BSD?" https://fossforce.com/2024/07/the-unintended-consequences-linuxs-wayland-adoption-will-have-on-bsd/
/usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)Apparently the Wayland project doesn't even want to be "X.org 2.0", and doesn't want to provide a commonly used implementation of a compositor that could be used by everyone: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233. Yet this would imho be required if they want to make it into a worthwile "successor" that would have any chance of ever fixing the many Wayland issues at the core.
obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)As of February 2024, screen recording is still broken utterly on Wayland with the vast majority of tools. Proof
Workaround: Find a Wayland compositor that supports the wlr-screencopy-unstable-v1 protocol and use wf-recorder -a. The default compositor in Raspberry Pi OS (Wayfire) does, but the default compositor in Ubuntu doesn't. (That's the worst part of Wayland: Unlike with Xorg, it always depends on the particular Wayand compositor what works and what is broken. Is there even one that supports everything?)
NOTE: As of November 2023, screen sharing in Chromium using Jitsi Meet is still utterly broken, both in Raspberry Pi OS Desktop, and in a KDE Plasma installation, albeit with different behavior. Note that Pipewire, Portals and whatnot are installed, and even with them it does not work.
sudo pkg install py37-autokey
This is an X11 application, and as such will not function 100% on
distributions that default to using Wayland instead of Xorg.
https://gitlab.com/lestcape/Gnome-Global-AppMenu/-/issues/116 :x: broken since 24 Aug 2018 ("because the lack of the Gtk+ Wayland support for the Global Menu")
https://bugs.kde.org/show_bug.cgi?id=424485 :x: Still broken as of late 2023 ("I am also still not seeing GTK global menus on wayland. They appear on the applications themselves, wasting a lot of space.")
https://blog.broulik.de/2016/10/global-menus-returning/ ("it uses global window IDs, which don’t exist in a Wayland world... no global menu on Wayland, I thought, not without significant re-engineering effort"). KDE had to do additional work to work around it. And it still did not work:
https://bugs.kde.org/show_bug.cgi?id=385880 ("When using the Plasma-Wayland session, the global menu does not work.")
Good news: According to this report global menus now work with KDE platformplugin as of 4/2022
_KDE_NET_WM_APPMENU_OBJECT_PATH which only the KDE platformplugin sets, leaving everyone else in the darkUpdate 2023: Some Wayland compositors (such as Wayfire) now support wlr_gamma_control_unstable_v1, see https://github.com/WayfireWM/wayfire/wiki/Tutorial#configuring-wayfire and https://github.com/jonls/redshift/pull/663. Does it work in all Wayland compositors though?
See below.
Apparently Wayland relies on nouveau drivers for NVidia hardware. The nouveau driver has been giving unsatisfactory performance since its inception. Even clicking on the application starter icon in Gnome results in a stuttery animation. Only the proprietary NVidia driver results in full performance.
See below.
Update 2024: The situation might slowly be improving. It remains to be seen whether this will work well also for all existing old Nvidia hardware (that works well in Xorg).
truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)Red Hat employee Matthias Clasen ("I work at the Red Hat Desktop team... I am actually a manager there... the people who do the actual work work for me") expicitly stated "Client-side everything" as a principle, even though the protocol doesn't enforce it: "Fonts, Rendering, Nested Windows, Decorations. "It also gives the design more freedom to use the titlebar space, which is something our designers appreciate" (sic). Source
Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.
- Screen recording and casting
- Querying of the mouse position, keyboard LED state, active window position or name, moving windows (xdotool, wmctrl)
- Global shortcuts
- System tray
- Input Method support/editor (IME)
- Graphical settings management (i.e. tools like xranrd)
- Fast user switching/multiple graphical sessions
- Session configuration including but not limited to 1) input devices 2) monitors configuration including refresh rate / resolution / scaling / rotation and power saving 3) global shortcuts
- HDR/deep color support
- VRR (variable refresh rate)
- Disabling input devices (xinput alternative)
As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. You do not expect JWM, TWM, XDM or even IceWM developers to implement all the featured outlined in ^1.
_NET_WM_STATE_SKIP_TASKBAR protocol_NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) :x: broken since March 10, 2022xclip is a command line utility that is designed to run on any system with an X11 implementation. It provides an interface to X selections ("the clipboard"). Apparently Wayland isn't compatible to the X11 clipboard either.
xclip. Wayland asks for wl-copy")This is another example that the Wayland requires everyone to change components and take on additional work just because Wayland is incompatible to what we had working for all those years.
SUDO_ASKPASSSUDO_ASKPASS doesn't work on Wayland currently, so piping the password")X11 atoms can be used to store information on windows. For example, a file manager might store the path that the window represents in an X11 atom, so that it (and other applications) can know for which paths there are open file manager windows. Wayland is not compatible to X11 atoms, resulting in all software that relies on them to be broken until specifically ported to Wayland (which, in the case of legacy software, may well be never).
Possible workaround (to be verified): Use the (Qt proprietary?) Extended Surface Wayland protocol casually mentioned in https://blog.broulik.de/2016/10/global-menus-returning/ "which allows you to set (and read?) arbitrary properties on a window". Is it the set_generic_property from https://github.com/qt/qtwayland/blob/dev/src/extensions/surface-extension.xml?
Games are developed for X11. And if you run a game on Wayland, performance is subpar due to things like forced vsync. Only recently, some Wayland implementations (like KDE KWin) let you disable that.
(Details to be added; apparently no 1:1 drop-in replacement available?)
xkill (which I use on a regular basis) does not work with Wayland applications.
What is the equivalent for Wayland applications?
Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/
Other platforms (Windows, Mac, other destop environments) can set the window position on the screen, so all cross-platform toolkits and applications expect to do the same on Wayland, but Wayland can't (doesn't want to) do it.
Apparently color management as of 2023 (well over a decade of Wayland development) is still in the early "thinking" stage, all the while Wayland is already being pushed on people as if it was a "X11 successor".
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/color-management-model.md
According to Valve, "DRM leasing is the process which allows SteamVR to take control of your VR headset's display in order to present low-latency VR content".
Extended Window Manager Hints, a.k.a. NetWM, is an X Window System standard for the communication between window managers and applications
Wayland breaks window icons when no .desktop files are used: Seemingly Wayland requires developers to use the xdg-shell protocol, which in turn requires developers to use reverse-DNS application IDs and set_app_id, which causes the icon to be loaded from the .desktop file. This is serious breakage, as not all desktop environments (for good reasons) use .desktop files. A display server should have no business in this, as this belongs into the domain of the desktop environment. https://community.kde.org/Guidelines_and_HOWTOs/Wayland_Porting_Notes#Application_Icon, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52 :x: broken since 2021-06-21
Qt setWindowIcon has no effect on KDE/Wayland https://bugreports.qt.io/browse/QTBUG-101427 ("Resolution: Out of scope", meaning it cannot be fixed in Qt, "Using QT_QPA_PLATFORM=xcb works, though", meaning that if you disable Wayland then it works) :x: broken since 2022-03-03
LibrePCB developer: "Btw it's just one of several problems we have with Wayland, therefore we still enforce LibrePCB to run with XWayland. It's a shame, but I feel totally helpless against such decisions made by Wayland and using XWayland is the only reasonable option (which even works perfectly fine)..." https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52#note_2155885
Update 6/2024: Looks like this will get unbroken thanks to xdg_toplevel_icon_manager_v1, so that QWindow::setIcon will work again. If, and that's a big if, all compositors will support it. At least KDE is on it.
./windowmanager --replace--replace argument, but Wayland compositors break this convention.Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.
This is exactly the kind of behavior this gist seeks to prevent.
Source: "Where's Wayland?" by Matthias Clasen - Flock 2014
A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg