Skip to content

Instantly share code, notes, and snippets.

@probonopd
Last active July 28, 2025 21:48
Show Gist options
  • Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Save probonopd/9feb7c20257af5dd915e3a9f2d1f2277 to your computer and use it in GitHub Desktop.
Think twice about Wayland. It breaks everything!

Think twice before abandoning X11. Wayland breaks everything!

image

Wayland breaks everything! It is binary incompatible, provides no clear transition path with 1:1 replacements for everything in X11, and is even philosophically incompatible with X11. 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.

Feature comparison

Please do fact-check and suggest corrections/improvements below. Maybe this table should find its home in a Wiki, so that everyone could easily collaborate. I'm just a bit fearful of vandalism... ideas?

✅ Supported ⚠️ Available with limitations ❌ Not available or only available on some systems (requires particular compositors or additional software which may not be present on every system)

Functionality Xorg Wayland
Performance ✅ Best (DistroWatch) ⚠️ Worse (DistroWatch)
Power consumption ? ?
Memory usage ✅ ~150 MB lower (Phoronix) ⚠️ ~150 MB higher (Phoronix)
Nvidia GPUs ✅ Well supported by proprietary Nvidia driver, also older hardware (open source driver Nouveau never worked satisfactorily) ⚠️ Only recent hardware
Multi-monitor ✅ Supported via XRandR, Xinerama (TheServerHost, KDE Blog) ✅ Stable, dynamic hotplug, better multi-monitor support (KDE Blog, CBT Nuggets)
Multi-resolution Multi-screen Support ✅ Can be done (tedu); mixed refresh rates (guiodic, Reddit) ✅ Per-output resolutions and per-output scaling with sharp rendering (CBT Nuggets, EndeavourOS Forum)
Cropping and Scaling ✅ Per monitor with XRandR (xrandr manpage) wp_viewporter, wp_fractional_scale_manager_v1, per-window ("surface") cropping (Wayland Protos, KDE Dev)
Screen Recording / Capture ✅ Supported via X APIs; easy screen & window recording (Xlib Manual, OBS Wiki) ❌ Not natively available—wlr-screencopy and/or ext-image-copy-capture can be used without Portals but may not be present on every system. Otherwise requires Screencast Portal, which may not be present on every system (GNOME Docs, PipeWire Portal FAQ).
Input Devices / Event Routing XInput, XInput2, global intercept (XInput2 Docs) ❌ Input routed only to focused window ("surface"), no global interception (Wayland FAQ, Wayland Security)
Input Injection ✅ Via XTEST, XSendEvent (XTEST Spec) ❌ Not natively available—requires Remote Desktop Portal, which may not be present on every system (libei GH, KDE Input) . Workaround: /dev/uinput should work everywhere.
Global Hotkeys / Key Grabs XGrabKey()/XGrabButton() (Xlib Docs) ❌ Not natively available—requires Global Shortcuts Portal, which may not be present on every system (Portal Docs, KDE)
Window Positioning / Stacking ✅ Clients move/resize windows (Xlib Ref) ❌ Only compositor controls window positioning (Wayland FAQ, KDE Dev)
Clipboard Access ✅ Full/explicit, ICCCM selections (ICCCM) ❌ Not natively available—requires Clipboard Portal, which may not be present on every system (Clipboard Portal, Wayland FAQ)
Drag and Drop / Copy and Paste ✅ Xdnd, Motif (Xdnd Spec), Motif (Motif DND) ⚠️ wl_data_offer, wl_data_device_manager (Wayland Protos, KDE Drag&Drop) but implementations are flaky, especially when dragging between X11 and Wayland applications
Touch / Gesture Support XInput2 (XInput Multi-Touch) wl_touch, gestures via zwp_pointer_gestures_v1 (Wayland Protos)
Tablet Support XInput2 (libinput Tablet) zwp_tablet_manager_v2 (Wayland Protos)
Remote Display / Network Transparency ✅ X11 protocol, SSH forwarding (OpenBSD FAQ, XForwarding) ❌ Not natively available—requires Remote Desktop Portal, which may not be present on every system (Wayland FAQ)
Screen Configuration XRandR direct (xrandr manpage) ❌ Only compositor can set layout; clients have no access (KDE Dev). Supported by some compositors which may not be present on every system via wlr-output-management and associated tools like wlr-randr.
Global menus ✅ Works ❌ Not natively available—requires qt_extended_surface set_generic_property which may not be present on every system
Window Management Hints (size, position) XSetWMHints, XSetNormalHints (ICCCM) ❌ Position not supported, only size
Window Title / Icon Name XSetWMName, XSetIconName (ICCCM) xdg_toplevel.set_title/set_icon (xdg-shell)
Window State (iconic, withdrawn, etc.) XSetWMState (ICCCM) ❌ Not exposed to clients; handled by compositor (Wayland FAQ)
Window Protocols (WM_DELETE_WINDOW) ✅ ICCCM, WM_DELETE_WINDOW (ICCCM) xdg_toplevel.close (xdg-shell)
Window Class / Instance XSetClassHint (ICCCM) ❌ Not supported (Wayland FAQ)
Window Transience (dialogs, popups) XSetTransientForHint (ICCCM) xdg_toplevel.set_parent (xdg-shell)
Input Focus (active window) XSetInputFocus (Xlib Ref) ❌ Managed by compositor (Wayland FAQ)
Selections ✅ Selections (ICCCM) ❌ Not natively available—requires Clipboard Portal, which may not be present on every system (Clipboard Portal, Wayland FAQ)
Drag and Drop ✅ Motif/Xdnd (Xdnd Spec) ✅ Native protocol (Wayland/Drag&Drop)
Window Grouping XSetWMHints group (ICCCM) ❌ No concept/protocol for grouping (Wayland FAQ)
Input Model / Input Hint ✅ Input model hints (ICCCM) ❌ Not exposed/natively supported (Wayland FAQ)
Window Manager Communication ✅ ICCCM client-to-WM (ICCCM) ❌ No standard protocol (Wayland FAQ)
Colormap / Visual hints ✅ Colormap per ICCCM (ICCCM) ⚠️ Handled by compositor (Wayland FAQ)
Icon Pixmap / Bitmap ✅ ICCCM icon hints (ICCCM) xdg_toplevel.set_icon (xdg-shell)
Urgency Hint XUrgencyHint (ICCCM) ❌ Not standardized; up to compositor (Wayland FAQ)
Window Shade (roll up/down) WM_STATE (mapped/unmapped state) ❌ Not supported
Window Always On Top (z-order) ✅ Applications can request stacking/z-order via WM_HINTS, window group, _NET_WM_STATE_ABOVE (EWMH) ❌ Not supported
Exclusive Display Control / DRM Leasing ⚠️ No protocol, possible with libdrm (libdrm) wp_drm_lease_v1 (Wayland Protos)
Transparency / Compositing ⚠️ With composite extension/compton/picom (wiki.archlinux) ✅ Built-in; always composited (Wayland FAQ)
Color Management ⚠️ Apps/loaders like xiccd (XCM docs) wp-color-manager-v1 (Wayland Protos)
VSync / Tear-free Rendering ⚠️ Inconsistent, needs correct driver/config (AskUbuntu) ✅ Guaranteed by compositor; always tear-free (Wayland FAQ)
Security / App Isolation ⚠️ Via extensions, e.g., Xnamespace extension (The Register) ⚠️ Wayland tries to separate applications from each other. As a result, applications can't do many things ("We're treated like hostile threat actors on our own workstations")
Click into a window to terminate the application xkill ❌ Not natively available—some compositors may have proprietary mechanisms, which may not be present on every system
Click into a window to see its metadata xprop ❌ Not supported
Set and get metadata (properties) on windows to exchange information regarding windows ✅ X Atoms (Docs) ❌ Not supported
One window server used by virtually all desktop environments and distributions ✅ Xorg (and Xlibre) ❌ Every desktop environment comes with a different compositor, which behaves differently, supports different features and has different bugs

Status update

Update 06/2025: X11 is alive and well, despite what Red Hat wants you to believe. https://github.com/X11Libre/xserver revitalizes the Xorg X11 server as a community project under new leadership.

And Red Hat wanted to silence it.


As 2024 is winding down:

For the record, even in the latest Raspberry Pi OS you still can't drag a file from inside a zip file onto the desktop for it to be extracted. So drag-and-drop is still broken for me.

And Qt move() on a window still doesn't work like it does on all other desktop platforms (and the Wayland folks think that is good).

And global menus still don't work (outside of not universally implemented things like qt_extended_surface set_generic_property).

Wayland issues

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/

Wayland is broken by design

  • A crash in the window manager takes down all running applications
  • You cannot run applications as root
  • You cannot do a lot of things that you can do in Xorg by design
  • There is not one /usr/bin/wayland display server application that is desktop environment agnostic and is used by everyone (unlike with Xorg)
  • It offloads a lot of work to each and every window manager. As a result, the same basic features get implemented differently in different window managers, with different behaviors and bugs - so what works on desktop environment A does not necessarily work in desktop environment B (e.g., often you hear that something "works in Wayland", even though it only really works on Gnome and KDE, not in all Wayland implementations). This summarizes it very well: https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

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.

Wayland breaks screen recording applications

  • MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
  • https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
  • vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
  • obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
  • There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)
  • phw/peek#1191 ❌ broken since 14 Jan 2023. Peek, a screen recording tool, has been abandoned by its developerdue to a number of technical challenges, mostly with Gtk and Wayland ("Many of these have to do with how Wayland changed the way applications are being handled")

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?)

Wayland breaks screen sharing applications

  • jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
  • jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.

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.

Wayland breaks automation software

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.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

Wayland broke global menus with KDE platformplugin

Good news: According to this report global menus now work with KDE platformplugin as of 4/2022

Wayland breaks global menus with non-KDE Qt platformplugins

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

  • https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

Update 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 jonls/redshift#663. Does it work in all Wayland compositors though?

Wayland breaks global hotkeys

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

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).

Wayland does not work properly on Intel hardware

Wayland prevents GUI applications from running as root

  • https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running 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".)

Suggested solution

Wayland is biased toward Linux and breaks BSD

  • https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

  • https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

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

Wayland breaks windows rasing/activating themselves

Wayland breaks RescueTime

Wayland breaks window managers

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.

Wayland requires JWM, TWM, XDM, IceWM,... to reimplement Xorg-like functionality

  • 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.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

  • https://github.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _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.) ❌ broken since March 10, 2022

Wayland breaks NoMachine NX

Wayland breaks xclip

xclip 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.

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.

Wayland breaks SUDO_ASKPASS

Wayland breaks auto-type in password managers

Wayland breaks X11 atoms

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?

Wayland breaks games

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.

Wayland breaks xdotool

(Details to be added; apparently no 1:1 drop-in replacement available?)

Wayland breaks xkill

xkill (which I use on a regular basis) does not work with Wayland applications.

What is the equivalent for Wayland applications?

Wayland breaks screensavers

Is it true that Wayland also breaks screensavers? https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/

Wayland breaks setting the window position

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.

  • PCSX2/pcsx2#10179 PCX2 (Playstation 2 Emulator) ❌ broken since 2023-10-25 ("Disables Wayland, it's super broken/buggy in basically every scenario. KDE isn't too buggy, GNOME is a complete disaster.")

  • Wayland might allow the compositor (not: the application) to set window positions, but that means that as an application author, I can't do anything but wait for KDE to implement https://bugs.kde.org/show_bug.cgi?id=15329 - and even then, it will only work under KDE, not Gnome or elsewhere. Big step backward compared to X11!

Wayland breaks color mangement

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

Wayland breaks DRM leasing

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".

Wayland breaks In-home Streaming

Wayland breaks NetWM

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

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.

Wayland breaks drag and drop

Wayland breaks ./windowmanager --replace

  • Many window managers have a --replace argument, but Wayland compositors break this convention.

Wayland breaks Xpra

Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.

  • Under Xpra a context menu cannot be used: it opens and closes automatically before you can even move the mouse on it. "It's not just GDK, it's the Wayland itself. They decided to break existing applications and expect them to change how they work." (Xpra-org/xpra#4246) ❌ broken since 2024-06-01

Wayland breaks multi desktop docks

  • "Unfortunately Wayland is not designed to support multi desktop dock projects. This is why each DE using Wayland is building their own custom docks. Plus there is a lot of complexity to support Wayland based apps and also merge that data with apps running in Xwayland. A dock isn't useful unless it knows about every window and app running on the system." zquestz/plank-reloaded#70 ❌ broken since 2025-06-10

Xwayland breaks window resizing

Workarounds

  • Users: Refuse to use Wayland sessions. Uninstall desktop environments/Linux distributions that only ship Wayland sessions. Avoid Wayland-only applications (such as PreSonus Studio One) (potential workaround: run in https://github.com/cage-kiosk/cage)
  • Application developers: Enforce running applications on X11/XWayland (like LibrePCB does as of 11/2023)

Examples of Wayland being forced on users

This is exactly the kind of behavior this gist seeks to prevent.

Summary what is wrong with Wayland, by one of its contributors

image

Source: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/179#note_2965661

History

  • 2008: Wayland was started by krh (while at Red Hat)
  • End of 2012: Wayland 1.0
  • Early 2013: GNOME begins Wayland porting

Source: "Where's Wayland?" by Matthias Clasen - Flock 2014

A decade later... Red Hat wants to force Wayland upon everyone, removing support for Xorg

What now?

Following the professional application KiCad's advice:

Recommendations for Users

For Professional Use

If you use KiCad professionally or require a reliable, full-featured experience, we strongly recommend:

Use X11-based desktop environments such as:

XFCE with X11 KDE Plasma with X11 MATE

Traditional desktop environments that maintain X11 support

Install X11-compatible display managers like LightDM or KDM instead of GDM if your distribution defaults to Wayland-only

Choose distributions that maintain X11 support - some distributions are moving to Wayland-only configurations that may not meet your needs

Source: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/#

Similarly, for Krite: https://www.davidrevoy.com/article1030/debian-12-kde-plasma-2024-install-guide#d-krita-as-appimage

References

@Consolatis
Copy link

Then again, please tell me how a X11 client can restore its size and position in tiling window managers. The window manager can do that, can the client do it?

@probonopd
Copy link
Author

probonopd commented Jul 27, 2025

I have only ever used stacking window managers. I can't even imagine how a tiling window manager would work with multi window applications. Overlapping windows are ia great achievement and are imho essential to the desktop metaphor.

@Loonekud
Copy link

Loonekud commented Jul 27, 2025

You're making too much work for yourself, waylanders.

Why should that work be shifted to individual developers? I thought you guys likes uniformity and all, wouldn't you want all your apps to remember their position and size, even if a developer hasn't or won't implement it themselves?

Give us a way to position and size

It's so clear how most people here have never used wayland and just repeat hearsay bs probono makes up in this gist (and then edits out when called out). Clients can set their own size on wayland.

@Consolatis
Copy link

Consolatis commented Jul 27, 2025

Personally I also very much prefer the stacking approach. But a proper solution to the use-case of restoring window geometry needs to cover all workflows, including those that rely on tiling window managers (or 3d spatial ones or whatever comes up in the future). So exposing the ability for windows to (2d) position themselves in wayland will not completely solve this issue. The session protocol however can do that because it relies on the entity that manages windows in the first place.

@darkhog
Copy link

darkhog commented Jul 27, 2025

Give us a way to position and size

It's so clear how most people here have never used wayland and just repeat hearsay bs probono makes up in this gist (and then edits out when called out). Clients can set their own size on wayland.

You're missing the point, the AND bit is very important. It is needed to both be able to set position AND the size. Having one without another makes both useless. As for tiling WMs, as a developer I don't care about what 0.00000000000001% of users use. Tiling WMs haven't been useful for a long time. And as much as I like Vaxry, hyprland is just pointless fluff without any substance.

@Consolatis Even if apps being able to position themselves won't solve EVERY issue, it will solve most of them for huge amount of users that use proper WMs/DEs. We can figure out something for the 0.00000000000001% of users who use tiling WMs later on.

@Consolatis
Copy link

Consolatis commented Jul 27, 2025

You're missing the point, the AND bit is very important. It is needed to both be able to set position AND the size. Having one without another makes both useless.

Do you even understand what you write? Not being able to position windows makes setting the window size useless? I bet there are some terminal emulators, video players and remote desktop clients out there which strongly disagree with that statement.

As for tiling WMs, as a developer I don't care about what 0.00000000000001% of users use. Tiling WMs haven't been useful for a long time.

Isn't that exactly the kind of statement that the "Wayland destroys everything" fanboys accuse Wayland of? So your personal workflow is the only one that is important and considerations for other workflows are irrelevant? Nice attitude.

Even if apps being able to position themselves won't solve EVERY issue, it will solve most of them for huge amount of users that use proper WMs/DEs. We can figure out something for the 0.00000000000001% of users who use tiling WMs later on.

proper.. Nice judgement of other people's workflow.

@Loonekud
Copy link

Loonekud commented Jul 27, 2025

You're missing the point, the AND bit is very important

The AND is useless when the second part is true already. I don't get the point of arguing for this further in your reply, it exists, it's supported, it works, mentioning it adds nothing to your original argument.

As for tiling WMs, as a developer I don't care about what 0.00000000000001% of users use

Okay so can you guys stop crying over GNOME's current dependence on systemd? Users of the other init systems are even smaller than WM users (including the entirety of FreeBSD desktop users).

won't solve EVERY issue, it will solve most of them for huge amount of users that use proper WMs/DEs

What exactly is it solving? You made up a user in your mind that's like "god I wish I could use wayland but since my calculator can't position itself, I'll have to pass".

@probonopd
Copy link
Author

probonopd commented Jul 27, 2025

wouldn't you want all your apps to remember their position and size, even if a developer hasn't or won't implement it themselves?

Use case 1:

https://en.wikipedia.org/wiki/Palette_window
The application knows where the palettes need to go. The compositors don't. Or else every compositor would need to know the details of every application that uses palettes. And each application author would need to tell the developers of all compositors where to put them.

Use case 2:

In my use case (spatial file manager), because I need to save the window position inside the folder a window represents. So that when you copy the folder to another disk, burn it to CD etc., it will retain its intended position even when opened on another machine.
If a compositor saves this information "somewhere", it is not good enough. My application needs to save it in a format of my own choosing. (Think https://en.wikipedia.org/wiki/.DS_Store files)

@probonopd
Copy link
Author

probonopd commented Jul 27, 2025

Users of the other init systems are even smaller than WM users

What do you want to say with that? Typing this from FreeBSD, where no systemd exists (which was part of my reason to choose it). I want my system free from anything Red Hat touched.

@probonopd
Copy link
Author

Clients can set their own size on wayland.

Isn't it funny that they can set their size but not position? As if by "maliciously resizing" windows you couldn't do at least as much damage as by moving windows.

Shows how arbitrarily the Wayland overlords decide what we may and may not have.

@Loonekud
Copy link

Loonekud commented Jul 27, 2025

Use case 1:

First of all, you are derailing the conversation again, you saw a trigger word and couldn't hold yourself back from posting your copypasta. We were talking about apps remembering their last position and size when starting up. The person I replied to argued that apps should remember it themselves, I argued that the compositor should do it automatically.

https://en.wikipedia.org/wiki/Palette_window

The screenshot shows the pallette inside the main window. GIMP already does a similar thing with their dialogs, use the resize tool for example. A small semi transparent dialog will show up at the top right. Your use case is not valid, a palette doesn't need to be drawn in a separate window but even if it does the app doesn't need precise control over the position, a relative "bottom left on me" is enough.

Use case 2:

Nobody cares. This is the most niche use case anyone can come up with, we won't bow down to your silly app which will have a total of 2 users (you and the person you forced to package it).

What do you want to say with that? Typing this from FreeBSD, where no systemd exists (which was part of my reason to choose it). I want my system free from anything Red Hat touched.

Once again, you failed to read what I was replying to. The person I was replying to said that they don't care about WMs since almost nobody uses them. My counter argument was that there many parts of the Unix world that everyone agrees on but there's always 2 people that go against the current that we could all ignore. Thanks for proving my point though.

Shows how arbitrarily the Wayland overlords decide what we may and may not have.

Your refusal to listen to other perspectives is the reason we are arguing here right now. You could have engaged in the conversations when they were happening but you didn't.

So allow me to repeat one of the many arguments that stuck with me over the years on this: You are about to pay for discord nitro, you click paypal, a malicious app positions a window that looks exactly like the one you were on, on top of discord, you type your passwords, you pay and wait. Turns out that app just emptied your account.

  • "But I would notice", you are not the only user
  • "But malicious apps can already do XYZ", a compositor can only secure so much, if someone runs with sudo a curl command someone sent them, there's nothing it can do. But thankfully there's more secure environments and distribution models out there (not crappimages)
  • "But my peepeepoopoo file manager won't work", security is more important. Many browsers don't implement APIs like the battery level one to protect user privacy, even if it breaks the epic whatsmybattery.whatever website that downloads 10mb of react
  • "This never happened", so far that we know of. Want me to be the first person to write it? "It's fine boss, nobody stole our data yet so we don't have to secure our database"

@Consolatis
Copy link

Consolatis commented Jul 28, 2025

So allow me to repeat one of the many arguments that stuck with me over the years on this: You are about to pay for discord nitro, you click paypal, a malicious app positions a window that looks exactly like the one you were on, on top of discord, you type your passwords, you pay and wait. Turns out that app just emptied your account.

I am sorry but I don't buy this argument, like at all.

  • such an application would need to end up on the system and getting started in the first place
  • the application would need to know when the user clicks on something (and in your example even *within* an application)
  • the application would need to know the exact position of the discord window
  • the application would need to know the exact content of the discord window
  • being able to set the position doesn't matter at all in this scenario because the application can simply maximize and use transparent backgrounds and potentially input regions in some parts

Don't get me wrong, in my opinion not providing clients with the option to move their window somewhere has all sorts of long term benefits for the user (like deterministic UI / UX) but those completely broken security examples are just a bad excuse. A similar argument is often used to confirm the restrictions of fullscreen surfaces not being allowed to have partly transparent backgrounds. That argument is just nonsense in my book and unnecessarily breaks completely valid use-cases like half transparent fullscreen terminal emulators.

@affhp
Copy link

affhp commented Jul 28, 2025

Use case 1:

First of all, you are derailing the conversation again, you saw a trigger word and couldn't hold yourself back from posting your copypasta. We were talking about apps remembering their last position and size when starting up. The person I replied to argued that apps should remember it themselves, I argued that the compositor should do it automatically.

https://en.wikipedia.org/wiki/Palette_window

The screenshot shows the pallette inside the main window. GIMP already does a similar thing with their dialogs, use the resize tool for example. A small semi transparent dialog will show up at the top right. Your use case is not valid, a palette doesn't need to be drawn in a separate window but even if it does the app doesn't need precise control over the position, a relative "bottom left on me" is enough.

Use case 2:

Nobody cares. This is the most niche use case anyone can come up with, we won't bow down to your silly app which will have a total of 2 users (you and the person you forced to package it).

What do you want to say with that? Typing this from FreeBSD, where no systemd exists (which was part of my reason to choose it). I want my system free from anything Red Hat touched.

Once again, you failed to read what I was replying to. The person I was replying to said that they don't care about WMs since almost nobody uses them. My counter argument was that there many parts of the Unix world that everyone agrees on but there's always 2 people that go against the current that we could all ignore. Thanks for proving my point though.

Shows how arbitrarily the Wayland overlords decide what we may and may not have.

Your refusal to listen to other perspectives is the reason we are arguing here right now. You could have engaged in the conversations when they were happening but you didn't.

So allow me to repeat one of the many arguments that stuck with me over the years on this: You are about to pay for discord nitro, you click paypal, a malicious app positions a window that looks exactly like the one you were on, on top of discord, you type your passwords, you pay and wait. Turns out that app just emptied your account.

* "But I would notice", you are not the only user

* "But malicious apps can already do XYZ", a compositor can only secure so much, if someone runs with sudo a curl command someone sent them, there's nothing it can do. But thankfully there's more secure environments and distribution models out there (not crappimages)

* "But my peepeepoopoo file manager won't work", security is more important. Many browsers don't implement APIs like the battery level one to protect user privacy, even if it breaks the epic whatsmybattery.whatever website that downloads 10mb of react

* "This never happened", so far that we know of. Want me to be the first person to write it? "It's fine boss, nobody stole our data yet so we don't have to secure our database"

TLDR
Is this what you are trying to say?
d34c9134-9617-4f9c-852f-15041bed4cb8

@xgui4
Copy link

xgui4 commented Jul 28, 2025

@probonopd did you try hyprland or any wayland compositor in 2025 ?

@reaperx7
Copy link

reaperx7 commented Jul 28, 2025

Then again, please tell me how a X11 client can restore its size and position in tiling window managers. The window manager can do that, can the client do it?

Easy... Let's pick on OBS...

Add the protocol to support last window size and placement coordinates and then use this:

/etc/OBS/OBS.ini

There... made it simple for you. The app can have support internally. That's what /etc is for. A registry. A global application registry. If not, then you have:

/home/user/.OBS/OBS.ini

for per account local settings for applications.

All the protocol has to say is, in .ini file save X/Y coordinates as:
X:0
Y:1280
Res:768
Screen:0

I'm pretty sure this is self explanatory with X:0 being the upper left corner of Screen:0.

@Loonekud
Copy link

I am sorry but I don't buy this argument, like at all.

There's a reason I said "that stuck with me". You can browse the decade old discussions on this issue to hear more perspectives.

such an application would need to end up on the system and getting started in the first place

Something I agreed with GNOME Wayland members on the icons protocol was that giving apps the ability to change icons to whatever they wanted at runtime could lead to situations where they impersonate other apps and was personally in favour of having them define their icons in their .desktop files in advance, so distributions can review them.

What I'm saying it that an innocent-looking app can easily impersonate another.

the application would need to know when the user clicks on something (and in your example even within an application)

My example wasn't the best, but this could also happen with network monitoring for discord.com => paypal.com or without user interaction e.g. "Alert! Your Nitro is about to expire, click here to renew".

the application would need to know the exact position of the discord window

Since probono is arguing against portals, an app could take a screenshot but otherwise your next point also applies on position detection, an app could position based on a click on a transparent window.

being able to set the position doesn't matter at all in this scenario because the application can simply maximize and use transparent backgrounds and potentially input regions in some parts

The problem with that is that 1. if focus security is implemented correctly the app couldn't have stolen it / propped itself to the top. 2. It would make it easier to notice (user wouldn't be able to interact with discord, clicking 'pay' or anywhere would do nothing etc.)

@sertraline
Copy link

Use case 2:

Nobody cares

:) the lack of self-awareness here is incredible, but it was expected.

@probonopd
Copy link
Author

Use case 2:

Nobody cares

This is the main problem with Wayland. The people designing a window server should NOT make assumptions about how the application level ought to work or not work.

And I care a lot. I want to recreate a user experience similar to the Mac. And for this, this feature is essential.
it is a shame that to this day Gnome and KDE don't remember their window position and configuration when you copy/move around folders - but it is totally inacceptable that some Wayland overlords deny me the possibility to implement it in my spatial file manager.

Logical conclusion: I am developing my stuff on FreeBSD with XLibre.

@Ro-Den
Copy link

Ro-Den commented Jul 28, 2025

So allow me to repeat one of the many arguments that stuck with me over the years on this: You are about to pay for discord nitro, you click paypal, a malicious app positions a window that looks exactly like the one you were on, on top of discord, you type your passwords, you pay and wait. Turns out that app just emptied your account.

@Loonekud Such a functionality may be used for good - to hide unwanted content (commercial propaganda, gore, porn, spam, etc). Even a kid with modern hardware (needed only to train some AI/DL/ML model) and modest programming experience can implement it with X11. Sooner or later I'll have to implement it myself due to the deprecation of MV2 by one of KDE's top sponsors. And it will be more fair for everybody except those who sell their crap by polluting our brain.

@probonopd
Copy link
Author

probonopd commented Jul 28, 2025

The flawed concept to begin with is to assume that it is the display server's job to worry about "malicious apps".

That needs to be handled on a whole different level of the system imho.

@kkmzero
Copy link

kkmzero commented Jul 28, 2025

A lot was said about "what ifs" and Wayland proponents try to pre-game situations when you might have malicious application doing whatever but at the same time you have Linux distros putting limits on what application is your ordinary clueless user able to install. It seems that distros like Ubuntu or Fedora want you to install curated snaps/flatpaks from those app centers. While containerization is spreading, Ubuntu also introduced some sort of additional mechanism which is supposed to protect you from running random unverified apps, I don't remember the details exactly. I think similar mechanisms will be adopted by other distributions. Security is important more than ever but isn't Wayland trying to do "too much" here? After all, malicious applications are responsibility of people who distribute software to users anyway. It's like if Khronos would not support rendering via Vulkan because you might be able to color pixels into inappropriate or malicious things. It's not their responsibility though, so they give us everything we might need instead (unlike Wayland).

@affhp
Copy link

affhp commented Jul 28, 2025

It is so funny to see that when talking about preserving window position, some people are trying hard to steer the conversation to the direction to talk about tiling window manager and completely ignore stacking window manager (which is what most people are using).

@affhp
Copy link

affhp commented Jul 28, 2025

Definition of malware in wikipedia:

Malware (a portmanteau of malicious software)[1] is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy.

All malware work well to do such things by design.

@ismaell
Copy link

ismaell commented Jul 28, 2025 via email

@darkhog
Copy link

darkhog commented Jul 28, 2025

It is so funny to see that when talking about preserving window position, some people are trying hard to steer the conversation to the direction to talk about tiling window manager and completely ignore stacking window manager (which is what most people are using).

Waydiots be like that. They either are "but think about the tiling WMs" or "but think about the security". Point is that if a malicious app wants to do malicious stuff, it will find a way. No need to make legitimate app devs suffer in the name of "security". In fact, security should be the end user's responsibility, just like installing a lock in a house is.

@xgui4
Copy link

xgui4 commented Jul 28, 2025

@xgui4 commented on this gist:
can someone create a wayland compositor but without the annoying freaking security that i hate ?
Theoretically, yes.

it will be awesome, cause x11 is kinda old but wayland is new but restricted and wallgarden like

@reaperx7
Copy link

Definition of malware in wikipedia:

Malware (a portmanteau of malicious software)[1] is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy.

All malware work well to do such things by design.

Most malware nowadays targets access points, not userland functions. Look at xz. The malware payload was designed to target a specific build of OpenSSH that used a patch that was out of tree.

An access point. Linux systems vary too much except certain patch sets that often get duplicated to parity features and abilities. There's no point to attacking the userland that may or may not have Xservers or any UI system at all. You go after an access point almost always around... Like OpenSSH.

Attacking X would be the work of someone with an IQ of -0.

@JRRandall
Copy link

Definition of malware in wikipedia:

Malware (a portmanteau of malicious software)[1] is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy.

All malware work well to do such things by design.

Wayland is malware but we already knew that.

@xgui4
Copy link

xgui4 commented Jul 28, 2025

Definition of malware in wikipedia:

Malware (a portmanteau of malicious software)[1] is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user's computer security and privacy.

All malware work well to do such things by design.

Wayland is malware but we already knew that.

wayland is not malware, i use it and nothing wrong happened... this is nonesense some anti-wayland propanganda. without wayland you wont be able to use any gui app if no other display server are installed.

how is this malware :
image

@xgui4
Copy link

xgui4 commented Jul 28, 2025

if this happen to happened to wayland , maybe we could consider as a malware, but even then that will be a stretch
https://www.reddit.com/r/unixporn/comments/1geuz3b/oc_made_an_activate_linux_overlay/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment