The thing drawing pixels on your Linux desktop changed, and most people only found out when a screen recorder stopped working or a keyboard shortcut daemon quietly stopped responding. X11 ran the Linux desktop for the better part of forty years. Wayland has now replaced it nearly everywhere, and the reasons go deeper than “the old one was old.”

What X11 actually was

X11 is a network protocol first and a display system second. That ordering explains almost everything strange about it.

When the X Window System was designed in the mid-1980s, the assumption was that your computer was a terminal on a desk and the program you were running lived on a mainframe down the hall. So X11 was built as a client-server protocol: applications are clients, the thing controlling the screen is the server, and they communicate over a socket that might just as easily be a network connection.

That design gave X11 network transparency, which was genuinely ahead of its time and is still occasionally useful. It also meant the X server had to know how to draw. Early X11 had primitives for lines, rectangles, and text rendering, because sending drawing commands over a wire was cheaper than sending pixels.

Modern applications do not use any of that. They render everything themselves, usually on the GPU, and hand the finished image to the server. The drawing API sat there unused, along with a great deal of other accumulated machinery.

Where the architecture broke down

The bigger problem was compositing. X11 had no concept of it, so when desktops wanted drop shadows, transparency, and smooth animation, a separate compositor was added alongside the window manager.

That left three processes cooperating to put a window on screen: the X server, the window manager, and the compositor. Every frame crossed all three, and each handoff was a chance to add latency or tear. Anyone who has fought screen tearing on Linux was fighting this.

The security model was the other issue, and it was worse. In X11 there is essentially no isolation between clients. Any application connected to your X server can:

• Read the contents of any other window
• Log every keystroke you type, in any application
• Inject synthetic input events into other windows
• Move, resize, or close other applications’ windows

This was not a bug. It was the design, from an era when the machine had one user and the threat model was other people in the building. It is also why X11 keyloggers are a one-liner and why any X11 application you run has, in practice, full access to your session.

What Wayland changed

Wayland is a protocol, not a program. There is no single Wayland server the way there is a single X server. Instead the compositor is the display server: Mutter for GNOME, KWin for KDE, Hyprland, Sway, and COSMIC’s compositor each implement the protocol themselves.

Collapsing window manager, compositor, and display server into one process removes the handoffs. The compositor knows what every window looks like and when the screen is ready for a new frame, so it can present exactly one complete frame per refresh. Tearing stops being a configuration problem and becomes structurally impossible.

Isolation is the other half. A Wayland client can see its own surfaces and nothing else. It cannot read other windows, cannot see input directed elsewhere, and cannot manipulate other applications.

Which is why some things broke

Every capability X11 handed out freely had software depending on it. Removing those capabilities broke that software, and the fix was to build explicit, permission-gated replacements.

Screen capture and sharing now goes through xdg-desktop-portal, which shows you a picker asking which window or screen to share. OBS, browsers, and video call software all use it. Anything that never adopted it records a black rectangle.

Global hotkeys were a problem for years, because a key combination that works while another application is focused requires seeing input intended for someone else. The global-shortcuts portal now covers this, but adoption took time.

Automation tools like xdotool and wmctrl relied on injecting events and manipulating foreign windows. The replacement is libei, the Emulated Input protocol, which is why you saw EI protocol support land in COSMIC 1.6 and why remote desktop on Wayland took so long to work properly.

Clipboard managers need to watch selection changes across applications, which is exactly what Wayland prevents. Most desktops now provide this at the compositor level instead.

Notice the pattern: the functionality is not gone, it has been moved somewhere that can ask permission first. That is slower to build and better once built.

XWayland

You are almost certainly running X11 applications right now without knowing it. XWayland is a real X server that runs as a client of your Wayland compositor, giving unmodified X11 applications a normal X environment inside a Wayland session.

# Which session are you in?
echo $XDG_SESSION_TYPE

# Which applications are running through XWayland?
xlsclients

If xlsclients errors out entirely, you have no X11 clients running at all, which is increasingly common.

XWayland works well enough that the transition has been mostly invisible. The catch is that applications inside XWayland get X11 semantics among themselves, including the lack of isolation, so an XWayland app can still snoop on other XWayland apps. It cannot see native Wayland ones.

Where things stand now

GNOME has removed its X11 session entirely. KDE Plasma defaults to Wayland and its X11 session is on the same path. Every major distribution ships Wayland by default on supported hardware.

The remaining X11 holdouts are the lighter desktops, and even there the direction is clear: Xfce’s own Wayland compositor reached its second preview recently.

The historically legitimate reason to stay on X11 was NVIDIA. Proprietary driver support for the interfaces Wayland needs lagged for years, and the advice to switch back to X11 on NVIDIA hardware was correct for a long time. It is not correct anymore.

What this means for you practically

For most people, nothing. Log in, use the desktop, notice no difference.

If something is broken, work out whether it is an application that has not been ported rather than a fault in Wayland:

# Force a Qt app to use Wayland natively
QT_QPA_PLATFORM=wayland yourapp

# Force an Electron app to use Wayland
yourapp --enable-features=UseOzonePlatform --ozone-platform=wayland

# Check what a GTK app is using
GDK_DEBUG=misc yourapp 2>&1 | head

Electron applications in particular default to XWayland far more often than they need to, which is why some of them look blurry on a HiDPI screen while everything else looks fine.

Falling back to an X11 session still works on most desktops and remains a reasonable emergency measure. Just treat it as a workaround with an expiry date rather than a permanent home, because the ecosystem is not going back.

Frequently Asked Questions

What is the practical difference between Wayland and X11?

X11 is a display server that sits between applications and the screen, with a window manager and compositor bolted on separately. Wayland collapses those roles into one compositor that talks directly to the kernel graphics stack. The result is fewer moving parts, less latency, and stricter isolation between applications.

Is Wayland the default on my system?

Almost certainly, if your distribution is recent. GNOME has fully dropped X11, KDE Plasma defaults to Wayland, and most major distributions ship Wayland sessions by default. Run echo $XDG_SESSION_TYPE to see which you are in.

Why can some apps not record my screen on Wayland?

Under X11 any application could read the contents of any window without permission. Wayland removed that capability deliberately, so screen capture goes through the xdg-desktop-portal interface instead, which asks you what to share. Tools that were never updated to use the portal simply see a black screen.

Does Wayland break NVIDIA graphics?

It used to. NVIDIA proprietary drivers lacked the required interfaces for years, which is why so many guides told NVIDIA users to stay on X11. Modern driver releases support Wayland properly and the major desktops enable it by default on NVIDIA hardware.

Can I still run X11 applications on Wayland?

Yes, through XWayland, a compatibility layer that runs a real X server inside your Wayland session. Most users never notice which applications are using it. Run xlsclients to list the ones that are.

Should I switch back to X11 if something does not work?

It is a reasonable short-term fix and an increasingly bad long-term plan. X11 is in maintenance mode with no new development, GNOME has removed its X11 session entirely, and the tools that only work on X11 are steadily being replaced. Report the problem rather than settling on the old session permanently.