Wayland vs X11 in Practice

What each one is

X11 (X.Org Server)

X11 is a window-system protocol that dates from 1984. The implementation that runs on Linux is the X.Org Server, a successor to the original MIT X Window System and to its predecessor XFree86. X11 is a network-transparent client-server protocol: applications ("clients") connect to a server, send drawing commands and receive input events. The server takes care of compositing the result on a display.

That design predates a lot of what desktop computers are now expected to do. Many of the things that feel native today — modern hardware-accelerated compositing, per-monitor scaling, robust input isolation between applications — were grafted onto X11 over time. They work, but the seams show.

Wayland

Wayland is a more recent protocol — first proposed in 2008 — designed around the assumption that the same process is acting as both window manager and compositor. There is no separate "server" speaking a long-lived network protocol; instead, each desktop environment (GNOME, KDE Plasma, Sway, and so on) ships its own Wayland compositor, and applications connect to it as Wayland clients.

Wayland is a smaller protocol than X11 by design. Many features that are part of X11's core are pushed up into the compositor or out into separate protocols that compositors opt into. This is part of the reason Wayland adoption has taken so long: each ecosystem piece (screen sharing, screen recording, accessibility tools, colour management) has had to be reimplemented for Wayland to reach the same level of polish.

How to check which one you're using

The quickest check from a terminal:

echo $XDG_SESSION_TYPE

This prints wayland or x11 depending on the current session. On GNOME you can also check via the About panel in Settings; on KDE Plasma, the relevant panel is System Information.

If you're seeing strange behaviour with a specific application — sluggish drawing, broken global hotkeys, a screen-recording tool that captures nothing — knowing which session you're in is the first useful piece of information.

Where the difference shows up

Screen sharing and recording

This is the most visible difference for most people. On X11, any client can read pixels from the screen and from other applications' windows; that's how traditional screen recorders, screen sharers in video-conferencing tools, and screenshot utilities all work.

On Wayland, applications cannot read pixels from other applications. Screen capture goes through the xdg-desktop-portal system: the application asks the portal for permission, the desktop environment shows a confirmation dialog, and the user picks which window or screen to share. This is more secure but means a screen-sharing tool that hasn't been updated to use portals will return a black rectangle.

Most major tools (OBS Studio, Zoom, Microsoft Teams, Firefox, Chromium) now support the portal API. If a particular tool you depend on doesn't yet, X11 is the path of least resistance.

Global hotkeys

On X11, any application can grab key combinations system-wide. Wayland doesn't allow that — global hotkeys are the compositor's responsibility, exposed (where supported) through the org.freedesktop.portal.GlobalShortcuts portal. Some applications (push-to-talk in voice chat, password manager autotype) will need to be configured through the desktop environment's keyboard settings rather than from inside the application.

Mixed-DPI and per-monitor scaling

Wayland was designed with high-DPI displays in mind. Per-monitor fractional scaling works more cleanly under Wayland; mixing a low-DPI external monitor with a high-DPI laptop screen produces fewer visual artefacts than it does under X11. Conversely, X11 applications running through XWayland (the compatibility layer) can look noticeably worse on fractional-scale Wayland sessions, because they're still rendering at a single DPI and being scaled.

NVIDIA drivers

For many years NVIDIA's proprietary driver lagged on Wayland support, which is part of the reason some distributions default to X11 when an NVIDIA card is in use. Recent driver versions have closed most of the gap, and modern distributions usually default to Wayland on NVIDIA hardware too. If you have an older card or are pinned to an older driver, X11 may still be the more reliable choice.

Remote display

X11's network transparency made it possible to forward a single application across SSH (ssh -X). Wayland doesn't support that model. The Wayland-era replacement is to run a remote desktop server (RDP, VNC, or the newer wayvnc) and connect to it, which is more like a full remote desktop than just a single forwarded window.

X11 forwarding from older systems

If you SSH into an older server that only knows X11, you can still receive its windows on a Wayland desktop — XWayland handles the translation. The reverse (an old X11 client trying to share its screen on a modern Wayland session) is where the friction lives.

Decision criteria: which session to use

If you're not sure which session to pick at the login screen, a short decision flow works for most cases:

How to switch sessions

Most graphical login managers expose a session picker on the login screen. The exact place varies:

• GDM (GNOME): click the gear icon next to the password field after entering your username.
• SDDM (KDE Plasma): use the dropdown at the bottom-left of the login screen.
• LightDM: a small icon next to the username opens a menu of installed sessions.

You should see at least two entries — for example, "GNOME" (Wayland) and "GNOME on Xorg". Pick the one you want; the choice is per-login and easy to reverse.

If only one session is listed, the X11 alternative may not be installed. On most distributions it's a one-package install (gnome-session-xsession, plasma-workspace-x11 or the equivalent), but on some recent releases the X11 session has been removed from the default install entirely and is no longer offered.

XWayland: the bridge

Most current Wayland sessions can run X11 applications transparently through a compatibility layer called XWayland. XWayland is essentially an X server that draws into a Wayland window. From the application's point of view it's still talking X11; from the compositor's point of view it's just another Wayland client.

For most applications this is invisible — they just work. The places where you notice are exactly the ones described above: screen capture across the X/Wayland boundary, global hotkeys, fractional scaling. If you find an old X-only application looks fuzzy on a high-DPI display, that's XWayland scaling being applied.

Common mistakes

• Assuming a problem is "a Wayland issue" without checking. Verify the session type first (echo $XDG_SESSION_TYPE) before searching for solutions. Some problems are completely independent of the display protocol.
• Trying to fix Wayland-specific screen-capture issues with X11-era utilities. If a particular tool doesn't support the desktop portal, replacing the tool is usually easier than working around the protocol.
• Logging in to the wrong session by accident, then concluding that the desktop is broken. Check the login screen's session picker if the desktop behaves differently from yesterday.
• Reaching for xrandr on Wayland. The X-era display-configuration tools won't see Wayland outputs. Use the desktop environment's display settings (or wlr-randr on wlroots-based compositors).

Related reading

• GNOME overview — GNOME's Wayland-first stance and how it shapes the wider Linux desktop.
• KDE overview — KDE Plasma's parallel Wayland development.
• Linux troubleshooting — including how to read graphical-session logs.
• How to install Ubuntu LTS — recent Ubuntu LTS releases default to a Wayland session out of the box.