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")
• https://github.com/vkohaupt/vokoscreenNG/issues/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

Wayland shines again: https://www.reddit.com/r/GlobalOffensive/comments/1wlcvc1/cs2_linux_x11_vs_wayland/

Tested CS2 on Arch + KDE with the same settings, 3 runs each at 1440x1080 stretched, using the Dust2 Benchmark map

OS: Arch Linux
Kernel: linux-cachyos
Kernel version: 7.2.6-1-cachyos
NVIDIA driver: 615.71.09

CPU: AMD Ryzen 7 7800X3D
GPU: Gigabyte GeForce RTX 5070 Ti Aero OC 16GB
Motherboard: Gigabyte B650E Aorus Elite X AX Ice
RAM: Kingston Fury Beast RGB 32GB (2x16GB), DDR5-6000 CL30

X11: ~839 FPS avg / ~347 P1
Wayland: ~764 FPS avg / ~322 P1

So X11 was about 10% faster for me.

Anyone else seeing similar results on NVIDIA?

No, NVIDIA doesn't pessimize Wayland.

I've seen similar with AMD and Intel. Problem is, most results are never publicized.

Wayland shines again: https://www.reddit.com/r/GlobalOffensive/comments/1wlcvc1/cs2_linux_x11_vs_wayland/

Tested CS2 on Arch + KDE with the same settings, 3 runs each at 1440x1080 stretched, using the Dust2 Benchmark map

OS: Arch Linux
Kernel: linux-cachyos
Kernel version: 7.2.6-1-cachyos
NVIDIA driver: 615.71.09

CPU: AMD Ryzen 7 7800X3D
GPU: Gigabyte GeForce RTX 5070 Ti Aero OC 16GB
Motherboard: Gigabyte B650E Aorus Elite X AX Ice
RAM: Kingston Fury Beast RGB 32GB (2x16GB), DDR5-6000 CL30

X11: ~839 FPS avg / ~347 P1
Wayland: ~764 FPS avg / ~322 P1

So X11 was about 10% faster for me.

Anyone else seeing similar results on NVIDIA?

No, NVIDIA doesn't pessimize Wayland.

I've seen similar with AMD and Intel. Problem is, most results are never publicized.

Seems similar to what i was experiencing when i was flipping between x11 and wayland while playing satisfactory.
A 'very' slight and in the long run NOT enough of a good thing to justify wayland. and may just've been noise. is a 1-2fps higher 1% low on wayland when i did this. but i couldn't reliably reproduce it.

MIT license forbids using MIT code for profit

This is wrong. The MIT license (also known as the expat license) does allow using MIT code for profit. You can also use MIT code in GPL code. And this is done all the time. The MIT license just doesn’t ensure that projects using it as license stay free, so it’s the perfect license if you want to create a product that you can proprietarize later, even if other people contributed. Just add some proprietary parts that the rest doesn’t work well without and the project effectively becomes proprietary.
That the culture established within Rust runs counter to copyleft is a problem for Software Freedom, but MIT code itself is usable in Free Software.

That isn't the problem. Problem is that you can close MIT source code any moment and change API, so open source forks wouldn't work.

Otherwise known as 'open darwin' once the bsd folks eventually forgot that apple wholesale took bsd and stopped demanding they leave the parts they took open.

BSD never says you have to submit code back. All it says is you have to acknowledge where you got it from. Most contributors to FreeBSD do so willingly to advance the project.

If you need music I know a guy on YouTube, named ThumbTacos, who has a friend who makes license free music. I've used some of his stuff myself during livestreams.

Looks like some retro gameplay channel. Got a proper link? Also by "epic and pumpy" I meant something like what Coffeezilla, etc. are using.

Spotify - Rad Music Studios.

Wayland shines again: https://www.reddit.com/r/GlobalOffensive/comments/1wlcvc1/cs2_linux_x11_vs_wayland/

Tested CS2 on Arch + KDE with the same settings, 3 runs each at 1440x1080 stretched, using the Dust2 Benchmark map

OS: Arch Linux
Kernel: linux-cachyos
Kernel version: 7.2.6-1-cachyos
NVIDIA driver: 615.71.09

CPU: AMD Ryzen 7 7800X3D
GPU: Gigabyte GeForce RTX 5070 Ti Aero OC 16GB
Motherboard: Gigabyte B650E Aorus Elite X AX Ice
RAM: Kingston Fury Beast RGB 32GB (2x16GB), DDR5-6000 CL30

X11: ~839 FPS avg / ~347 P1
Wayland: ~764 FPS avg / ~322 P1

So X11 was about 10% faster for me.

Anyone else seeing similar results on NVIDIA?

No, NVIDIA doesn't pessimize Wayland.

I've seen similar with AMD and Intel. Problem is, most results are never publicized.

Seems similar to what i was experiencing when i was flipping between x11 and wayland while playing satisfactory. A 'very' slight and in the long run NOT enough of a good thing to justify wayland. and may just've been noise. is a 1-2fps higher 1% low on wayland when i did this. but i couldn't reliably reproduce it.

839/764 average is actually quite a large discrepancy when you deal with some game titles. That's roughly a drop of 35 FPS meaning 4.17% on average. It may be noise, but it's also a twll of the resource usage rates of wayland are affecting things.

Otherwise known as 'open darwin' once the bsd folks eventually forgot that apple wholesale took bsd and stopped demanding they leave the parts they took open.

And very different from khtml, which fought for its copyleft (though a weak one) after Apple took the code and is the reason why today all the relevant browsers have Free Software at their core, because the KDE folks managed to force Apple to adhere to the LGPL. That’s the historical reason why a small group of volunteers can release a browser today that has the same rendering capabilities as Edge or Chrome. Copyleft is not perfect protection (as cups shows), but the benefits it brings to Free Software are very valuable.

How can we expect an increase in Linux desktop adoption when something as simple as global hotkeys doesn't work out of the box?

How can we expect an increase in Linux desktop adoption when something as simple as global hotkeys doesn't work out of the box?

If the key players behind wayland aren't making it loud and clear, the end goal is to kill GNU/Linux adoption and prevent adoption. This is the age old, "we're doing great, but we need to fix something not broken and move the goal posts yet again" problem. If you boil down everything needed to make a perfect mass deployable GNU/Linux desktop, you'll find all the parts work, with the exception of wayland. Take out wayland and drop in X11, and guess what you have? The perfectly mass deployable GNU/Linux system that anyone and everyone can use without any issues, shortfalls, or problems long term.

If this was ArchLinux, it would be roughly about 2000 packages, but within those 2000 packages, everything would work out of the box. You would turn on the PC, the bootloader would fire up, load the kernel, start the services, start the login manager, enter a password, and finally, you're at your desktop where everything works perfectly. No fussing with stuff that's broken, no workarounds needed to be read in a wiki and then implemented. Everything just working. But that system only works with X11 and an X11 desktop like Cinnamon, Mate, Xfce, Trinity, and Sonic. Outside of that, the system breaks, and the desktop isn't useable.

This is what wayland has done to the Year of the Linux Desktop. Another setback. And honestly, it feels deliberately done.

If I had the resources, I could and would make a proof of concept system based on Arch using Xfce as a baseline of what to showcase. A distribution that would be a baseline of what YOTLD could be like. Yes it would even have Wine installed too to prove a point. We have a YOTLD design, but the wayland issue is killing the idea completely.

To me, X11 is like general mathematics. Everything is learned by tables. Math is simple. Nobody has an issue learning it.

Wayland is like common core math using imaginary numbers, unnecessary breakdowns of math problems, roundabout ways of solving simple formulas, and in the end, when you try to learn it, it makes you feel stupid on purpose.

Please let us deescalate this. The year of the Linux Desktop wasn’t destroyed. Every year since 2009 has been a year of the Linux desktop, because we have faster than linear growth. This doesn’t mean that there have not been actions against it, but please let us stop the doomsaying. Despite all setbacks, GNU Linux is growing steadily.

And in my experience, a regular Mint install on a laptop just works. These things are what most people see, even while specialist tooling gets broken badly. Though it is annoying to imagine how much further ahead we could be if the last 15 years hadn’t been wasted trying to get Wayland nearer to the level that X11 had reached already, with the endless promise that it would be ready just two years later (so investing into X11 felt like it would be wasted). I fell for those promises in 2011 and only started to doubt in 2013. But I still trusted that they knew what they were doing, because the Wayland folks were the ones with most X11 experience. If me and others hadn’t been this trusting but had instead remembered that you should never ever do a full rewrite of infrastructure and had contributed to X11 tooling (for example fixing the xcb keyboard layout problems instead of only reporting them until someone wrote a patch 5 years later¹ that I then didn’t see because I was no longer using KDE due to the bug), then we’d be in a better place today.

xcb was a genuine improvement that fixed the performance problems of X11 (and along with event filtering voided any need for Wayland), but it did not receive the polish it should have received.

¹ the patch ist still not merged, as far as I can tell …

Also imaginary numbers are great: they make Physics much easier.

Charts and numbers only speak a small fraction of what the reality is.

Where's the feedback for people trying out GNU/Linux from Windows and then going back to Windows because they found something that wasn't working onky to be using a wayland based distribution or wayland based WM/DE? That's the real issue.

We already know many people flocked to GNU/Linux thanks to YouTubers like PewDiePie. I'd like to know how many tried Arch with Hyprland, and went back to Windows because something just wasn't working.

People who come to GNU/Linux are looking for parity in the experience, and wayland is not offering parity. When they see that, those users go back, and that data is not shown.

Since there are quite a few stumbling points, teasing out whether Wayland was the reason won’t be easy.

But to make it clear what those charts mean: In 2026 about 10% of desktop computers worldwide run GNU Linux.

Which also explains the pressure to get proprietary software into these systems: they can no longer be ignored. And increasingly, Windows is the system that doesn’t provide parity in the experience.

https://www.draketo.de/politik/gnu-linux-desktop-share

NetMarketShare ); StatCounter ); They get the data from web traffic.

2022 ); The year when the fake-AI revolution to prop up hardware prices started.

So, how many of these Linux users are bots scraping the web to feed data to machine learning algorithms? Check AFRICA, where this shit is hardly present, and everything will fall into place.

Now, take a look at APPLE, that is suspiciously missing from the above-mentioned analysis, and the picture is turning even gloomier. What we're witnessing right now is one proprietary operating system being replaced by another while Linux market share stays almost negligible at 3-4%.

https://www.draketo.de/politik/gnu-linux-desktop-share

Now, take a look at APPLE, that is suspiciously missing from the above-mentioned analysis

If you take a look at the graph, you’ll see that the measure is "GNU per kilowindows". Nothing suspicious. You just didn’t understand the metric.

(and no, Apple is not that big on desktop)

found while looking for something else. wow, does this mean you don't use systemd? Because...I don't. I barely use linux at this point, I'll jump to freebsd once I can get my radeon working in HIP/ROCm so I can use pytorch.

X11 did too many things. Wayland is lighter. X11 was designed for a world that hasn't existed in decades. Wayland didn't have as a goal for being a 1 to 1 feature replacement of X11, because it shouldn't be.

I'm working on a new GUI toolkit: https://iodev.co.uk/gui-preview/

It is VERY alpha, no source release yet, but I thought it might be interesting for people to know it's coming.

• It's entirely vector-based.
• Can survive server crashes and migrate across servers too.
• Low memory requirements.
• Could be made network-transparent (I might aim for that in v2.0)
• Multiplatform.

wow, does this mean you don't use systemd? Because...I don't.

I use OpenRC

I barely use linux at this point, I'll jump to freebsd once I can get my radeon working in HIP/ROCm so I can use pytorch.

Why not install GNU/Linux-libre?

Actually X11 does provide a good idea of what a UI/UX should present in a WM/DE. It shares the same fundamentals as MacOSX and Windows. All three were based on XeroxUI.

Interapplication communication without spaghetti code APIs to route everything through needlessly.

Basic standard functionality of global hotkeys.

Standardized mouse enabled menus (aka Right-click).

Uniformity of standards and practices. The protocols and display server are always on the same specification, and there is always a basic core functionality standard to follow.

Wayland is fractured and has multiple display servers, display protocols, and feature lists between them all. There is no set standard even if people claim it and try to defend it. Wlroots, wayfire, gnome, kde, everyone has their own in-house display server, but none of them are to any real standard other than what they feel they need. Even then xwayland doesn't do the same job as X11 does. It can't. Even games running on Steam require workarounds to use with a wayland system that are needless. And that's all we get with wayland is workarounds after workarounds theough xdg's spaghetti code of stupidity.

this is becoming the most non-UNIX, non-KISS conversation I've had all afternoon.

Right-click menus can easily be added if you want them. spaghetti code? X11.org without desktop has 700k lines, wayland 40k. I have only wayland - the core, main one - with niri, and it does absolutely everything I need.

I still have my 1995 infomagick cd set that has original slackware and mother's day redhat, if you'd like; I assume you don't use SMP, or other new-fangled things of that nature? Windows 11 has far less to do with anything from xerox than wayland does, btw. Your arguments make no sense. It's not 1990 anymore, there are fundamental differences in hardware and networking.

because it shouldn't be.

yes it should

Wayland is lighter.

dysfunctional doesn't mean lighter

because it shouldn't be.

yes it should

No, it shouldn't. Absolutely nothing about its core driving mission was to be a 1:1 feature replacement for X11, Windows11, my maverick hybrid truck, a carton of eggs, or any other product that isn't itself. There were also features of X11 which shouldn't exist.

Wayland is lighter.

dysfunctional doesn't mean lighter

Functions just fine for me :) Though I just want my compositor to be able to draw windows - and I don't have any interest in them drawing the windows /over there/ - just here.

No, it shouldn't. Absolutely nothing about its core driving mission was to be a 1:1 feature replacement for X11, Windows11, my maverick hybrid truck, a carton of eggs, or any other product that isn't itself. There were also features of X11 which shouldn't exist.

Core driving mission is to take over X11. So they should offer in return everything they taking away.

Functions just fine for me :) Though I just want my compositor to be able to draw windows - and I don't have any interest in them drawing the windows /over there/ - just here.

Just fine for me doesn't work, when it can't do even basic functions. There is no point then for this replacement.

If the purpose was to replace, then why does wayland and every wayland compositor still get parity functions wrong? Why does everything have to be routed through the spaghetti code of xdg's API which is worse than X11 in every regard.

People say X is bad without even looking at what is replacing it. Xdg and it's far worse to code for because it relies on wayland compositors to have features available and half the compositors still have missing and broken functions.

@ismaell

I'm working on a new GUI toolkit: https://iodev.co.uk/gui-preview/

It is VERY alpha, no source release yet, but I thought it might be interesting for people to know it's coming.

* It's entirely vector-based.

* Can survive server crashes and migrate across servers too.

* Low memory requirements.

* Could be made network-transparent (I might aim for that in v2.0)

* Multiplatform.

Excellent news, thanks a ton! Exactly what Wayland needed.

If you're dead serious about it, there's something extra it should have: absolutely stable rock solid APIs/ABIs.

And it should support stream based drawing, IOW the UI could be streamed as a list of commands over a networking connection (UNIX pipes, tcp, etc).

Both Win32 and X11 support that, but not GTK/Qt.

Last I heard, Trolltech has no plans to remove X11 support from QT, despite what KDE keeps claiming, and has said KDE does not speak for them.

I see that we're still as miserable as always around here :)

I've been running wayland for years now. always outside of big desktop environments. I run my own window manager now.
it's great. multi-monitor works better than it ever has. I have no way of telling which ones of my monitors use fractional scaling and which ones don't. I can do multi-seat stuff that X11 could only dream of.

Life is good. Wayland works fine and well.

I see that we're still as miserable as always around here :)

I've been running wayland for years now. always outside of big desktop environments. I run my own window manager now. it's great. multi-monitor works better than it ever has. I have no way of telling which ones of my monitors use fractional scaling and which ones don't. I can do multi-seat stuff that X11 could only dream of.

Life is good. Wayland works fine and well.

It heavily depends on the use case, and wayland does not always fit every use case perfectly.

Laptops, some gaming, single screen monitor setups, general workstation for office and light usage, then yes, it works fine. You can use wayland 100% perfectly in this setup.

Multi-monitor, desktops, heavy gaming, content creation, production workflows, and rendering, it absolutely sucks wrestling with the xdg spaghetti code API and dozens of workarounds and plugins that don't guarantee 100% apples to apples with X11.

Life is good. Wayland works fine and well.

For you. And that there are people for whom X11 worked fine and well and Wayland does not is the point.

On 25/Sep/2026 06:19, Artem S. Tashkinov wrote: @birdie-github commented on this gist:

<...>

If you're dead serious about it, there's something extra it should have: absolutely stable rock solid APIs/ABIs.

And that's why I haven't published it yet, the API is far from stable, I'm making experiments to figure out how it should be, and many things are too broken still. I will publish it before API stability though, the 0.x series will be dedicated to unstable releases.

And it should support stream based drawing, IOW the UI could be streamed as a list of commands over a networking connection (UNIX pipes, tcp, etc).

It is already streamable.

Both Win32 and X11 support that, but not GTK/Qt.

At the moment Windows and Mac support is achieved, theoretically, through SDL2/3. I have no plans to support Mac officially unless someone pays for it handsomely, and Windows only through ReactOS, unless the same thing happens. X11 support is solid, as Wayland is.

@ismaell

Great news, thanks a ton!

When designing APIs, I hope you will bear in mind the rendering paths of Qt and GTK. In theory, they could add your library as a backend to achieve some surface-level parity with X11, although I really doubt this will ever happen.

The Wayland mob doesn't care about fast and effective remote desktop'ing - sending raw bitmaps, that are also horribly compressed, is totally fine with them.

But that still leaves us stranded, I feel like. Without properly integrating into Wayland compositors you cannot achieve feature parity with X11.

On 29/Sep/2026 04:46, Artem S. Tashkinov wrote: <...>

When designing APIs, I hope you will bear in mind the rendering paths of Qt and GTK. In theory, they could add your library as a backend to achieve some surface-level parity with X11, although I really doubt this will ever happen.

I've done that sort of thing in the past, specially with QPA, but I'd rather port the applications to my toolkit instead.

The Wayland mob doesn't care about fast and effective remote desktop'ing - sending raw bitmaps, that are also horribly compressed, is totally fine with them.

They are not wrong, the way most toolkits are designed nowadays, it's faster and better to do it that way, and X11 wasn't really any better at it, it's networking capabilities were awful despite native.

But that still leaves us stranded, I feel like. Without properly integrating into Wayland compositors you cannot achieve feature parity with X11.

My toolkit integrates just fine with Wayland, in fact theoretically could do better than X11 by adding some protocols to accelerate compositing (you could composite the command buffers instead of a raster, and taking it a step further it could be done in hardware even).