Think twice about Wayland. It breaks everything!

Wayland.md

Think twice before abandoning X11. Wayland breaks everything!

tl;dr: Wayland is not "the future", it is merely an incompatible alternative to the established standard with a different set of priorities and goals.

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	?	?
RAM 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, theoretically better (debatable, comment) 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) - but applications can be blurry
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), 2 Years Later Wayland Is Still Debating A Basic Feature
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.

• raspberrypi/bookworm-feedback#149 (comment) ❌ broken since at least Nov 17, 2023 ("window sharing not being available in wlroots derived compositors (such as wayfire)")
• flathub/us.zoom.Zoom#22 Zoom ❌ broken since at least 4 Jan 2019. ("Can not start share, we only support wayland on GNOME with Ubuntu (17, 18), Fedora (25 to 29), Debian 9, openSUSE Leap 15, Arch Linux"). No word about non-GNOME!
• https://community.zoom.com/t5/Meetings/Screensharing-only-works-on-GNOME-wayland-when-it-should-work-on/m-p/64823 Zoom ❌ Still broken as of 24 Jun 2022. ("... we only support Wayland on Gnome with Ubuntu 17 and above, Fedora 25 and above, Debian 9 and above ...")
• probonopd/Zoom.AppImage#8 ❌ broken since 1 Oct 2022 Zoom: "You need PulseAudio 1.0 and above to support audio share" on a system that uses pipewire-pulseaudio

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)

• https://gitlab.com/lestcape/Gnome-Global-AppMenu/-/issues/116 ❌ 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 ❌ 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.")

Wayland broke global menus with KDE platformplugin

• 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

Wayland breaks global menus with non-KDE Qt platformplugins

• https://blog.broulik.de/2016/10/global-menus-returning/ ❌ broke non-KDE platformplugins. As a result, global menus now need _KDE_NET_WM_APPMENU_OBJECT_PATH which only the KDE platformplugin sets, leaving everyone else in the dark

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

• https://wiki.archlinux.org/index.php/redshift ❌ broken ("Redshift does not support Wayland since it offers no way to adjust the color temperature")

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

Wayland breaks global hotkeys

• albertlauncher/albert#309 ❌ broken since 7 Jan 2017 ("This is a security measure, but has the side effect of preventing applications from registering their own global hotkeys") YouTube video by René Rebe

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

• https://cfenollosa.com/blog/fed-up-with-the-mac-i-spent-six-months-with-a-linux-laptop-the-grass-is-not-greener-on-the-other-side.html ❌ broken since at least 02 Apr 2021 ("Screen tearing with the intel driver. Come on. This was solved on xorg and now with Wayland it's back.")

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

• https://phabricator.kde.org/D16648#470609 ("Wayland clients can't raise or activate themselves"), ❌ broken since May 27 2019

Wayland breaks RescueTime

• https://help.rescuetime.com/article/117-common-linux-issues ("One of the features of Wayland is that it prevents apps from doing precisely what RescueTime is trying to do—track activity in other windows.") ❌ broken since June 3, 2021

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

• https://gitlab.freedesktop.org/wayland/wayland/-/issues/233

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

• AppImage/AppImageKit#1221 (comment) ❌ broken since 2022-20-15 ("Espanso built for X11 will not work on Wayland due to 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.

Wayland breaks SUDO_ASKPASS

• https://github.com/linuxhw/hw-probe-pyqt5-gui/commit/eb2d6e5145fb8571414bda57676084b7f13b94e5#diff-23cb15995f1502beebb38433bfa83204a5f45b376eaf88e2e41a0d8a1cd44722R290 ❌ broken since 2022-04-09 ("SUDO_ASKPASS doesn't work on Wayland currently, so piping the password")

Wayland breaks auto-type in password managers

• keepassxreboot/keepassxc#2281 ❌ broken since 11 Sep 2018 (crude, Linux-only workaround: https://keepass.info/help/kb/autotype_wayland.html)

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

• "Unfortunately not all Wayland compositors support DRM leasing" https://help.steampowered.com/en/faqs/view/18A4-1E10-8A94-3DDA - "not all" highlights one of the fundamental problems with Wayland - there is fragmentation

Wayland breaks In-home Streaming

• ValveSoftware/steam-for-linux#6148 ❌ broken since 2019-03-17

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

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

Wayland breaks drag and drop

• On Raspberry Pi OS (which is running a Wayland session by default), dragging a file out of a zip file onto the desktop fails with "XDirectSave failed."
• The same seems to be true in Gnome: https://discourse.gnome.org/t/xdnddirectsave-and-wayland/2954

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

• https://www.youtube.com/watch?v=8G9zX8CkGTY

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.

• Asahi Linux enforces Wayland for ARM-based Macs: https://social.treehouse.systems/@marcan/110354541574112092
• Fedora enforces Wayland for KDE Plasma: https://fedoraproject.org/wiki/Changes/KDE_Plasma_6#Why_drop_the_X11_session_with_the_Plasma_6_upgrade?
• Red Hat enforces Wayland for RHEL:https://www.redhat.com/de/blog/rhel-10-plans-wayland-and-xorg-server
• Gnome has announced to drop X11 support, forcing Wayland onto people
• Fedora has announced to drop X11 support for the default (Gnome) version, forcing Wayland onto people
• Ubuntu has decided to drop X11 support for the default (Gnome) version, forcing Wayland onto people

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

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

• Dudemanguy's Musings, Wayland Isn't Going to Save The Linux Desktop
• Chris Titus Tech: Wayland vs Xorg https://www.youtube.com/watch?v=U_MBJcD3SFI
• tildearrow: did somebody say "anti-Wayland horseshit"?
• pcsx2: CI/Linux: Disable Wayland and spring cleaning
• Testing SCREEN RECORDERS on Linux Mint Wayland
• ProtonPenguin: Wayland Breaks Everything
• KDE: https://community.kde.org/Plasma/Wayland_Known_Significant_Issues
• Are we XLibre yet?
• The Trouble with Wayland
• 2 Years Later Wayland Is Still Debating A Basic Feature

One giant wall of strawmen. I have a pretty modern and decent rig. 16 core ryzen, 128GB RAM, and a 4090. The only "obscure" piece of hardware I have is a wacom tablet lol. It's software that is the biggest issue. Under wayland, substance painter can't even manage to cache the icons of my material library without crashing. Houdini runs like garbage, worse than on windows even. Blender the same story. These aren't exactly obscure software nobody uses, it's industry standard stuff. My hardware is not the problem, considering I used to run all that shit on a 8 core ryzen with 16BG RAM and a 2060 on windows and on x11 with no issues.

Seriously, he should see the Xeon and EPYC systems that utilize 2D display systems for basic SVGA. Old VGA accelerators are still in heavy supply from AMD, Nvidia, VIA, etc, and ASpeed isn't old either. Threadripper Pro systems have them as part of their SOC management system. Plenty of workstations using Computational Accelerator cards don't have GeForce, Arc, or Radeon cards in them. They don't need them, but they do need a working DDX 2D acceleration system to actually do work. Servers never have 3D accelerators except computational cards. Like get real man. He should learn about real IT before trying to mouth off to actual IT professionals.

Then the same complaints that you about a compositor needing to provide functionality would instead be functionality that's allowed or disallowed by the distro.

No, it’s just whether the distro packages it.

So it’s not worse than having to install an external package today: flatpaks, appimages, … already don’t work like distro-provided programs.

And X11 prevents Flatpaks from fully doing the job of sandboxing an application because it can't prevent other applications from capturing it's input or viewing it's contents.

Both Qubes and SELinux Sandbox already provided that in 2011 by running sub x-servers (the latter used Xephyr).

That’s just inventing complexity instead of using a system that already works.

Except it isn't inventing complexity. If the window automation protocol makes incorrect assumptions about how a window manager manages its windows then

There is no "if": those tools already work. With a wide variety of desktop environments.

The pure x11 tools are the ones which used to work across the whole range of window managers -- from dwm over lxde to KDE and Gnome.

What do you think why quite a few old-timers chose exactly those for their automations -- and are now hit hardest?

¹ my personal judgement, not an absolute truth. Partly informed by seeing how xcb resolved X11’s most glaring painpoint: the slowness due to xlib being synchronous. …

XCB only resolved an issue with it's client-side library. Wayland was not created just to resolve performance issues …

That was a large part of Waylands appeal for users (I hoped for it back then). And it fell flat after xcb adoption proved that X11 already supported that quite well: the issue was one with the client library that could be solved at that level while continuing gradual evolution.

And that is OK. They have expectations that things keep working. Justified expectations. No amount of theoretical argumentation changes that.

No one is even saying that they need to accept some kind of loss of functionality …

That’s false. If that was the case I wouldn’t mind Wayland.

But once real, provable problems are reported, they are dismissed as "that’s life".

To quote:

they have to rip up parts of their program just to keep it working. And they can’t, because it requires more free time than they have available.
This is a general problem: volatile infrastructure. Others also caused such problems … but Wayland managed to do that worse than every system that came before (that I experienced in the past 20 years).

Honestly. That's tough but that's life.

People absolutely say that others "need to accept some kind of loss of functionality". Not just people: you do. You then just go and put blame on others. But whom you blame doesn’t change that you expect people to "accept some loss of functionality".

This is the core reason why volatile infrastructure is a problem.

What.the.fuck.is.all.this.shitstorm.about lol.

Nobody takes X.Org from you, go touch some grass.

If this wall of text is your attempt to discredit or belittle my experience, then you're trolling.

They're not. If you read any of it and had decent reading comprehension then you'd see that.

I'm not even going to read through all that blathering because I already know you're trying to dismiss and discredit without even attempting to understand every person's experience is different.

Oh so you're admitted that you didn't read any of it and would prefer to make shit up lol

Do us a favor and just leave. You have no place here.

Nope. I'm staying :-) I mean what's your purpose here? You don't read anything and you don't contribute anything.

One giant wall of strawmen. I have a pretty modern and decent rig. 16 core ryzen, 128GB RAM, and a 4090. The only "obscure" piece of hardware I have is a wacom tablet lol. It's software that is the biggest issue.

So lets see what issues you think are Wayland issues. Btw, Wayland basically has built-in support for Wacom tablets through libinput.

Under wayland, substance painter can't even manage to cache the icons of my material library without crashing.

This has nothing to do with Wayland or X11. Any code that Substance Painter has relating to icon caching would be internal to the program and wouldn't even have different code paths for each code path.

Houdini runs like garbage, worse than on windows even.

Without any specifics, I couldn't tell you what causes that.

This and substance painter both run in Wayland sessions through XWayland (a tested Xorg server) so you could be running into XWayland issues. Perhaps it has something to do with the GLX to EGL conversion stuff.

Blender the same story.

I use Blender. It's the only software you mentioned so far that actually runs as a native Wayland client and I don't know what issues you're referring to. Are you running it as a native Wayland client or are you running it through XWayland?

These aren't exactly obscure software nobody uses, it's industry standard stuff. My hardware is not the problem, considering I used to run all that shit on a 8 core ryzen with 16BG RAM and a 2060 on windows and on x11 with no issues.

Luckily I wasn't directing about obscure use cases at you. I see you have a 2060 though, which may be part of the issue. Nvidia has historically been behind on supporting the kernel and Mesa APIs that all of the other Linux graphics drivers use. My understanding is that they built their drivers around specifically supporting Xorg. In the past 4 or so years they started implementing things like DMA-buffer, GAMMA_LUT, and GBM but as I understand there's still some issues.

When I last used Nvidia few years ago I know that it's EGL support wasn't great and since they didn't support implicit sync (the whole Linux graphics stack was implicit sync at that time) and only emulated it through their driver, it caused syncing issues within XWayland that resulted in interfaces flashing like crazy or frames being shown out of order.

Seriously, he should see the Xeon and EPYC systems that utilize 2D display systems for basic SVGA. Old VGA accelerators are still in heavy supply from AMD, Nvidia, VIA, etc, and ASpeed isn't old either.

You specifically said :

"You have servers with video displays running Rage64, ASpeed, S3, VIA, etc"

The Rage64 was released in the late 1990s by ATI, a company that was acquired by AMD 20 years ago. S3 hasn't been around since 1999.

Threadripper Pro systems have them as part of their SOC management system. Plenty of workstations using Computational Accelerator cards don't have GeForce, Arc, or Radeon cards in them. They don't need them, but they do need a working DDX 2D acceleration system to actually do work. Servers never have 3D accelerators except computational cards. Like get real man. He should learn about real IT before trying to mouth off to actual IT professionals.

Hey, baby brain. I'm aware that most servers don't have 3D accelerators. Most servers are run headless and are accessed from remote terminals that are responsible for providing the UI. The servers themselves don't render their GUI themselves or run display servers.

The issue is that you specifically brought up using GPUs that came out nearly 30 years ago in a server to try to make the point that Xorg is better for desktop use cases in 2026 than Wayland.

Is anybody trying to run Gnome or KDE Plasma on an Aspeed chip in a server? No.
Do any of the app issues mentioned in the OP apply to a server scenario? No.

"hE sHoUld lEarN aBoUt reAl IT" You forgot what the topic was even about, clown lol

Seriously, he should see the Xeon and EPYC systems that utilize 2D display systems for basic SVGA. Old VGA accelerators are still in heavy supply from AMD, Nvidia, VIA, etc, and ASpeed isn't old either.

You specifically said :

"You have servers with video displays running Rage64, ASpeed, S3, VIA, etc"

The Rage64 was released in the late 1990s by ATI, a company that was acquired by AMD 20 years ago. S3 hasn't been around since 1999.

Threadripper Pro systems have them as part of their SOC management system. Plenty of workstations using Computational Accelerator cards don't have GeForce, Arc, or Radeon cards in them. They don't need them, but they do need a working DDX 2D acceleration system to actually do work. Servers never have 3D accelerators except computational cards. Like get real man. He should learn about real IT before trying to mouth off to actual IT professionals.

Hey, baby brain. I'm aware that most servers don't have 3D accelerators. Most servers are run headless and are accessed from remote terminals that are responsible for providing the UI. The servers themselves don't render their GUI themselves or run display servers.

The issue is that you specifically brought up using GPUs that came out nearly 30 years ago in a server to try to make the point that Xorg is better for desktop use cases in 2026 than Wayland.

Is anybody trying to run Gnome or KDE Plasma on an Aspeed chip in a server? No. Do any of the app issues mentioned in the OP apply to a server scenario? No.

"hE sHoUld lEarN aBoUt reAl IT" You forgot what the topic was even about, clown lol

Oh look the wannabe IT professional can use Google or ChatGPT to form an argument... 😂

No, it’s just whether the distro packages it.

Which creates the same issue. One of the complaints about Wayland that keeps getting mentioned on this topic (and it's overstated compared to the reality) is that someone may work on one compositor and not another if a compositor decides not to implement a certain protocol.

In the idea you brought up, that would apply per distro because some applications may have some functionality on distro and no on others based solely on whether not the distro packaged it or not.

So it’s not worse than having to install an external package today: flatpaks, appimages, … already don’t work like distro-provided programs.

How so?

Both Qubes and SELinux Sandbox already provided that in 2011 by running sub x-servers (the latter used Xephyr).

Yes and I imagine XNamespace does the same thing. The issue then becomes that those applications can't provide screen capture, global shortcut, or window automation functionality at all... unless they use portals just like a Wayland app would.

I mean correct me if I'm wrong here: running an application in their own nested Xservers would not only be slower because it's running multiple Xservers simultaneously, but it would also completely break certain functionality. I think that might even include DND though I'm not sure.

There is no "if": those tools already work. With a wide variety of desktop environments.
The pure x11 tools are the ones which used to work across the whole range of window managers -- from dwm over lxde to KDE and Gnome.

Yea, they work well in a wide variety of desktop environments that use stacking window managers. XTest assumes that windows can move freely and stack, two things that don't happen in tiling or scrolling window managers. What do you think happens in those cases?

What do you think why quite a few old-timers chose exactly those for their automations -- and are now hit hardest?

I guess those old timers don't use tiling window managers?

That was a large part of Waylands appeal for users (I hoped for it back then). And it fell flat after xcb adoption proved that X11 already supported that quite well: the issue was one with the client library that could be solved at that level while continuing gradual evolution.

Again, Wayland wasn't created just to resolve performance issues. XCB wouldn't remove the need for something like Wayland to exist because it still doesn't fix any of the other issues with X11 that it's extensions were working around for ages.

That’s false. If that was the case I wouldn’t mind Wayland.

But once real, provable problems are reported, they are dismissed as "that’s life".

I literally linked to things that can do automation in Wayland and one of them is done in an display server agnostic way.

Also you've straight up ignored every issue with X11 that I've brought up.

Before you mentioned a solution for properly sandboxing applications in X11 which required running each application in it's own nested XServer which would be slow and break that applications functionality. Meanwhile Wayland could achieve that same sandboxing without nesting while maintaining functionality.

Honestly. That's tough but that's life.

Because that's true. You can't improve things without changing something. Wayland can't do anything about life getting in the way of a developer being able to maintain an application.

People absolutely say that others "need to accept some kind of loss of functionality". Not just people: you do. You then just go and put blame on others. But whom you blame doesn’t change that you expect people to "accept some loss of functionality".

I literally didn't. If you read ANYTHING I said, then you wouldn't be making up this bullshit.

I said that there were thing that were broken about X11 that couldn't be fixed without breaking the core protocol, which is why Wayland exists and why it can't maintain backwards compatibility with X11 while still fixing those issues.

You mentioned your fear of losing input automation and told you about things that do that in Wayland. Others mourned the death of screen sharing and global shortcuts under Wayland even though Wayland applications absolutely CAN do those things. The OP complained about DND under Wayland even though Wayland has support for DND in the core protocol.

What loss of functionality are you talking about?

What's happening is that everyone whose been defending X11 in this topic feels that everyone should perpetually ignore any issues with X11 just so that a single bit on their hard drive doesn't have to be changed and they don't need to learn about anything remotely new to them.

Apparently fixing X11's issues with multi-monitoring isn't important and should be ignored forever. Apparently X11's issues with DPI scaling should be ignored forever. Apparently X11's issues with frame tearing aren't important and should be ignored forever. There's literally people in this topic saying that X11's security issues aren't important and should be ignored forever.

Also don't think that I didn't notice that any time I actually explain any technical issue with X11 you pretend that I didn't say it or drop that part of the conversation.

You said the only reason that certain issues weren't fixed in X11 was because X11 was abandoned. I explained exactly how X11s multi-monitoring worked, named the issues it creates, explained how they unfixable, and from the explanation it should have been obvious how it's extensions have been working around issues with the core protocol for awhile. Did you correct me about any of that? Nope. Did you concede that point? Nope. Did you have anything to say about it? Yep, you responded with two posts that talked about everything BUT that. You even made an effort not to quote those parts.

You asked me to imagine a scenario where Wayland was backwards compatible with X11. I did that and you dropped that conversation, too. No rebuttal at all.

You did it in this post, too. I explained how X11 is overly complex architecturally for the purpose it serves then I gave an example with DRI3. Did you mention that? Nope. Instead you quoted "XCB only resolved an issue with it's client-side library. Wayland was not created just to resolve performance issues" and then conveniently turned all the technical discussion about X11's very real problems in an ellipses so you would have to respond to it.

Gee, I wonder why this topic is never technical and is always about some other shit. Maybe it's because of shit like that. Can't talk about the merits of the tech, we gotta talk about life shit and sob stories instead.

This is the core reason why volatile infrastructure is a problem.

I'm not gonna read your blog post about fear of change that's mascarading as a cautionary article. All I have to do is read as far as "I stayed mostly silent on this for a long time, hoping that people would figure out how to get it right without disrupting other tools," to know that it's not worth reading.

You're have no idea if what you want is even possible but you are gonna complain if others can't achieve it for you. I presented a bunch of X11's issues to you that were the reasons for Wayland coming about but you seem to be sure that X11/Wayland/s devs could have fixed all of them in a backwards compatible way. So why don't you mention how?

Oh look the wannabe IT professional can use Google or ChatGPT to form an argument... 😂

Self-report? Did ChatGPT tell you that Wayland has something to do with file system permissions? Where else would you have gotten that? lol

You can't respond to shit lol All you have is insults, conspiracy theories, and troll responses.

Oh look the wannabe IT professional can use Google or ChatGPT to form an argument... 😂

Self-report? Did ChatGPT tell you that Wayland has something to do with file system permissions? Where else would you have gotten that? lol

You can't respond to shit lol All you have is insults, conspiracy theories, and troll responses.

Dude you respond to everything in a wall of text like you think we're going to read all of that and actually care. All you do is repeatedly try to project on to us what YOU feel we're wrong about. Read it again, all you have done is make this about you and your feelings towards wayland.

We don't care about wayland and what it does or doesn't do. You can go wipe your butt with wayland and every wayland compositor out there because we will shit on wayland all day long. We've tried it, used it, and we found nothing but problems. What makes you think for 2 seconds we give a flying shit about some pro-wayland blabbermouth parrot coming in here and trying to preach a sermon like a southern Baptist pastor about how wrong we are? Right? Wrong? WE DON'T CARE!

We hate wayland dude, and we don't give a crap about it. There's nothing you can say to change our minds on it. Again, YOUR USE CASE IS NOT OURS! Learn to read the room.

There is no "if": those tools already work. With a wide variety of desktop environments.
The pure x11 tools are the ones which used to work across the whole range of window managers -- from dwm over lxde to KDE and Gnome.

Yea, they work well in a wide variety of desktop environments that use stacking window managers. XTest assumes that windows can move freely and stack, two things that don't happen in tiling or scrolling window managers. What do you think happens in those cases?

What do you think dwm is?

I said that there were thing that were broken about X11 that couldn't be fixed without breaking the core protocol, …

And I showed you the approach to fix them and the projects that did.

To disprove "couldn’t", all that’s needed is an example that did. I showed you two.

I'm not gonna read …. All I have to do is read as far as …

Goodbye.

Dude you respond to everything in a wall of text like you think we're going to read all of that and actually care. All you do is repeatedly try to project on to us what YOU feel we're wrong about. Read it again, all you have done is make this about you and your feelings towards wayland.

Except I never did that. You straight up said you didn't read my posts and now you're trying to say what's in them? lol Those "walls of text" (they're separated into paragraphs) have sentences in them that explain things. You would know this if you were the learning and reading type lol

We don't care about wayland and what it does or doesn't do.

That's what this whole topic has been about for 6 years, genius. The OP literally has table that tries to compare functionality between Wayland and X11 lol

What makes you think for 2 seconds we give a flying shit about some pro-wayland blabbermouth parrot coming in here and trying to preach a sermon like a southern Baptist pastor about how wrong we are?

Gee, my mistake. I thought you had reasons that you were against Wayland and Probo kept on saying this topic was about improving Wayland. Shucks, maybe if I didn't read anything ever then I'd be just like you. /s

We hate wayland dude, and we don't give a crap about it.

These two things can't both be true at the same time lol You either care and spend all your time hating on it (which is what you're doing) or you don't... in which case you wouldn't be here.

Again, YOUR USE CASE IS NOT OURS! Learn to read the room.

Learn how to read lol I never said that your use cases (what other person here has expressed your same use case?) was one where you should or needed to start using Wayland. I was grounding my argument in reality lol

I will repeat. Did ChatGPT tell you that Wayland had something to do with file permissions?

What do you think dwm is?

Despite it's name, DWM just a compositor and does not handle any window management. All of the things that you would define as functionality of display server are done by multiple other parts of Win32.

You can look at the list of DWM functions and messages on Microsoft's website to see how an application would interact with it.

https://learn.microsoft.com/en-us/windows/win32/dwm/reference

You can even see in Microsoft's documentation that "Windows and Messages" is in a separate section than "Desktop Window Manager".

https://learn.microsoft.com/en-us/windows/win32/windows-application-ui-development

And I showed you the approach to fix them and the projects that did.
To disprove "couldn’t", all that’s needed is an example that did. I showed you two.

You did? Where?

The closest I could find was when you mentioned SELinux and Qubes achieving sandboxing. That was right after I had mentioned that XACE could do that it but it would break app functionality. Then when I responded and pointed out that the solutions you mentioned would have the same issues as XACE plus performance issues, you deciding to drop that discussion.

You definitely didn't mention any solutions for multi-monitoring and scaling because none of your posts use the words "scale", "scaling", "DPI", "multi-monitoring" or anything similar.

Goodbye.

Oh so you don't like when I ignore things that you write but when you do it my posts, that's okay? You'd rather leave then actually respond? I'm good with that lol

I'm just gonna mute this thread. When I joined it initially, I had just a few issues with the Wayland. I wanted to switch to it and never liked xorg, but there were just a few things keeping me switching back. I asked repeatedly in hopes someone was able to help, but it was drowned out by pissing contests where no one listens to each other and just insults each other all day.

Nobody wants to provide answers. This thread is clearly just being used as an argument theater where neither side is actually listening. Good-bye.

I'm just gonna mute this thread. When I joined it initially, I had just a few issues with the Wayland. I wanted to switch to it and never liked xorg, but there were just a few things keeping me switching back. I asked repeatedly in hopes someone was able to help, but it was drowned out by pissing contests where no one listens to each other and just insults each other all day.

I had to scroll back awhile to find out what your OBS issue was. If you still wind up seeing this somehow, you should open up an issue with OBS or with the xdg-desktop-portal. What's happening is that either OBS is deciding to prompt you again when the connection doesn't exists or that's a behavior of the portal.

Nobody wants to provide answers. This thread is clearly just being used as an argument theater where neither side is actually listening.

I definitely agree that this thread is unproductive.

What do you think dwm is?

Despite it's name, DWM just a compositor and does not handle any window management. All of the things that you would define as functionality of display server are done by multiple other parts of Win32.

If you have no clue, just admit it instead of trying to (however you found your false answer).

dwm is the iconic tiling window manager by suckless, written in under 2000 lines of C.

Goodbye because you first complain that I didn’t answer every falsehood in your wall of text (no need to magnify the noise) and then add that you won’t read an article on the topic because you don’t like the intro (it shouldn’t be a surprise that it criticizes Wayland).

With that there may be space again for more productive discussions.

XACE was pretty much like Wayland security model: "block unless allowed". XNamespace is "allow unless prohibited."

Thanks you for being the one to finally answer one of my questions about the actual protocols.

Are the permissions per namespace or are there per-application permissions as well? Do applications needs to be within the same namespace in order for one of app to capture another's window?

I don't know the answer for the first question, as far as the second one goes, yes, both apps have to be in the same namespace OR the capturing app has to be in the higher namespace (you can create hierarchies of namespaces) to capture another app's window.

If you have no clue, just admit it instead of trying to (however you found your false answer).

dwm is the iconic tiling window manager by suckless, written in under 2000 lines of C.

I apologize. I don't know how but I got my wires crossed and thought you were responding to when I said that "Windows and MacOS don't have anything equivalent to X11 or Wayland" so I thought you were referring to Desktop Window Manager in Windows. That's entirely my fault.

Goodbye because you first complain that I didn’t answer every falsehood in your wall of text (no need to magnify the noise)

Well no, I complained that you didn't respond to anything technical that I said and that's true. If they were false hoods then you would made an effort to disprove them instead of ignoring them entirely.

and then add that you won’t read an article on the topic because you don’t like the intro (it shouldn’t be a surprise that it criticizes Wayland).
With that there may be space again for more productive discussions.

No. I'm not gonna read an article that you wrote as if it's some sort of informed outside opinion to this conversation. You linked to that multiple times and never even say that it was your article. Even in this post you said it's an article. It's not an it's your article.

Also "volatile infrastructure" has an actual meaning. It's not a term for you to apply to whatever you don't like.

It refers to a dependency that frequently makes breaking changes.

That would apply to Gnome's Extension API but it's not applicable to an ecosystem slowly migrating from one display server protocol to another. The migration to Wayland has been happening over 14 years. The transition to Wayland started around the same time that Windows 8 came out. It's only in the past few months that a single DE dropped support for a native Xorg session but even that still maintains backwards compatibility with X11 apps through XWayland. Nothing was suddenly swapped from beneath you without warning.

Wayland itself does not see frequent, breaking changes. The core protocol has not had any breaking changes and one of the one of the biggest criticisms of Waylands development is that it's been slow and extensions take a long time to get merged. The session restore protocol is a great example. It was only merged 2 months ago but it was in development for 6 years.

If you want to argue that Wayland should have and could have been backwards compatible then that's a technical argument that completely unrelated to the concept of "volatile infrastructure".

Also "volatile infrastructure" has an actual meaning. …
It refers to a dependency that frequently makes breaking changes.

Not a dependency, but the infrastructure of which the dependency is a part.

And yes, the switch from X11 to Wayland is a breaking change. And worse: the inconsistency between XWayland and Wayland as well as incompatibility between portals and compositors cause frequent breaking changes. "Why can’t my application do X anymore?" "Because it uses X11 commands, but it is now started as Wayland application, not as XWayland one".

Working applications stop working correctly when some other application gets updated (or in this case: replaced).

And yes: my name is clearly and openly on that website. Which you would have seen directly if you had not just decided to ignore it. I consider "here’s a coherent argumentation about that part" to be much more courteous than bombarding people with a wall of text and then complaining when they don’t answer every false sentence.

Nothing … without warning.

You obviously did not read it to the end, otherwise you would have known that "without warning" would come off as just weasel wording to break something but redirect the blame.

If you want to argue that Wayland should have and could have been backwards compatible then that's a technical argument that completely unrelated to the concept of "volatile infrastructure".

No: foregoing backwards compatibility and forcing the replacement is what turns the infrastructure volatile.

PS: I’m sorry for answering again. I’ll try to ignore further comments on that, regardless of how wrong they are.

💩💩💩💩💩💩💩💩💩💩

BINEX-DSK DIED FOR YOUR SINS

Neither X11 nor Wayland can do a hecking dot inside the close button for changed files which Mac OS X has for a 3rd decade already. Neither can do drag'n'drop of the current file icon from the window title.

Both are shit, end the thread.

Also "volatile infrastructure" has an actual meaning. …
It refers to a dependency that frequently makes breaking changes.

Not a dependency, but the infrastructure of which the dependency is a part.

And yes, the switch from X11 to Wayland is a breaking change. And worse: the inconsistency between XWayland and Wayland as well as incompatibility between portals and compositors cause frequent breaking changes. "Why can’t my application do X anymore?" "Because it uses X11 commands, but it is now started as Wayland application, not as XWayland one".

Working applications stop working correctly when some other application gets updated (or in this case: replaced).

And yes: my name is clearly and openly on that website. Which you would have seen directly if you had not just decided to ignore it. I consider "here’s a coherent argumentation about that part" to be much more courteous than bombarding people with a wall of text and then complaining when they don’t answer every false sentence.

Nothing … without warning.

You obviously did not read it to the end, otherwise you would have known that "without warning" would come off as just weasel wording to break something but redirect the blame.

If you want to argue that Wayland should have and could have been backwards compatible then that's a technical argument that completely unrelated to the concept of "volatile infrastructure".

No: foregoing backwards compatibility and forcing the replacement is what turns the infrastructure volatile.

If people understood that breaking a working model is detrimental to a functionality this wouldn't be an issue. What you said basically... Xwayland is NOT X11 in any regards... Is about as hammer to nail as it gets. Xwayland doesn't work like X at all. It doesn't MouseGrab like X, it doesn't screen lock and prioritize like X11, it doesn't use X11 tools to manage it. It's not even a good attempt at a compatibility layer because it breaks stuff too.

What are your opinions on alternative x servers that aren't forks of xorg? Stuff like Phoenix or Yserver.

I want to see what Phoenix is doing honestly. Yserver has A.I. vibe code in it, so I'm skeptical of it.

Zig to me is a better language to follow up with since it's based on C and compatible with C.

I don't care what the license is, as long as control is maintained without stupidity being involved that can happen with GPLv3. We don't need "paid for Xservers" again.

I don't care what the license is, as long as control is maintained without stupidity being involved that can happen with GPLv3. We don't need "paid for Xservers" again.

I usually prefer GPL licenses, but in the case of the display server which should also be shipped on the BSDs (to have shared display infrastructure) and for that, copyleft licenses are a no-go, because OpenBSD rejects all copyleft.

Exactly, so we need MIT unfortunately. The good thing is most projects carry MIT and BSDL for display servers. It would be interesting to see if the Phoenix devs would collaborate with Xlibre and maybe implement the Xlibre work in Zig in Phoenix.

Multiple cursor support?