The X Window System Explained

X11 has powered Linux graphical desktops for decades, yet most users treat it as a black box. Understanding how the X Window System actually works — and how Wayland rethinks it — makes you a better troubleshooter and helps you make informed choices about your desktop stack. This guide tears open that black box.

The Core Concept: Server and Clients Are Backwards

The first thing that trips everyone up: in X11, the naming is counterintuitive. The X server is the program that controls your physical hardware — your GPU, keyboard, and mouse. The X clients are the applications (a terminal, a browser, a text editor) that connect to that server and ask it to draw windows on your behalf.

This naming made more sense in the 1980s, when the X server often ran on a powerful workstation while thin-client machines ran the applications remotely over a network. The server served display resources to client programs. That network-transparent design is baked into the protocol to this day.

The Display Variable and TCP/Unix Sockets

X clients find the server by reading the DISPLAY environment variable. Its format is hostname:displaynumber.screennumber. On a local machine you will almost always see:

echo $DISPLAY

Output will typically be :0 or :1 — meaning display 0, screen 0, on the local host. The X server listens on a Unix domain socket at /tmp/.X11-unix/X0 for local connections and historically on TCP port 6000+N for remote ones. Modern distributions disable TCP listening by default for security reasons.

The Display Manager: Your Login Screen

Before any of this starts, something has to launch the X server and present a login screen. That is the job of the display manager (DM), sometimes called a login manager. Common ones include GDM (GNOME), SDDM (KDE), and LightDM. They run as systemd services.

To see which display manager is active and its status:

systemctl status display-manager

To switch the default display manager (example: switching to SDDM on a Debian/Ubuntu system):

sudo dpkg-reconfigure sddm

On Fedora/RHEL systems, enable a different DM like this:

sudo systemctl disable gdm --now
sudo systemctl enable sddm --now

On Arch:

sudo systemctl enable sddm
sudo systemctl disable lightdm

After a successful login, the display manager hands control to a session script, which is where the window manager or desktop environment starts.

The Window Manager

The X server draws primitives — rectangles, lines, text — but it does not decide where windows go, how their title bars look, or how you resize them. That is the window manager's job. The window manager is just another X client with special privileges: it intercepts events and manages window placement.

Window managers range from minimal (openbox, i3, sway) to full desktop environments like GNOME Shell or KWin (KDE). A desktop environment bundles a window manager with a compositor, a panel, a file manager, and a settings daemon.

You can confirm which window manager is running:

wmctrl -m

Or check the process list for common names:

ps aux | grep -E 'openbox|i3|kwin|mutter|xfwm'

The Compositor

Classic X11 draws directly to the screen via shared memory buffers, which causes tearing and limits visual effects. A compositor solves this by redirecting all window output to off-screen buffers, compositing them into a final image, and presenting it in sync with the display refresh. On modern desktops, the compositor is built into the window manager (Mutter for GNOME, KWin for KDE). Standalone compositors like picom are common with lightweight window managers.

X11 Configuration

Modern X servers are largely autoconfigured via udev and kernel modesetting. Manual configuration lives in /etc/X11/xorg.conf (rarely needed) or more commonly in drop-in files:

ls /etc/X11/xorg.conf.d/
ls /usr/share/X11/xorg.conf.d/

To generate a baseline config from detected hardware (useful when something is broken):

sudo Xorg -configure

This produces /root/xorg.conf.new which you can inspect and then copy into place.

The X server log is the first place to look when a session fails to start:

cat /var/log/Xorg.0.log | grep -E '\(EE\)|\(WW\)'

Entries marked (EE) are errors; (WW) are warnings.

Xorg Permissions and the Kernel

Historically, Xorg ran as root to access GPU hardware directly. Modern distributions use rootless Xorg (introduced in Xorg 1.16), which relies on kernel modesetting (KMS) and logind for hardware access. You can verify:

ps aux | grep '[X]org'

If the process owner is your regular user rather than root, rootless mode is active. This meaningfully reduces the attack surface of the X server.

How Wayland Differs

Wayland is not a drop-in replacement for X11; it is a different protocol and architecture. Key differences:

• No separate server process: The Wayland compositor combines the roles of display server, window manager, and compositor into one program. There is no standalone Wayland server daemon equivalent to Xorg.
• Direct rendering: Clients render to their own buffers using the GPU directly (via DRM/KMS and EGL). The compositor imports those buffers via wl_buffer and composites them. Fewer copies, less latency, no tearing by design.
• No network transparency by default: The Wayland protocol has no built-in remote display capability. Tools like waypipe or VNC/RDP solutions fill this gap when needed.
• Stronger isolation: Clients cannot spy on each other's input events or window contents, which was trivially possible under X11.
• XWayland for compatibility: A compatibility layer called XWayland runs an X server as a Wayland client, allowing unported X11 applications to run on a Wayland compositor with minimal friction.

To check whether your current session is running X11 or Wayland:

echo $XDG_SESSION_TYPE

Output will be x11 or wayland.

Verifying Your Graphical Stack

Run this small diagnostic sweep to map out exactly what is running on your system:

# Session type
echo "Session: $XDG_SESSION_TYPE"

# Display manager
systemctl show display-manager.service --property=Id

# Desktop / window manager
echo "Desktop: $XDG_CURRENT_DESKTOP"

# Compositor or Xorg process
ps aux | grep -E '[X]org|[w]eston|[m]utter|[k]win'

# GPU driver in use
glxinfo | grep 'OpenGL renderer'   # X11
# or for Wayland:
wayland-info 2>/dev/null | head -20

Troubleshooting Common Issues

Black screen after login

Check the display manager journal and the Xorg log:

journalctl -u display-manager -n 100
cat /var/log/Xorg.0.log | grep '(EE)'

A missing or mis-matched GPU driver is the most common cause. On Debian/Ubuntu verify the driver package is installed; on Fedora check dnf list installed | grep xorg-x11-drv.

Application refuses to open on Wayland (missing DISPLAY)

Install and ensure XWayland is running, then set the display variable explicitly as a workaround:

DISPLAY=:0 some-x11-app

Screen tearing under X11

Enable a compositor if you are on a lightweight WM, or add a TearFree option for Intel/AMD in an xorg.conf.d snippet:

sudo tee /etc/X11/xorg.conf.d/20-tearfree.conf <<'EOF'
Section "Device"
    Identifier "GPU"
    Driver     "modesetting"
    Option     "TearFree" "true"
EndSection
EOF

Cannot authenticate for display manager after system update

A mismatched xauth cookie can block logins. Clear the stale cookie file and restart:

rm -f ~/.Xauthority
sudo systemctl restart display-manager