A display server is the program that owns the screen, keyboard and pointer on a graphical system and coordinates how applications draw windows and receive input. In desktop environments on Linux and other Unix-like systems, it sits between the kernel graphics and input drivers below and the GUI toolkits and applications above, so that dozens of programs can share one physical display safely.
The two dominant implementations are the X Window System (X11, usually the X.Org Server) and the Wayland protocol, which is implemented directly inside the compositor. Windows and macOS have equivalent components, but they are integrated into the operating system and rarely discussed as a separate, replaceable layer of software.
What a display server does
A display server performs three core jobs: it manages access to the graphics hardware, it routes input events to the correct client, and it enforces the rules that keep one application from interfering with another. Applications act as clients that connect through a socket and speak a defined display protocol, while the server acts as the single authority over what appears on each monitor.
Below the server, the Linux kernel provides Direct Rendering Manager (DRM) and kernel mode setting (KMS) for screens and the evdev interface, usually wrapped by libinput, for keyboards, mice and touchpads. The server configures resolutions and refresh rates, opens input devices and decides which window has keyboard focus and which window lies under the pointer.
The following table separates the responsibilities that a display server typically carries from those handled by neighboring components.
| Responsibility | Typical owner | Notes |
|---|---|---|
| Mode setting and outputs | Display server via KMS | Resolution, refresh rate, multi-monitor layout |
| Input routing | Display server via libinput | Focus, pointer position, key repeat |
| Window placement and decorations | Window manager or compositor | Separate program in X11, merged in Wayland |
| Pixel rendering inside a window | Application and GUI toolkit | Usually GPU-accelerated through OpenGL or Vulkan |
| Final image composition | Compositor | Blends window buffers into one frame |
X11 and Wayland compared
X11 is a network-transparent protocol designed in the 1980s, when the server drew lines, text and rectangles on behalf of clients. Modern toolkits render almost everything themselves and send finished images, so much of the original X11 drawing model is now unused, while extensions such as Composite, RandR and XInput2 carry the real workload.
Wayland reduces the display server to a compositor that receives finished client buffers and decides how to present them. Each client renders into its own buffer, often shared with the GPU through dmabuf, and the compositor combines them into a frame synchronized with the display refresh. The comparison below summarizes the practical differences.
| Aspect | X11 (X.Org Server) | Wayland compositor |
|---|---|---|
| Architecture | Server plus separate window manager and compositor | One process combines all three roles |
| Client isolation | Any client can read input and screen contents | Clients see only their own surfaces |
| Tearing control | Depends on driver and compositor settings | Frame-perfect presentation by design |
| Screen capture | Unrestricted by the protocol | Mediated by portals and PipeWire |
| Remote display | Built into the protocol | Provided by separate tools and protocols |
| Mixed refresh rates and scaling | Limited and inconsistent | Per-output scaling and refresh supported |
Legacy X11 applications still run on Wayland desktops through Xwayland, an X server that runs as a Wayland client. This compatibility layer is the main reason most users can switch sessions without losing older software.
Relationship to the compositor and window manager
The display server, the window manager and the compositor are distinct roles that may or may not live in one program. Under X11 they are separate: the X server handles hardware and protocol, a window manager such as Openbox positions windows, and an optional compositor adds transparency, shadows and vsync. Under Wayland, the compositor is the display server, so GNOME Mutter, KDE KWin, Sway and similar programs carry all three responsibilities.
This merger changes what a desktop environment can do. A Wayland compositor controls every pixel and every input event, which simplifies features such as fractional scaling and gesture handling, but it also means that tasks once solved by small independent X11 utilities, such as global hotkeys or color pickers, now require explicit protocols or desktop portals.
Security and performance characteristics
The most important security difference is client isolation. Under X11, any connected client can log keystrokes, inject input and capture the whole screen without special privileges, which makes the display server a weak boundary between applications. Wayland removes those abilities from ordinary clients and grants them only through compositor-specific protocols or user-approved portal dialogs.
Performance depends more on drivers and compositor design than on the protocol itself, but Wayland avoids extra buffer copies by passing GPU buffers directly. Typical quantities that matter in practice are summarized below.
| Parameter | Typical range | Effect |
|---|---|---|
| Refresh rate | 60 to 240 Hz | Sets the frame budget, about 16.7 ms at 60 Hz |
| Scale factor | 100 to 300 percent | Controls size of text and controls on dense panels |
| Presentation latency | One to three frames | Delay between input and visible result |
| Adaptive sync | Off or variable refresh | Reduces stutter in games and video |
| Color depth | 8 or 10 bits per channel | Affects banding and HDR capability |
Choosing and troubleshooting a display server session
Most current distributions start a Wayland session by default for GNOME and KDE Plasma and offer an X11 session as a fallback at the login screen. The choice matters mainly for older tools, certain remote desktop setups and some proprietary drivers. A short decision guide follows.
| Situation | Recommended session | Reason |
|---|---|---|
| Laptop with mixed-DPI monitors | Wayland | Per-output fractional scaling works reliably |
| Legacy automation tools that inject input | X11 | Such tools depend on unrestricted X11 access |
| Security-sensitive workstation | Wayland | Applications cannot spy on each other |
| Old window manager or custom X11 setup | X11 | Configuration may not exist for Wayland |
| Screen sharing in video calls | Either, with current software | Wayland requires portal and PipeWire support |
Common pitfalls include blurry applications that run through Xwayland at fractional scales, missing screen sharing when portal packages are absent, and hotkey tools that silently stop working. Checking the session type, usually through the XDG_SESSION_TYPE environment variable, is the first diagnostic step when graphical behavior differs between machines.
A non-technical view
Think of the display server as the traffic controller for your screen. Many programs want to show something at the same time, and each one wants to know when you type or click. The display server decides which program gets which part of the screen and sends each keypress to the right window.
Older systems used a very open controller that let any program watch everything. Newer systems use a stricter controller that keeps programs apart, which is safer and usually smoother, but some old tools need extra help to work with it.
A concrete example
A software developer runs a Linux laptop with a built-in 14-inch panel at 200 percent scaling and an external 27-inch monitor at 100 percent. In an X11 session, applications look either too small on the laptop or too large on the monitor, and dragging a window between screens does not adjust its size cleanly.
After switching to a Wayland session at the login screen, the compositor assigns each output its own scale factor, so text looks sharp on both displays. One older clipboard utility no longer works, so the developer replaces it with a Wayland-aware tool. Screen sharing in video meetings works after the desktop portal package is installed. The result is a consistent, sharper multi-monitor setup with better isolation between applications.