The Linux Window Manager Landscape

Most Linux documentation reaches for the same shorthand: a window manager manages your windows, a desktop environment is a window manager plus extras. That’s accurate but flattening. It hides the fundamental architectural difference that has cleaved the Linux desktop in two since Wayland became the default session on most major distributions — a difference that determines not just what software you run, but how display, compositing, input, and security interact at the kernel boundary. Understanding it properly changes how you evaluate every option in the WM space, from the well-worn i3 to the scrollable niri to the animations-first Hyprland.

The thesis here is simple: in 2026, the X11 window manager model and the Wayland compositor model are not interchangeable. They are architecturally different, and choosing between them involves real tradeoffs that are not fully resolved by XWayland compatibility layers or “it mostly works.” For infrastructure people and homelab operators who spend most of their day in terminals, editors, and browser windows, understanding these tradeoffs leads to a defensible choice. This post maps the full landscape — the paradigms, the architecture, the notable options, and the honest state of both the X11 holdout position and the Wayland migration path.

What a window manager actually does

A window manager has a specific, bounded job. It tracks the position, size, and stacking order of top-level windows on screen. It decides which window gets keyboard focus. It draws or delegates the drawing of window decorations — titlebars, borders, close buttons. It responds to events from the display server (a window wants to map itself, a client requests a resize) and issues instructions back (place this window at these coordinates with these dimensions).

That is all. A window manager does not manage your files, configure your network, play notification sounds, or draw a panel. Those are the additions that turn a WM into a desktop environment. GNOME layers Mutter (the WM/compositor), GNOME Shell (the shell and panels), Nautilus (file manager), GSettings/dconf (configuration), gnome-session (session management), gnome-keyring (secrets), libnotify/notification-daemon (notifications), NetworkManager applets, and pulseaudio/pipewire integration on top of each other and ships the result as a coherent product. KDE Plasma does the same with KWin plus an equivalent tower of Plasma frameworks. What you get from a full DE is a tested, integrated stack where the pieces are designed to work together.

What you get from a bare WM is the window manager alone. Everything else — the status bar, the launcher, the notification daemon, the screen locker, the network applet, the Bluetooth control, the clipboard manager, the polkit agent, the XDG portal implementation — you select, configure, and wire up yourself. The upside is that you pick exactly what you want and build a system that starts faster, uses less RAM, and puts every keybinding under your direct control. The downside is that the assembly tax is real and the failure modes are opaque.

The three paradigms

Window managers fall into three behavioral models that cut across both X11 and Wayland.

Stacking (also called floating) is the desktop-paradigm most people learned: windows overlap like papers on a desk. You drag them, resize them, and Alt+Tab between them. Openbox is the canonical lightweight stacking WM; it underlies the default desktop in LXDE and is still widely used as the WM inside full DE configurations where a basic floating compositor is wanted.

Tiling arranges every window as a non-overlapping tile that fills available screen space, typically managed by keyboard commands. New windows split space from existing ones; closing a window gives the space back. i3 is the archetypal tiling WM for X11. The keyboard-driven workflow eliminates mouse usage for layout management entirely.

Dynamic compositors support multiple named layouts — dwindle/spiral, master-stack, columns, monocle — and let you switch between them per-workspace or on the fly. Hyprland, awesome, and Qtile fall here: you get tiling by default but can switch to floating for specific windows or switch layout algorithms for a workspace that calls for it.

For a deeper treatment of the tiling workflow and the argument for why it pays off for keyboard-heavy work, see a deeper dive on tiling window managers.

The architectural fork: X11 versus Wayland

This is the crux. The two display systems handle the relationship between the window manager, the compositor, and the display server completely differently.

X11: separate processes, bolted together

On X11, the X server is a long-running process that owns the hardware (framebuffer, input devices). It speaks the X11 wire protocol to clients. A separate window manager process — i3, openbox, awesome, whatever you choose — connects to the X server as a privileged client. It uses X11 extension protocols (specifically the ICCCM and EWMH standards) to manage window geometry, decorations, and focus. It does not draw pixels by default; it just tells the server where windows go.

Compositing is bolted on. Without a compositor, windows are painted directly to the framebuffer with no intermediate buffer; dragging a window tears and leaves artifacts. When you add a compositor — Picom is the standard choice for X11 standalone WMs — it redirects all window rendering to off-screen textures, composites them, and outputs the result. The compositor runs as yet another separate process attached to the X server via the Composite extension.

X11 Stack
─────────────────────────────────────────────────────────
  Application A    Application B    Application C
       │                │                │
       └────────────────┴────────────────┘
                        │  X11 wire protocol
                   ┌────▼────┐
                   │ X Server│  (Xorg / Xwayland)
                   │ (Xorg)  │  owns hardware access
                   └────┬────┘
                        │  X11 Composite extension
            ┌───────────┼───────────┐
            │           │           │
      ┌─────▼─────┐     │    ┌──────▼──────┐
      │ Window    │     │    │  Compositor │
      │ Manager   │     │    │  (Picom)    │
      │ (i3/ob)   │     │    │  optional   │
      └─────┬─────┘     │    └─────────────┘
            │           │
          window      display
         geometry     output

This is powerful and flexible. You can swap any component independently: change WMs, change compositors, keep the X server. The downside is that the seams between processes are visible. Screen tearing was chronic before compositors were common. Security is poor: any X11 client can read keyboard input from any other client, intercept clipboard data, and take screenshots without the user’s permission. There is no security boundary at the display server.

Wayland: compositor is the window manager is the display server

Wayland collapses the stack. A Wayland compositor is simultaneously the display server (it directly presents frames to the DRM/KMS kernel interface), the compositor (it manages all window surfaces and their blending), and the window manager (it decides window geometry, stacking, and focus). There is no separate WM process. There is no separate display server you connect to. There is one process with privileged access to the hardware and a documented Wayland protocol over which clients communicate with it.

Wayland Stack
─────────────────────────────────────────────────────────
  Application A    Application B    Application C
       │                │                │
       └────────────────┴────────────────┘
                        │  Wayland protocol (Unix socket)
            ┌───────────▼──────────────────┐
            │     Wayland Compositor       │
            │  (sway / Hyprland / Mutter)  │
            │                              │
            │  ┌──────────┐ ┌──────────┐  │
            │  │  Window  │ │Compositor│  │
            │  │ Manager  │ │  Logic   │  │
            │  └──────────┘ └──────────┘  │
            │         ┌──────────┐        │
            │         │  DRM/KMS │        │
            │         │  Direct  │        │
            │         └──────────┘        │
            └──────────────────────────────┘
                        │
                   GPU / Display

The security model is substantially better: clients cannot snoop on other clients’ input, and screen capture requires explicit user consent via the xdg-desktop-portal mechanism. The performance model is also better: explicit sync via the linux-drm-syncobj-v1 protocol, introduced broadly in 2024 and widely deployed by 2025, eliminated the XWayland tearing and stuttering that was the last credible performance argument for staying on X11 for gaming. The cost is that you cannot swap out the WM independently of everything else. The compositor you choose is your display server, your compositor, and your WM, combined.

X11 apps run inside Wayland sessions via XWayland, which is an X server implemented as a Wayland client. XWayland translates X11 protocol calls into Wayland surface operations, giving legacy X11 applications a compatibility layer. It works well for most applications; the caveats are HiDPI scaling (XWayland surfaces are scaled at the compositor level, which can produce blur in some compositors) and the fact that XWayland clients do not inherit Wayland’s security boundary — they are still treated as X11 clients with X11’s permissive model.

The X11 standalone WM landscape

These run on Xorg. They are not being retired anytime soon — the kernel’s DRM subsystem still supports Xorg, and several major workflows depend on things Wayland has not yet uniformly solved. But their development is slowing: Xorg itself is in maintenance mode, receiving security fixes but no new features.

i3

The benchmark tiling WM. Config in a plain text file at ~/.config/i3/config, with an obvious syntax (think nginx-style blocks). Workspaces, marks, scratchpads, and a mature IPC protocol that lets external scripts manipulate the session. i3bar and i3status provide the default status bar. i3-gaps is a community fork that adds gaps between windows; many distro packages now ship with gaps built in.

i3 is deliberate and stable. Its development pace is intentionally conservative. If you have a working i3 setup, there is no compelling pressure to migrate; it will continue to work on X11 as long as Xorg works.

dwm

The suckless.org WM. Written in about 2,000 lines of C. Configured by editing the source and recompiling. Tags instead of workspaces (windows can belong to multiple tags simultaneously). No configuration file format at all — if you want to change a keybinding, you patch config.h and rebuild. The model is not hostile; it is an explicit philosophy that code is the configuration and the binary is the interface.

dwm demands more from the user than any other WM here. It rewards users who are comfortable reading and modifying C, want minimal memory overhead, and are willing to maintain their own patch stack. It has a large collection of community patches that add features without them being present in the default source.

bspwm

Binary space partitioning WM. All window management operations are issued via a socket using the bspc command-line tool; bspwm has no built-in keybinding handling. You pair it with sxhkd (the simple X hotkey daemon) for input. This separation is a design choice: bspwm manages layout, sxhkd manages keys, and neither has opinions about the other’s domain. Config is therefore split across two files: ~/.config/bspwm/bspwmrc (a shell script that runs bspc commands) and ~/.config/sxhkd/sxhkdrc (a keybinding file).

1
2
3
4
5
6
7
8

# bspwmrc snippet
bspc monitor -d I II III IV V VI VII VIII IX X

bspc config border_width         2
bspc config window_gap           12
bspc config split_ratio          0.52
bspc config borderless_monocle   true
bspc config gapless_monocle      true

awesome

A WM and widget toolkit configured and extended in Lua. Ships with a default configuration that is usable out of the box — you get a panel with a task list, a system tray, a clock, and workspaces. The Lua runtime means you can write arbitrary logic into your WM: auto-spawn applications on specific tags, write status bar widgets that make HTTP requests, or implement layout algorithms that don’t exist elsewhere. This power comes with Lua as a runtime dependency and a configuration that has more surface area than simpler WMs.

Qtile

Python as the WM. Same philosophy as awesome, different language. Groups (Qtile’s term for workspaces), configurable layouts, a built-in bar with Python-scripted widgets. Qtile is notable in 2026 because it runs on both X11 and Wayland — the same config file (with minor backend checks) works in both environments. The Wayland backend uses wlroots.

1
2
3
4
5
6
7

# qtile config.py – shared X11/Wayland backend detection
from libqtile import qtile

if qtile.core.name == "wayland":
    terminal = "foot"
else:
    terminal = "urxvt"

Openbox

A stacking WM, not a tiler. Extremely lightweight, XML-configured, and widely used as the WM component inside LXDE/LXQt. Openbox is the answer when you want something simpler than a full DE but prefer the floating paradigm. It handles decorations, stacking, and focus with minimal footprint. The compositing story requires adding Picom separately.

The Wayland compositor landscape

Sway

The first widely-adopted Wayland tiling compositor and still the stability baseline. Sway is an i3-compatible compositor: its config syntax is nearly identical to i3’s, its IPC protocol is a superset of i3’s, and i3-targeting tools (swaybar, swaylock, swaybg) have direct equivalents. Built on wlroots. Version 1.10, current in 2026, prioritizes stability over features.

Migrating from i3 to Sway is as close to a drop-in as the Wayland/X11 divide allows. Your bindsym lines, your workspace assignments, your exec_always rules — most transfer verbatim. The gaps you notice are Wayland-specific: some X11 tools stop working, global hotkeys behave differently, some screen capture workflows need to be rebuilt around PipeWire and xdg-desktop-portal-wlr.

# sway config excerpt — largely identical to i3
set $mod Mod4

input "type:keyboard" {
    xkb_options ctrl:nocaps
}

output DP-1 {
    resolution 3440x1440@144Hz
    position 0 0
}

bar {
    position top
    status_command i3status
}

bindsym $mod+Return exec foot
bindsym $mod+Shift+q kill
bindsym $mod+h focus left
bindsym $mod+l focus right
bindsym $mod+Shift+h move left
bindsym $mod+Shift+l move right

Hyprland

The current center of gravity for new Wayland tiling setups. Dynamic tiling, smooth animations, blur, rounded corners, shader effects, per-monitor DPI, per-monitor refresh rate, HDR. Version 0.54 (February 2026) introduced a complete redesign of the layout engine enabling per-workspace layouts and significant rendering performance improvements — particularly for integrated GPUs where the speedup is reported at 50–500% depending on hardware.

Hyprland is no longer built on wlroots. It forked to its own Aquamarine backend in 2024, which gives the project freedom to implement protocol support independently of wlroots’s release cycle. That’s a maintenance bet worth understanding: wlroots is the most widely tested Wayland compositor library, and deviating from it means some protocol implementations may diverge. In practice, Hyprland’s protocol coverage is excellent and in some cases ahead of wlroots compositors.

The ecosystem has matured around it: hyprpaper for wallpapers, hypridle for idle management, hyprlock for the screen locker, hyprpicker for color picking, and hyprpanel/waybar for status bars. The xdg-desktop-portal-hyprland package handles screen sharing and portal integration.

The NVIDIA situation is better than it was. NVIDIA 560+ series drivers on Hyprland work for most users. The LIBVA_DRIVER_NAME=nvidia environment variable and explicit sync flags are usually required; the Hyprland wiki documents this. It is not zero-configuration on NVIDIA, but it is no longer the reliable source of pain it was through 2023.

River

River is architecturally interesting: it implements the river-layout-v3 Wayland protocol, which allows a separate layout generator process to define window arrangement. River is the compositor but delegates the tiling algorithm to an external program. This means layout is scriptable in any language, the protocol is stable by design (“we do not break window managers”), and there were nine independent layout generators written within six weeks of the protocol being published.

River is written in Zig, uses wlroots, and is deliberately minimal. Tag-based workspace model (like dwm). Input handling through riverctl commands in a config shell script. It attracts users who want a Wayland-native compositor that shares the Unix philosophy of composable, replaceable components, and who are comfortable writing or choosing their own layout logic.

niri

niri is a scrollable-tiling Wayland compositor written in Rust. It implements a fundamentally different spatial model: windows are arranged in columns on an infinite horizontal strip, and you navigate by scrolling the strip. Opening a new window does not resize existing windows — it adds a column to the right. Workspaces are vertical; monitors have independent workspace sets.

niri workspace model (per monitor):
─────────────────────────────────────────────────────────
Workspace 1:  [  Terminal  ] [    Browser    ] [  Editor  ] ──► (scroll right)
Workspace 2:  [  Slack  ] [  Zoom  ] ──────────────────────────► (scroll right)
Workspace 3:  (empty)
     │
     ▼ (switch workspaces vertically)

niri reached a stable, daily-drivable state in 2024. The 2025 and 2026 releases added window rules, animations, screen capture portal support, and NVIDIA support. It is packaged by several distributions including CachyOS. It is not for everyone — the infinite-scroll model is either intuitive or disorienting depending on how you think about window layout — but it is stable, actively maintained, and genuinely different enough to be worth trying if standard tiling models have never clicked for you.

GNOME Mutter and KDE KWin

Both are Wayland compositors that happen to be deeply embedded in full desktop environments. Mutter combines a Wayland compositor, an X11 window manager, and a scene graph into the core of GNOME Shell. GNOME 50 (March 2026) dropped X11 support entirely — no X11 session, no fallback, Wayland only. KWin is KDE Plasma’s compositor; it supports both X11 and Wayland sessions and uses linux-drm-syncobj-v1 explicit sync and has optionally Vulkan rendering paths. KDE Plasma targets dropping the X11 session in Plasma 6.8, expected in 2027.

Neither Mutter nor KWin is typically used as a standalone compositor outside its parent DE. They are not configurable in the way sway or Hyprland are; they expose the DE’s settings UI, not a config file. They are listed here because they are technically Wayland compositors and because a decision guide that ignores “just use GNOME or Plasma” would be incomplete.

The assembly tax: what you build without a DE

Running a bare WM — whether X11 or Wayland — means building the following stack yourself. This is not a complaint; it is a list of decisions to make before you start.

The Wayland column adds one required dependency that has no X11 equivalent: xdg-desktop-portal. Screen sharing, file open/save dialogs from sandboxed apps, and a growing list of system integrations require a portal backend installed and running. For Hyprland users, that is xdg-desktop-portal-hyprland; for sway users, xdg-desktop-portal-wlr. For river and niri users, xdg-desktop-portal-wlr is typically used. If the portal is not running or not configured correctly, screen sharing in browsers and video conferencing apps will silently fail or show an empty chooser that never completes.

Global hotkeys deserve special mention. On X11, any application with the right permissions can grab a global keybinding. On Wayland, this is by design impossible for arbitrary applications; keyboard input is delivered only to the focused window. The xdg-desktop-portal global shortcuts portal exists but its implementation is patchy across compositors and applications in 2026. Applications like OBS, push-to-talk in Teamspeak, and clipboard managers that relied on global grabs often need compositor-specific workarounds or per-application configuration.

The X11-to-Wayland transition: honest status in 2026

The broad narrative — “Wayland has won” — is accurate for mainstream GNOME and KDE desktop usage. GNOME 50 is Wayland-only. Fedora Workstation 43 dropped the GNOME X11 session. RHEL 10 dropped X11 support in its default configuration. Ubuntu’s default session is Wayland. For desktop environments, the transition is largely complete.

For standalone WMs, the picture is more nuanced.

What works well in 2026:

• Wayland tiling compositors on AMD and Intel hardware are reliable and performant
• HiDPI and mixed-DPI multi-monitor setups work better on Wayland than X11 ever did
• Explicit sync via linux-drm-syncobj-v1 has eliminated XWayland tearing for most gaming and GPU-heavy workloads
• XWayland provides workable compatibility for the vast majority of X11 applications
• PipeWire as the audio/video plumbing layer is stable and widely deployed
• Screen sharing in major browsers (Firefox, Chromium) via portals works reliably when the portal is correctly configured

What is still rough:

• NVIDIA support is functional but not zero-configuration; the proprietary driver stack remains partially opaque and some edge cases in compositors remain undebuggable at the driver level
• Global hotkeys for non-DE applications remain a source of friction; there is no universal solution
• Some professional creative applications (certain CAD tools, older creative software) have X11 dependencies that XWayland does not fully satisfy
• Screen sharing failure modes are opaque when they fail — the chooser appears, nothing happens, and diagnosing whether the problem is in the portal, PipeWire, or the compositor requires more investigation than it should
• Remote display (forwarding Wayland sessions over SSH in the way DISPLAY=:0.0 forwarded X11) remains awkward; there is no wayland equivalent of X forwarding in common use
• Some input method frameworks for CJK input and accessibility tools that depended on X11’s AT-SPI or xinput model have incomplete Wayland replacements

X11 is not being deleted. Xorg is in security-fix-only maintenance mode, but it will be available for years. Running i3 on X11 in 2026 is a defensible choice, not a sign of failure to keep up. The correct question is whether the things Wayland does better (HiDPI, per-monitor refresh rates, security model, tearing-free rendering) are things you care about, and whether the rough edges are in workflows you use.

Compositor and WM comparison matrix

Decision guide

Use a full desktop environment (GNOME or KDE Plasma) if: you want something that works out of the box, your time is better spent on work than on configuring a desktop, you use applications that assume a full DE is present (some GTK/GNOME apps rely on gnome-keyring, some KDE apps rely on KWallet and the Plasma portal stack), or you are administering a machine used by others who did not sign up for the assembly tax.

Use Sway if: you are coming from i3 and want Wayland without learning a new config format, you value stability and a conservative development pace, and you want something that will work correctly on wlroots without tracking upstream closely.

Use Hyprland if: you want the most visually capable Wayland tiling compositor in 2026, you are on AMD or Intel hardware (NVIDIA works but needs extra configuration), you are starting fresh with a Wayland tiling WM, or you want the largest community of dotfile examples and support. Be prepared to track upstream changes; Hyprland moves fast.

Use niri if: the standard tiling model (static splits that resize on window open/close) has never felt right and the scrollable strip model sounds more natural, or if you work in prose-heavy or reading-heavy contexts where having many windows on a scrollable strip suits your workflow better than a fixed grid.

Use River if: you want a Wayland compositor that embodies the Unix composability philosophy, you are comfortable writing a layout generator script, and you want explicit architectural separation between compositing and window layout logic.

Stay on X11 (i3, bspwm, awesome) if: your workflow depends on global hotkeys that have no Wayland equivalent, you are using professional software with X11 dependencies that XWayland does not satisfy, you are on older NVIDIA hardware where Wayland driver support is inconsistent, or your setup is working and you have no concrete reason to change it. X11 is maintenance-mode, not end-of-life. It will be running in 2028 and beyond, just without new features.

Avoid running a bare WM as your first Linux desktop. The assembly tax is paid in confusion before it is paid in configuration. Start with GNOME or KDE, learn how the components interact by observing what the DE does for you, then strip away what you do not need. Going the other direction — starting with a bare WM and adding DE components piecemeal — works but is slower and more frustrating for someone who does not yet know what a polkit agent does or why screen sharing requires a portal.

The Linux window manager landscape in 2026 is wider than it has ever been, and the Wayland transition has not narrowed it. It has replaced one set of choices (which X11 WM, which compositor to bolt on) with a different set (which Wayland compositor, how to handle the portal and hotkey gaps). The architectural question — one unified process that is the compositor and the WM and the display server, versus a modular X11 stack of separate processes — is settled in favor of Wayland for new deployments. But settled architecture does not mean every workflow is equally well served, and understanding what you are actually running makes the difference between a desktop you fight and one you forget about.

Sources

• Hyprland 0.54 Wayland Compositor Brings Per Workspace Layouts — Linuxiac
• Hyprland — ArchWiki
• Hyprland Wiki — Nvidia
• GitHub — hyprwm/Hyprland
• Hyprland vs Sway vs COSMIC: Best Wayland Compositor for Developers in 2026 — Botmonster Tech
• Can I finally start using Wayland in 2026? — Michael Stapelberg
• Wayland vs X11: 2026 Comparison — DEV Community
• X11 vs Wayland in 2026: The Linux Display Protocol Shift — Linuxteck
• GitHub — niri-wm/niri: A scrollable-tiling Wayland compositor
• Niri 26.04: Scrollable-tiling Wayland compositor — Hacker News
• River brings modular window managers to Wayland — The Register
• River — Gentoo wiki
• GitHub — swaywm/sway: i3-compatible Wayland compositor
• Sway — ArchWiki
• GNOME 50 vs KDE Plasma 6.3 — FOSSLinux
• A Deep Dive into Wayland Compositor Internals: Mutter and KWin — OpenLib.IO
• AerynOS 2026.03 Brings GNOME 50 — Phoronix
• GitHub — qtile/qtile
• Qtile Wayland documentation
• Wayland Architecture: Separating the Compositor and Window Manager — Sesame Disk
• X window manager — Wikipedia
• Compositing window manager — Wikipedia
• Labwc 0.20 Wayland Compositor Released with wlroots 0.20 Support — Linuxiac
• 5 ways Wayland isn’t living up to its promises yet — XDA Developers
• Global Shortcut support on Wayland — tauri-apps/global-hotkey GitHub issue
• Window manager — ArchWiki
• Wayland — ArchWiki