YSERVER: A Modern X11 Server Built From Scratch In Rust With Claude Code

Open-source developer Jos Dehaes wrote in to Phoronix this morning to announce something that sounds borderline reckless on paper: a brand new X11 server, written from scratch, in Rust, with a healthy assist from Claude Code. It is called yserver, and unlike most weekend display-server experiments, it already runs real desktop environments instead of a single xterm in a debugger.

What yserver Actually Is

The X.Org Server is one of those pieces of infrastructure that everyone depends on and almost nobody wants to touch. The codebase carries roughly four decades of accumulated compatibility logic: the DDX driver ABI, indirect GLX, endian-swapped clients from big-endian workstations that mostly stopped shipping in the 2000s, multiple-screen Zaphod mode, and a forest of non-TrueColor visuals nobody renders to anymore. yserver's stated goal is not to clone any of that.

In Dehaes' words: "The goal is not to clone Xorg. It is to provide a practical X11 server that runs real desktop environments, window managers, and applications on modern Linux while dropping legacy baggage (multiple screens, non-TrueColor visuals, indirect GLX, the DDX driver ABI, endian-swapped clients, and so on)."

That framing matters. Wayland's pitch for years has been "X11 is unfixable, start over with a new protocol." yserver makes a different bet: the X11 protocol is fine for a lot of people, it is the implementation that is crushed under historical weight. Keep the wire protocol that thousands of existing clients already speak, throw away the implementation cruft, and write a clean core in a memory-safe language.

The Feature List Is Surprisingly Complete

The part that separates this from a proof of concept is the extension coverage. A display server is only as useful as the extensions your toolkit and window manager expect to find. yserver currently supports:

• RandR for output configuration and mode setting
• DRI3 for buffer sharing with the GPU
• GLX for OpenGL on X
• MIT-SHM for shared-memory image transport
• Composite for offscreen window redirection

That Composite support is the load-bearing one. With Composite working, Dehaes demonstrated Compiz running on top of yserver, wobbly windows, spinning cube, and all. If your new server can drive a compositing window manager that historically poked at every dark corner of the X server, you have covered a lot of API surface.

On the desktop side, yserver can currently bring up a full MATE, Xfce, or Cinnamon session. Those are GTK-heavy environments with panels, system trays, notification daemons, and settings managers, not toy setups. Getting Cinnamon to log in cleanly means the input handling, window management hints, and EWMH/ICCCM property machinery are all functioning.

{{IMAGE:2}}

The Claude Code Angle

Looking at the Git history, yserver was written with substantial help from Claude Code, Anthropic's agentic CLI. This is worth sitting with for a moment, because a from-scratch X11 server is exactly the kind of project that used to be considered AI-assistance-proof. The X11 protocol specification is enormous, the request and reply encodings are fiddly, byte-order and atom handling are full of edge cases, and the feedback loop is brutal: a single malformed reply and the client disconnects with no useful error.

What makes it tractable is that the protocol is exhaustively documented and deterministic. The request formats, the extension specs, the visual and pixmap format negotiation, all of it is written down in protocol references that have been stable for years. That is a near-ideal setup for an AI coding agent: a precise spec, a clear correctness oracle (does the real client connect and render?), and a tight test loop where you run a window manager and watch what breaks. The hard creative judgment, which legacy features to drop, where to draw the Rust module boundaries, how to model the resource ID space, still lands on the human. The mechanical translation of spec text into correct encoder/decoder code is where the agent earns its keep.

Why A Homelab Builder Should Care

My interest here is practical rather than ideological. On the boxes I run, X11 still does things Wayland makes awkward. Network transparency for forwarding a single GUI app over SSH without a full remote desktop stack. Rock-solid behavior under VNC and headless virtual framebuffers for machines that have no monitor attached. Window managers and automation tooling that were written against X and have no Wayland equivalent. A leaner X server that starts faster, uses less memory, and has a smaller attack surface is directly useful for a rack of low-power nodes where every megabyte of RAM on an idle login screen is megabytes not spent on containers.

Memory safety is the other quiet win. The display server sits in a privileged position, parsing untrusted input from every client that connects. A decade of X.Org CVEs has been dominated by buffer overflows and integer mishandling in exactly that parsing path. Rewriting the request-parsing core in Rust does not magically make it bug-free, but it does take an entire class of memory-corruption bugs off the table, which is meaningful for a process that historically ran as root and touched the hardware directly.

The trade-offs are real and the project does not hide them. Dropping the DDX driver ABI means yserver relies on the modern kernel-mode-setting and GPU stack rather than the old userspace driver model, so your acceleration story depends on what DRI3 and the kernel give you. Dropping multi-screen Zaphod mode and exotic visuals means a small set of unusual setups will not be served. For the vast majority of single-GPU, TrueColor, KMS-based Linux machines, which is to say almost everything built in the last fifteen years, none of those removals cost anything.

Where It Stands

yserver is MIT-licensed and the source is up on its GitHub repository, linked from the Phoronix announcement. It is early, and "runs three desktop environments and Compiz" is a starting line rather than a finish line. There is no published benchmark suite yet comparing input latency, frame delivery, or memory footprint against X.Org, and that is exactly the data I want to see next. A clean-room Rust server with a trimmed feature set should win on resident memory and startup time, and it would be good to put numbers behind that intuition rather than assume it.

For now, the notable thing is that a single developer, working with an AI agent, produced something that boots a real desktop on a protocol everyone assumed was too gnarly to reimplement. Whether yserver grows into daily-driver infrastructure or stays a sharp technical demonstration, it is a concrete data point on what one motivated person can now build against a well-specified target.