Wayland is a display server protocol that defines how graphical applications communicate with the component that draws the screen, called the compositor, on Linux and related operating systems. On Linux desktops, Wayland is the successor to the X Window System (X11): it specifies how windows hand finished images to the compositor and how keyboard, mouse and touch input reaches the right window.
Wayland is a protocol and a set of libraries, not a single program. Each desktop environment implements its own compositor, for example Mutter in GNOME, KWin in KDE Plasma, or standalone compositors such as Sway and Hyprland. Since the early 2020s, most major Linux distributions use a Wayland session by default, keeping X11 compatibility through a translation layer.
How Wayland draws and delivers input
Under Wayland, each application renders its own window contents into a buffer, usually with the GPU through OpenGL or Vulkan, and then passes a handle to that buffer to the compositor. The compositor combines all visible buffers into the final image and presents it to the display through the kernel’s DRM and KMS interfaces. No separate server sits between the application and the compositor.
Communication runs over a Unix domain socket using an asynchronous, object-oriented message protocol. The core protocol is deliberately small. Features such as desktop windows, decorations, screen capture and fractional scaling are added as protocol extensions, most of them standardized in the wayland-protocols collection, where the xdg-shell extension defines ordinary application windows.
Input follows the same principle. The compositor receives events from the kernel through libinput and forwards them only to the window that has focus. Applications cannot read global keyboard input or the position of other windows, which is a deliberate security improvement over X11, where any client could observe the whole session.
Main components of a Wayland session
A Wayland desktop consists of several cooperating parts. The table identifies the role of each component and where problems usually appear.
| Component | Role | Examples |
|---|---|---|
| Compositor | Display server, window manager and renderer in one | Mutter, KWin, Sway, Weston |
| Client toolkit | Lets applications speak Wayland | GTK, Qt, SDL, Chromium, Firefox |
| XWayland | Runs X11 applications inside Wayland | Bundled with most compositors |
| Portals | Mediate screen sharing and file access | xdg-desktop-portal backends |
| PipeWire | Transports screen-capture and audio streams | Used by screen-sharing tools |
| Kernel graphics stack | Mode setting and buffer sharing | DRM, KMS, GBM |
The most important architectural consequence is that the compositor is also the window manager. Under X11, a window manager was a replaceable client of the X server; under Wayland, changing window management behavior means changing or extending the compositor itself.
Wayland compared with X11
Wayland was designed to remove decades of accumulated complexity in X11, much of which modern toolkits no longer used. The differences below explain both its advantages and its migration difficulties.
| Aspect | Wayland | X11 |
|---|---|---|
| Architecture | Compositor is the display server | Separate X server, window manager and compositor |
| Rendering | Client-side, buffers shared with compositor | Historically server-side drawing commands |
| Isolation | Clients cannot see each other | Any client can read input and other windows |
| Screen tearing | Avoided by design, every frame is complete | Common without careful configuration |
| Mixed DPI monitors | Per-output scaling, fractional via extension | One global scale, workarounds needed |
| Network transparency | Not built in, uses separate tools | Built in, remote windows over the network |
| Maturity | Default on major distributions | Stable, mostly in maintenance mode |
A frequent misunderstanding is that Wayland is “a newer X server”. It is a different model: there is no shared global coordinate space that applications can query, so tools that positioned windows freely, captured the whole screen or injected keystrokes must now ask the compositor through dedicated protocols or portals.
Compatibility and practical configuration
For users, Wayland is usually selected at the login screen as a session type. For administrators, compatibility depends on drivers, toolkits and the specific applications in use, and most problems fall into a few recurring categories.
| Symptom | Typical cause | Usual remedy |
|---|---|---|
| Screen sharing shows a black window | Application lacks portal support | Update the app, enable PipeWire capture |
| Blurry older application | App runs through XWayland with scaling | Use native Wayland mode or integer scaling |
| Global hotkeys do not work | Clients cannot read global input | Use compositor shortcuts or a portal |
| Remote desktop tool fails | Tool relies on X11 capture | Use a Wayland-aware remote desktop |
| Graphical glitches on some GPUs | Older driver without needed features | Update the graphics driver |
Many toolkits detect Wayland automatically, but some applications still need an explicit switch, such as an environment variable or a command-line flag, to run natively instead of through XWayland. Running natively typically brings sharper scaling and smoother input.
Limitations and open questions
Wayland’s strict separation improves security and visual quality, but it also moves responsibility to compositors, which leads to fragmentation.
- Feature support varies by compositor. An extension available in KWin may be missing in another compositor, so the same application can behave differently.
- Accessibility and automation tools that relied on X11 introspection have needed new interfaces and are still catching up in some areas.
- Color management and HDR arrived later than on other platforms and depend on recent compositor and toolkit versions.
- Crash resilience is weaker by default: when the compositor crashes, applications often close with it, although recovery mechanisms are being developed.
In plain words
Wayland is the set of rules a Linux computer uses to put windows on the screen. Every program paints its own window. It then hands the finished picture to one central program, the compositor. The compositor arranges all the pictures and shows them on the monitor.
Think of an art exhibition. Each artist paints a canvas at home, and one curator decides where every canvas hangs. Visitors only touch the canvas in front of them. This makes the desktop smoother and safer. Some older tools have to learn new ways to work, though.
A real-world example
A video editor works on a Linux laptop with a 14-inch high-density screen and connects an ordinary 27-inch monitor at the office. Under an X11 session, one global scaling factor makes text either too small on the laptop or too large on the external monitor. After switching to the Wayland session at the login screen, the compositor applies 200 percent scaling on the laptop and 100 percent on the monitor, and windows keep a sensible size when dragged between them.
During a video call, screen sharing initially shows a black rectangle because the meeting application is an old version built for X11. Updating it to a release that uses the desktop portal and PipeWire solves the problem: a system dialog asks which window to share. The result is sharp text on both screens and permission-based screen sharing, with no manual configuration files edited.