X11 Is Gone. Your Linux App Needs a Compositor Matrix

For about thirty years, testing a Linux desktop application meant testing against X11. Not "an X server" — the X server. Whatever distribution your user ran, whatever desktop environment sat on top, the underlying implementation was the same, with the same behaviour. If your app worked on your machine, it worked on theirs.

That assumption is now gone, and it's a bigger change for anyone shipping Linux software than the porting work itself.

In this post:

• Where things actually stand
• Why this is a testing problem first
• What actually breaks
• The portal model
• XWayland is a fallback, not a shim
• Building the test matrix
• My take

Where Things Actually Stand

Worth being precise, because the timelines get muddled in the arguing.

GNOME has finished. GNOME removed the X11 backend from Mutter, GNOME's compositor, in November 2025. GNOME 49 dropped the X11 session, and GNOME 50 — released in March 2026 — ships with no X11 code at all. There is no GNOME X11 session to install any more, regardless of what else you have on the system.

KDE is a year behind and committed. Plasma 6.7 is the last release with an X11 session. Plasma 6.8 goes Wayland-exclusive, removing the X11 session and then cleaning up X11-specific code. KDE has maintained the position through 2026: Phoronix reported in June that 95% of Plasma 6.6 users were already running Wayland.

One distinction that matters and gets lost: this concerns the Plasma desktop session, not KDE applications. KDE apps are expected to keep running in X11 environments, and there are no plans to drop X11 support in the applications themselves.

Distributions have largely moved already. Fedora 43 dropped X11 in favour of Wayland. Ubuntu 25.10 removed X11 sessions from default installations, and Ubuntu 26.04 ships Wayland-exclusively for both GNOME and Plasma.

The rest of the ecosystem is uneven. Xfce added initial Wayland support in 4.20, using labwc as a stopgap, but xfwm4 still isn't a Wayland compositor. Cinnamon and MATE are earlier still. COSMIC was built Wayland-only from the start and never supported X11. For users who genuinely need an X11 session, KDE's own guidance points at long-term-support distributions — AlmaLinux 9, for instance, ships Plasma and is expected to receive security updates until 2032.

So: if you ship desktop software for Linux, your users are on Wayland now, whatever your own machine is running.

Why This Is a Testing Problem First

Most of what's written about this frames it as a porting exercise — replace these calls, adopt these protocols, done. That underestimates it, and in a specific way.

Under X11, "works on Linux" was a coherent claim, because there was one implementation of the display server. You tested against X.Org, your users ran X.Org, and the behaviour was identical because it was literally the same binary.

Wayland is a protocol, not an implementation. Mutter, KWin, wlroots-based compositors, and COSMIC's compositor are separate codebases implementing the same specification, each with its own extensions, its own gaps, and — crucially for anything privileged — its own portal backend. Screen capture is served by the GNOME stack on GNOME, the KDE portal on Plasma, and xdg-desktop-portal-wlr or a compositor-specific variant on wlroots systems. These are different implementations of the same D-Bus interface, and they don't behave identically.

Then add XWayland as a fallback path with its own distinct behaviour, and the toolkit-level backend switches on top.

The practical result: "it works on my machine" has gone from a reasonable proxy for "it works" to nearly worthless. Your app can be flawless on GNOME and broken on Plasma for reasons that have nothing to do with your code and everything to do with which portal backend answered the call. If you only test on your own desktop — and most Linux developers do, because for thirty years that was sufficient — you now have no idea whether your app works.

What Actually Breaks, and Why

Everything in this list has the same root cause, which is worth stating before the list rather than after: under X11, any application could read any other window's pixels, read keystrokes, and inject input events. That's why screen sharing worked so easily. It's also why keyloggers and screen scrapers worked with no friction at all. Wayland's design removes that, and every broken feature below is downstream of exactly that removal.

Screen capture and screen sharing. No app can grab the framebuffer directly. Capture goes through the org.freedesktop.portal.ScreenCast D-Bus interface: your app asks, the compositor shows a prompt, the user picks a screen or window, and the portal hands back a PipeWire stream. This is a substantially different architecture from "read the root window," not a drop-in replacement. OBS Studio needed a dedicated portal plugin. Peek, a screen-recording tool, was abandoned by its developer partly over these challenges.

Global hotkeys. An application can't listen for keystrokes it doesn't own. Global shortcuts have to be registered with the compositor's shortcut system, and a portal interface for this was a long-standing gap — the request sat in the xdg-desktop-portal tracker for years before a solution existed. If your app has push-to-talk, a global capture shortcut, or a quake-style toggle, this change is most likely to cost you real work.

Window positioning and geometry. Wayland was explicitly designed to prohibit clients from introspecting or programmatically changing their global window coordinates. A client cannot know where its own top-level window is — only which outputs it overlaps. So there's no "remember where the user left this window and put it back," and no programmatic placement. This isn't an unimplemented feature awaiting a protocol; it's a deliberate design decision, and SDL and Qt both carry long-standing issues about it.

Inspecting or controlling other windows. The xprop/xkill category of capability — reading another application's process ID and properties, or terminating it — has no direct equivalent. Partial coverage exists through ext-foreign-toplevel-list and ext-foreign-toplevel-state, but "partial" is doing real work in that sentence. This hits taskbars, docks, window-management utilities and automation tooling hardest.

Remote desktop. This is the sharpest remaining friction point. Wayland's permission model means many third-party remote desktop tools require someone to be physically present at the machine to accept the connection—which defeats the purpose of unattended access. The workable path is the desktop's own portal-integrated remote-desktop service; GNOME and Plasma both expose one. For X11 forwarding specifically, XWayland still supports it, and Waypipe provides comparable functionality for Wayland-native applications.

Clipboard and drag-and-drop across the boundary. There's no shared memory between Wayland and XWayland, so clipboard and drag-and-drop need explicit bridging, handled by the compositor xdg-desktop-portal. It usually works. When it doesn't, the failure is confusing, intermittent, and depends on which side of the boundary each application sits.

The Portal Model, and Why It's Shaped Like This

It's worth understanding the portal architecture rather than treating it as an obstacle, because it explains the failure modes.

Portals are a D-Bus API that mediates privileged operations between an application and the desktop. The application makes a request; the compositor's portal backend renders a user-facing prompt; the user grants or refuses; the backend returns a handle to the resource. The application never touches the underlying capability directly and never learns anything the user didn't consent to.

Which means a screen-capture request now traverses four things that can independently fail: your application, the portal frontend, the compositor's portal backend, and PipeWire as the media transport. Break any link and capture fails — no portal backend installed and nothing processes the D-Bus request; PipeWire not running and there's no transport for the stream.

This is why "screen sharing doesn't work on Wayland" is so often not an application bug at all. It's why your first diagnostic when a user reports a capture failure should be which portal backend they have installed, not what your code did.

It also has a design consequence people miss. The prompt is user-visible, so when you request matters. An application that asks for screen capture at launch, before the user has done anything, trains people to dismiss prompts reflexively. Request it at the point of use, with the action the user just took still on screen, and make the prompt self-explanatory. That's a UX decision the portal model forces on you whether you think about it or not.

XWayland Is a Fallback, Not a Shim

XWayland runs a full X server as a Wayland client, starting on demand when the first X11 client connects. Legacy applications keep working. It's genuinely good, and it's why the transition hasn't been catastrophic.

It is not, however, transparent, and the differences are precisely the ones that make testing harder:

• HiDPI scaling is coarse. The X11 model scales in integer multiples, so fractional scaling doesn't carry across cleanly. X11 windows look blurry at 125% and 150% — a visual defect your users will report as your bug.
• Global shortcuts and raw pointer grabs behave differently, which is why hotkey and capture tools misbehave in hard-to-reproduce ways.
• The isolation is real. X11 clients cannot snoop on Wayland windows. If your application depended on cross-application inspection, running under XWayland does not restore it.

Two things worth knowing for debugging: xlsclients and xprop will tell you which X11 clients are currently connected to XWayland, which is the fastest way to establish whether your app is actually running natively or has quietly fallen back.

Building the Matrix Without Six Machines

The honest minimum for a Linux desktop application in 2026:

Two compositors, not one. GNOME (Mutter) and Plasma (KWin) between them cover the overwhelming majority of users and have genuinely different portal backends. If you test on one, test on the other. This is the single highest-value addition, and everything else is optional next to it.

Both paths through your own app. Native Wayland and XWayland, deliberately, not accidentally. GDK_BACKEND=wayland and GDK_BACKEND=x11 force the backend for GTK applications, which lets you exercise both without changing sessions.

Qt's equivalent is QT_QPA_PLATFORMand the Qt situation deserves more attention than it usually gets, because it has two opposite failure modes. Left to auto-detect, Qt has defaulted to the xcb — that is, XWayland — backend even inside a Wayland session on GNOME, printing a warning that it's ignoring XDG_SESSION_TYPE=wayland and suggesting you set QT_QPA_PLATFORM=wayland if you want otherwise. So your app may be running through XWayland even though you think it's native. Set the variable explicitly without the QtWayland plugin installed, though, and it doesn't fall back at all — the application aborts with "no Qt platform plugin could be initialised."

This case reaches users with bundled Qt. Applications shipping their own Qt — AppImages, Flatpaks not distributed by KDE, proprietary software, and at one point the Qt installer itself — frequently don't include the QtWayland platform plugin, so they take the XWayland path on every machine regardless of the session. If you distribute your app that way, check what's actually inside the bundle rather than what's on your development box.

One warning on that technique: some Electron applications — Slack, Element and Discord have all been cited — and Chromium itself may break when GDK_BACKEND is forced to wayland. If your app embeds a browser engine, this variable is for diagnostics, not deployment.

Fractional scaling, specifically 125% and 150%. This is where the XWayland blur appears, and it's the most common thing users report that developers never see, because developers overwhelmingly run at 100% or 200%.

Every portal-mediated path, on each compositor. If your app captures the screen, registers a global shortcut, opens a file picker, or shares a window, that path needs to be exercised against both backends. These are the operations where the same code genuinely produces different results.

What you can skip: wlroots compositors, COSMIC, and the in-transition desktops, unless you have a specific reason to think your users are there. Testing four compositors isn't four times better than testing two; the second catches most of what the first missed, and returns diminish sharply after that.

A VM per compositor is sufficient for all of this. You don't need hardware.

My Take

X11's permissiveness was as much a testing shortcut as a capability. One display server meant one test environment, and the fact that any app could see any other app's windows meant a whole category of tooling — screenshot utilities, hotkey daemons, window managers, automation — could be written without the platform's cooperation and worked everywhere by default. That was enormously convenient. It was convenient in the same way that a flat with no internal doors is convenient.

I've written recently about Android 17 removing the portrait-lock escape hatch, and this is the same story on a different platform. A permissive default everyone built on gets withdrawn; the migration is framed as a porting problem, and the real cost lands in testing — because what you lost wasn't a feature; it was the guarantee that one environment represented all of them.

The security argument is unanswerable, and I'd say that plainly to anyone still litigating it. A model where any application can read every other application's pixels and keystrokes is not defensible in 2026. Every other desktop platform closed this years ago. macOS started requiring explicit consent for screen recording in 2018; mobile platforms never permitted it at all. Linux is the last to arrive somewhere everyone else already is, and it arrived late enough that the arguments were already had elsewhere.

But the sequencing was genuinely botched, and pretending otherwise is why the discourse is so bad. They removed the capability before the replacement existed. A portal interface for global shortcuts was requested for years, while applications that depended on it were simply broken. Screen capture went through a long period of "Wayland provides no capture APIs" before PipeWire and the ScreenCast portal matured. When macOS made the same change, Apple shipped the restriction and the replacement API on the same day. Linux shipped them years apart, and application maintainers paid the cost —some gave up; Peek's developer abandoned the project rather than fight it.

That's worth naming precisely, because the lesson isn't "Wayland was wrong." It's that removing a capability before its replacement is usable converts a technical migration into a decade of grievance, and the grievance outlives the problem. The portals work now. A lot of people stopped listening too late.

Practically, what I'd actually do: add a second compositor to your test setup this month, before you touch any code. Not because you're planning a port — because you currently don't know whether your app works, and finding out is cheap. Everything else follows from what you find.

And the user-facing version: nobody has ever cared which display server their desktop uses. They care that screen sharing works when they join a call, that their shortcut still fires, and that text isn't blurry on the external monitor. Those three things are your test plan. If they pass on GNOME and on Plasma, at 100% and at 150%, you're in better shape than most of the software your users are running.

FAQ

Is X11 dead?
The X.Org server is still maintained and still receives fixes. What's ending is desktop environments offering an X11 session: GNOME has removed it entirely, and KDE removes it in Plasma 6.8.

Will my X11 application still run?
Yes, through XWayland, which runs a full X server as a Wayland client. Rendering is generally fine; exceptions include global shortcuts, screen capture, window positioning, and fractional scaling.

When does KDE drop X11?
Plasma 6.7 is the last release with an X11 session; Plasma 6.8 is Wayland-exclusive, with X11 support running to early 2027.

Do KDE applications stop supporting X11?
No. The change concerns the Plasma desktop session. KDE applications are expected to continue running in X11 environments elsewhere.

Why doesn't screen sharing work on Wayland?
Usually because a link in the chain is missing, not because of an application bug. Capture requires the correct xdg-desktop-portal backend for the compositor plus a running PipeWire daemon.

What if I genuinely need an X11 session?
Use a long-term-support distribution. KDE's own guidance points to AlmaLinux 9, which ships Plasma and is expected to receive security updates until 2032.

Which compositors should I test against?
At minimum, GNOME's Mutter and KDE's KWin. They cover most users and use different portal backends, where behaviour actually diverges.