X11 is version 11 of the X Window System protocol, the network-transparent windowing system that has provided the graphical display layer of Unix and Linux desktops since 1987. On Linux desktops, X11 defines how applications open windows, draw into them and receive keyboard and mouse input through a central display server, usually the X.Org Server.
X11 separates mechanism from policy: the server manages screens and input devices, while a separate window manager decides how windows look and behave. This design made X11 extremely flexible and long-lived, and it also explains why Linux desktops are now moving to its successor, Wayland.
How the X11 client-server model works
X11 works as a client-server protocol in which the X server owns the display, keyboard and mouse, and applications act as X clients that send requests to it. The naming feels reversed to many people: the server runs on the machine with the screen, and the client may run anywhere on the network.
Clients connect through a Unix domain socket for local use or TCP port 6000 plus the display number for remote use. The DISPLAY variable, for example :0 or host:1, tells a client which server to use. Requests such as creating a window or drawing a line travel to the server, and events such as key presses, pointer motion and exposure notices travel back.
| Component | Role | Example |
|---|---|---|
| X server | Owns display and input, executes drawing requests | X.Org Server, XWayland |
| X client | Application that opens windows and handles events | Terminal, browser, editor |
| Window manager | Special client that places and decorates windows | Openbox, i3, Mutter in X11 mode |
| Compositor | Combines window images for effects and tear-free output | Picom, built-in compositors |
| Client libraries | Encode and decode the wire protocol | Xlib, XCB |
Extensions that kept X11 alive
The core X11 protocol has barely changed since 1987, so new capabilities arrived as protocol extensions that a client can query and use if the server supports them. Modern X11 desktops depend on these extensions far more than on the original drawing primitives.
| Extension | What it adds | Why it matters |
|---|---|---|
| XRandR | Resolution, rotation and multi-monitor layout | Hot-plugging displays |
| XInput 2 | Multiple pointers, touch and precise scrolling | Modern input devices |
| Composite | Off-screen window storage | Transparency and compositing |
| RENDER | Anti-aliased, alpha-blended drawing | Smooth fonts and graphics |
| GLX and DRI3 | Direct hardware-accelerated rendering | OpenGL and Vulkan performance |
| MIT-SHM | Shared-memory image transfer | Fast local image updates |
In practice, most toolkits now render pixels on the client side with the GPU and hand finished images to the server. The server’s own drawing commands are rarely used, which means much of X11’s original architecture has become an expensive intermediary.
X11 compared with Wayland
Wayland replaces X11 by merging the display server, window manager and compositor into one compositor process and by letting clients submit complete buffers. The change removes decades of legacy and closes several security gaps, but it also removes some behavior that X11 users relied on.
| Aspect | X11 | Wayland |
|---|---|---|
| Architecture | Separate server, window manager and compositor | Single compositor |
| Client isolation | Any client can read input and screen contents | Clients see only their own windows |
| Network transparency | Built into the protocol | Requires separate tools |
| Tearing and scaling | Hard to avoid tearing, mixed DPI is awkward | Frame-perfect output, per-monitor scaling |
| Legacy compatibility | Native | Through XWayland |
XWayland is an X server running as a Wayland client, so older X11 applications keep working on Wayland desktops. Major distributions and desktop environments now default to Wayland, and some have removed their X11 session entirely, while the X.Org Server itself receives mainly maintenance and security fixes.
When X11 is still the practical choice
X11 remains a sensible choice where its flexibility or legacy compatibility outweighs Wayland’s advantages. The decision depends on hardware, software and workflow rather than on a general preference.
| Situation | Better fit | Reason |
|---|---|---|
| Lightweight or tiling window manager without a Wayland port | X11 | Window manager exists only for X11 |
| Automation tools that inject input or read other windows | X11 | No isolation between clients |
| Remote display of a single application over SSH | X11 forwarding | Built-in network transparency |
| Laptop with mixed-DPI external monitors | Wayland | Per-monitor fractional scaling |
| Security-sensitive desktop | Wayland | Clients cannot snoop on each other |
Security weaknesses and common problems
The most serious X11 weakness is the lack of isolation between clients: any application connected to the server can log keystrokes, capture the screen and inject input into other windows. This was acceptable in trusted multi-user workstations of the 1980s but conflicts with modern sandboxing.
- Exposed TCP listeners: enabling port 6000 without authentication gives remote hosts full control of the display, so modern servers disable TCP listening by default.
- Weak access control: the command
xhost +disables checks entirely; Xauthority cookies are the safer mechanism. - Slow remote sessions: modern toolkits send large images, so X11 forwarding over high-latency links is often sluggish.
- Screen tearing: without a compositor or a correctly configured driver, video and scrolling show visible tearing.
- Privilege concerns: the X server historically ran as root, which made its large code base an attractive attack target.
In simple terms
X11 is the traffic controller for windows on many older and current Linux computers. Programs ask it to open a window and draw something, and it tells them when you click or type.
It was designed in an era when one powerful computer served many screens, so it can even show a program running on another machine. That flexibility comes at a price: every program can watch what the others are doing, which is why newer desktops are switching to a safer system called Wayland.
A practical example
A research engineer needs to inspect simulation output with a small plotting tool installed on a remote compute server that has no desktop. Instead of copying several gigabytes of data to a laptop, the engineer connects with ssh -X, which tunnels X11 traffic through the encrypted SSH connection.
When the plotting tool starts on the server, its window appears on the engineer’s local desktop, and mouse and keyboard input travel back over the same tunnel. Over the campus network the tool responds smoothly; from home, with about 40 ms of latency, redraws become noticeably slower but remain usable.
The outcome is that the engineer analyzes the data where it lives, with no remote desktop software installed and no data transfer, using a capability built into X11 for decades.