A compositor is the software responsible for taking the pixel buffers produced by each running application and combining them into the final image displayed on screen. It handles layering, transparency, shadows, animations, and effects — essentially acting as a real-time video editor for your desktop.
How It Fits in the Graphics Stack
Application (Chrome, Terminal, etc.)
↓ draws into its own buffer
Compositor (receives all buffers)
↓ composites into final frame
GPU → Monitor
Without a compositor, applications would draw directly to a shared screen buffer — causing flickering and tearing. With a compositor, each app is isolated; the compositor decides the final output.
Display Protocols
Compositors communicate with applications using a display protocol. There are two on Linux:
X11
The original protocol, over 30 years old. Applications draw to a shared memory buffer visible to all processes. This makes screen recording easy but is fundamentally insecure — any app can read pixels from any window.
Wayland
The modern replacement. Each application gets its own isolated buffer. The compositor is the only process that combines everything. More secure, smoother rendering, and better support for HiDPI and multiple monitors.
Wayland Protocol Layers
The Wayland core protocol is deliberately minimal. It only handles:
- Surfaces — a rectangle of pixels
- Input events — keyboard, mouse, touch
- Shared memory buffers — how pixel data is exchanged
Notably, the core protocol does not define what a “window” is. That’s where protocol extensions come in:
┌──────────────────────────────────────┐
│ Your Application Code │
├──────────────────────────────────────┤
│ GUI Toolkit (GTK, Qt, SDL, etc.) │ ← what developers use
├──────────────────────────────────────┤
│ libwayland-client │ ← toolkit uses this internally
├──────────────────────────────────────┤
│ Wayland core + XDG Shell + other │ ← wire protocol
│ protocol extensions │
├──────────────────────────────────────┤
│ Compositor (Mutter, KWin, etc.) │
└──────────────────────────────────────┘
The most important extension is XDG Shell (xdg-wm-base), which defines:
- Toplevel surfaces — what we think of as “windows” (title, minimize, maximize, close)
- Popups — dropdown menus, tooltips
- Window decorations — via the
xdg-decorationsub-protocol
Other standard extensions handle clipboard, drag-and-drop, screen capture, idle inhibit, and more.
Note
“Shell” here means the protocol layer that gives raw Wayland surfaces window-like behavior — not a command-line shell like zsh. The word “shell” is overloaded: in a terminal it’s your CLI interpreter (zsh, bash), in a desktop environment it’s the visual UI layer (GNOME Shell), and in Wayland it’s the protocol extension that turns surfaces into windows (XDG Shell).
In practice, application developers never touch these protocols directly. GUI toolkits like GTK and Qt abstract everything away. When you create a window in GTK, it internally creates an xdg_toplevel surface, sets the title, negotiates decorations with the compositor, and handles all input events — invisibly.
You would only use libwayland-client directly if you were writing a compositor, a panel, a screen locker, or your own GUI toolkit.
Note
On Wayland, screen sharing and camera access requires an additional layer called XDG Desktop Portal — a D-Bus service that proxies privileged requests between Flatpak/sandboxed apps and the compositor. This sits above the protocol stack, using D-Bus rather than the Wayland protocol itself. See X Desktop Group (XDG).
Types of Compositors
| Compositor | Type | Protocol | Used In |
|---|---|---|---|
| Mutter | Stacking | Wayland + X11 | GNOME |
| KWin | Stacking + tiling | Wayland + X11 | KDE Plasma |
| Hyprland | Tiling | Wayland only | Standalone |
| Sway | Tiling | Wayland only | Standalone |
| Picom | Stacking | X11 only | i3, bspwm |
Stacking vs Tiling
- Stacking: Windows float and overlap freely. You drag them around. This is the familiar macOS/Windows model.
- Tiling: Windows are automatically arranged to fill the screen without overlap. All positioning is keyboard-driven.
Compositors and Desktop Environments
A desktop environment (like GNOME) bundles a compositor with a panel, file manager, settings app, and other tools. A standalone compositor like Hyprland gives you just the compositor — you assemble everything else yourself.
Tip
It is possible to have multiple compositors installed on the same machine. GDM (the GNOME login manager) lets you choose which session — and therefore which compositor — to start at login.