[Back to all posts](/blog) ![Display Server, Window Manager, Desktop Environment: Who Does What on Linux](/_next/image?url=https%3A%2F%2Fik.imagekit.io%2Fgrbmndlassts%2Fblogs%2Flinux-display-server-window-manager-desktop-environment%2Fcover.jpg&w=3840&q=75) # Display Server, Window Manager, Desktop Environment: Who Does What on Linux November 6, 2026 · 8 min read linuxx11waylandgnomedesktop-environmentwindow-manager How the Linux GUI stack splits into kernel, display server, window manager and desktop environment, and why GNOME is more than a theme --- # Display Server, Window Manager, Desktop Environment: Who Does What on Linux There's Wayland and X11, which are called display servers but aren't servers in any sense I'd use the word. There's GNOME, which I filed under "theme". And there's Ubuntu, which is the OS. The "server" part is historical. X was built so an app could run on a big machine in the basement (the client) and show its window on a terminal on your desk (the X server). On a home PC both sit on the same box, and the name just stays. ## The pipeline I had backwards My first mental model: the OS manages CPU and GPU and talks to drivers, the display server calculates what to draw (coordinates, dimensions), and the desktop environment takes those instructions and puts them on screen.⁠‌‍‌ ‌‍ ‌​ ‍‍‌‍‌​‌‍‍‌‌ ​ ‌ ​​‌‍ ​‌‍​‌‌ ‍‌​‍ ‌‌ ​ ‌‍‌‌‌ ​‍‌ ‌‍‌‍‌‌‌ ​‍​‍ ‌‌ ‌ ‌‍‍‌‌‍ ‍‌‍‌​‌‍ ‌ ‌ ​‍ ‌‌‍ ‌‌‍​‌‌‍ ‍‌‍​‌‌‍‌ ‌‍‌‌‌ ​‍​‍ ‌‌‍‌​‌‍‌‌‌ ​ ‌‍‍ ‌ ‌​‌‍ ‌ ​​​‍ ‌‌‍‌‌‌‍ ‍‌ ‌‍‌‍‍‌‌ ​‍‌‍ ‌‍ ‍‌‍ ‌‌‍‌‌‌‍ ‍‌ ‌​​‍ ‌‌ ‌ ‌‍‍​‌‍ ​‍ ‌‌‍‌​‌‍ ‌‍‌‌‌ ​ ​‍ ‌‌ ‌ ‌‍‍​‌‍​‌‌ ‌​​‍ ‌‌‍ ‌‍ ‍​‍ ‌‌‍ ​‌‍‍‌‌‍ ‍‌ ‌‌‌ ‍​​ ‍‍​ ​‌​ ‌ ​ ‍‌​ ​ ​ ‍‌​ ‌​​ ​​​ ​‌​ ‌​​ ​ ​ ‍‍​ ​​​ ‌‌‌‍‌‌​ ‌​​ ​​‌‍‌​​ ​‍​ ‍‌‌‍​ ​ ​‌​ ‌‍​ ​‌​ ​ ​ ​‍​ ‍​​ ‌ ⁠ The last two steps are inverted. Apps draw their own content into a buffer in memory. They don't know where other windows are or what the refresh rate is. They hand over "here's my 800x600 window". The display server (or compositor) collects those buffers, routes keyboard and mouse input to whichever window is under the cursor, merges everything into one frame, and presents it through the graphics stack. The compositor doesn't push a finished image into the kernel as such. It renders through the GPU driver (Mesa, AMDGPU, NVIDIA) using graphics APIs like OpenGL or Vulkan, then uses DRM/KMS to set the video mode and flip the finished buffer onto the screen, which the GPU scans out over HDMI or DisplayPort. Rendering diagram... flowchart LR A["Applications"] -->|"buffers"| B["Compositor"] B -->|"OpenGL / Vulkan rendering"| C["GPU"] C -->|"DRM/KMS buffer presentation"| D["Kernel display subsystem"] D --> E["Monitor"] The panel, launcher and daemons of a desktop environment are ordinary clients in that diagram, same as VLC or Steam. No display server running means a black TTY even with GNOME installed, because its programs have nothing to connect to and die with `Cannot open display`. The display server has no idea what a taskbar is. If GNOME asks for a strip of pixels at the top of the screen, that's all it sees. ## The fourth component I assumed the window manager was part of the display server. In classic X11 it's a separate program. The X server is dumb on purpose: it allocates pixel space and catches input, and has no policy on how windows get managed. A client called the window manager makes the spatial decisions. Run X11 with no window manager and apps typically open at (0,0).⁠‌‍‌ ‌‍ ‌​ ‍‍‌‍‌​‌‍‍‌‌ ​ ‌ ​​‌‍ ​‌‍​‌‌ ‍‌​‍ ‌‌ ​ ‌‍‌‌‌ ​‍‌ ‌‍‌‍‌‌‌ ​‍​‍ ‌‌ ‌ ‌‍‍‌‌‍ ‍‌‍‌​‌‍ ‌ ‌ ​‍ ‌‌‍ ‌‌‍​‌‌‍ ‍‌‍​‌‌‍‌ ‌‍‌‌‌ ​‍​‍ ‌‌‍‌​‌‍‌‌‌ ​ ‌‍‍ ‌ ‌​‌‍ ‌ ​​​‍ ‌‌‍‌‌‌‍ ‍‌ ‌‍‌‍‍‌‌ ​‍‌‍ ‌‍ ‍‌‍ ‌‌‍‌‌‌‍ ‍‌ ‌​​‍ ‌‌ ‌ ‌‍‍​‌‍ ​‍ ‌‌‍‌​‌‍ ‌‍‌‌‌ ​ ​‍ ‌‌ ‌ ‌‍‍​‌‍​‌‌ ‌​​‍ ‌‌‍ ‌‍ ‍​‍ ‌‌‍ ​‌‍‍‌‌‍ ‍‌ ‌‌‌ ‍​​ ‍‍​ ​‌​ ‌ ​ ‍‌​ ​ ​ ‍‌​ ‌​​ ​​​ ​‌​ ‌​​ ​ ​ ‍‍​ ​​​ ‌‌‌‍‌‌​ ‌​​ ​​‌‍‌​​ ​‍​ ‍‌‌‍​ ​ ​‌​ ‌‍​ ​‌​ ​ ​ ​‍​ ‍​​ ‌ ⁠ No title bar, no close button, no border, and no way for you to drag or resize a window with the mouse. An app can still move or resize its own window through X requests, but nothing provides the usual behavior. If a window spawns over another, there's no built-in way to raise the one underneath. Start a window manager and it wraps each window in a frame, handles drags by telling the server "move this window from (100,100) to (300,200)", and owns shortcuts like `Alt + Tab`. So the stack is four things: | Layer | Job | Example | | ------------------- | ----------------------------------------------- | ------------------------- | | OS / kernel | hardware access: GPU, CPU, input devices | Linux | | Display server | pixel canvas, input routing, talking to clients | X.Org | | Window manager | borders, positioning, focus, stacking | Openbox, i3, KWin, Mutter | | Desktop environment | panel, tray, launcher, daemons, default apps | GNOME Shell, XFCE panel | Wayland itself is only a protocol, a rulebook for how clients and a compositor talk. A Wayland compositor implements the protocol and combines the display-server and window-management responsibilities. That's why Mutter under Wayland gets called "the" Wayland server, and why KWin and Sway are too. There's no separate Wayland daemon to point at. This is also where the overlap I kept running into comes from. GNOME ships its own window manager, Mutter, and gnome-shell hosts it. On my setup (GNOME on X11) it's Xorg as the display server, Mutter as the window manager, and the rest of gnome-shell plus the daemons as the desktop environment. One package, three roles. ## What a desktop environment is Kernel + display server + window manager is enough to run a graphical desktop. Everything else can be assembled separately. Run i3 or Openbox on X11 and you can open Firefox, compile code, play video. Audio, Wi-Fi and power are CLI commands or your own scripts. The desktop environment is everything added on top for convenience: - the shell: taskbar or top bar, system tray, app launcher, notification center, desktop icons - background daemons: volume keys, USB mounting (`gvfs` in GNOME), lid-close suspend, remembering monitor layout and scaling, Wi-Fi and Bluetooth pickers - shared conventions: one dark mode switch via dconf/gsettings that every app watches, MIME defaults for which app opens a `.pdf`, the file picker that pops up when Chrome says "Upload"⁠‌‍‌ ‌‍ ‌​ ‍‍‌‍‌​‌‍‍‌‌ ​ ‌ ​​‌‍ ​‌‍​‌‌ ‍‌​‍ ‌‌ ​ ‌‍‌‌‌ ​‍‌ ‌‍‌‍‌‌‌ ​‍​‍ ‌‌ ‌ ‌‍‍‌‌‍ ‍‌‍‌​‌‍ ‌ ‌ ​‍ ‌‌‍ ‌‌‍​‌‌‍ ‍‌‍​‌‌‍‌ ‌‍‌‌‌ ​‍​‍ ‌‌‍‌​‌‍‌‌‌ ​ ‌‍‍ ‌ ‌​‌‍ ‌ ​​​‍ ‌‌‍‌‌‌‍ ‍‌ ‌‍‌‍‍‌‌ ​‍‌‍ ‌‍ ‍‌‍ ‌‌‍‌‌‌‍ ‍‌ ‌​​‍ ‌‌ ‌ ‌‍‍​‌‍ ​‍ ‌‌‍‌​‌‍ ‌‍‌‌‌ ​ ​‍ ‌‌ ‌ ‌‍‍​‌‍​‌‌ ‌​​‍ ‌‌‍ ‌‍ ‍​‍ ‌‌‍ ​‌‍‍‌‌‍ ‍‌ ‌‌‌ ‍​​ ‍‍​ ​‌​ ‌ ​ ‍‌​ ​ ​ ‍‌​ ‌​​ ​​​ ​‌​ ‌​​ ​ ​ ‍‍​ ​​​ ‌‌‌‍‌‌​ ‌​​ ​​‌‍‌​​ ​‍​ ‍‌‌‍​ ​ ​‌​ ‌‍​ ​‌​ ​ ​ ​‍​ ‍​​ ‌ ⁠ - accessibility: screen reader (Orca), magnifier, sticky keys - a default app set on one toolkit: Nautilus, Text Editor, Loupe on GTK for GNOME; Dolphin and Konsole on Qt for KDE The launcher is a good example. Installing Firefox drops `/usr/share/applications/firefox.desktop` with lines like: INI ``` Name=Firefox Web Browser Exec=firefox %u Icon=firefox ``` GNOME reads every one of those files, pulls the icon from the current theme and draws the app grid. The display server doesn't know that those pixels represent an app icon. I first read all of this as a theme, then as a pile of variables. The variables part is half right, since dconf holds a lot of the shared state. The rest is a pile of programs with a theme on top. ## What I actually run GNOME on X11.⁠‌‍‌ ‌‍ ‌​ ‍‍‌‍‌​‌‍‍‌‌ ​ ‌ ​​‌‍ ​‌‍​‌‌ ‍‌​‍ ‌‌ ​ ‌‍‌‌‌ ​‍‌ ‌‍‌‍‌‌‌ ​‍​‍ ‌‌ ‌ ‌‍‍‌‌‍ ‍‌‍‌​‌‍ ‌ ‌ ​‍ ‌‌‍ ‌‌‍​‌‌‍ ‍‌‍​‌‌‍‌ ‌‍‌‌‌ ​‍​‍ ‌‌‍‌​‌‍‌‌‌ ​ ‌‍‍ ‌ ‌​‌‍ ‌ ​​​‍ ‌‌‍‌‌‌‍ ‍‌ ‌‍‌‍‍‌‌ ​‍‌‍ ‌‍ ‍‌‍ ‌‌‍‌‌‌‍ ‍‌ ‌​​‍ ‌‌ ‌ ‌‍‍​‌‍ ​‍ ‌‌‍‌​‌‍ ‌‍‌‌‌ ​ ​‍ ‌‌ ‌ ‌‍‍​‌‍​‌‌ ‌​​‍ ‌‌‍ ‌‍ ‍​‍ ‌‌‍ ​‌‍‍‌‌‍ ‍‌ ‌‌‌ ‍​​ ‍‍​ ​‌​ ‌ ​ ‍‌​ ​ ​ ‍‌​ ‌​​ ​​​ ​‌​ ‌​​ ​ ​ ‍‍​ ​​​ ‌‌‌‍‌‌​ ‌​​ ​​‌‍‌​​ ​‍​ ‍‌‌‍​ ​ ​‌​ ‌‍​ ​‌​ ​ ​ ​‍​ ‍​​ ‌ ⁠ It works, it doesn't overwhelm me with options, and I can change what I want with CLI commands and dconf. Wayland still feels immature to me, and a lot of good extensions don't work on it. GNOME's own apps (Nautilus, terminal, text editor, image viewer) are good and need no extra ceremony. Upstream GNOME is removing its X11 session, so this setup has an expiry date. Newer GNOME releases will only offer Wayland, which means staying on X11 eventually requires an older release or a desktop that still ships an X11 session, like KDE or XFCE. X11 apps keep running through XWayland, but extensions are written against Mutter and gnome-shell, so the ones that matter to me need porting by their authors.