yserver 1.8.0 ships with VRR, hardware cursors, and OpenBSD support
A substantial release for the from-scratch Rust X11 server adds variable refresh rate, hardware cursors, and OpenBSD support to a project built largely with AI assistance.
yserver 1.8.0 hit the streets today. That's when maintainer Jos Dehaes pushed commit 46e30e1 off the master branch, moving the project from v1.7.1 to what's its most substantial release yet.
X11 predates the Linux kernel. Released in 1987 by the MIT X Consortium, it's now more than two decades older than the system software it usually runs on. Most of your Linux desktop still draws through it, even as Wayland quietly eats into its market share.
yserver is a from-scratch attempt to rebuild the X server in Rust. It's developed under the GitHub handle joske, and per multiple outlets it was built largely with AI coding tools like Claude Code. It runs real desktop environments like Cinnamon, MATE, XFCE, and i3 while skipping decades of cruft that weigh down Xorg.
What's actually new in 1.8.0
The diff between v1.7.1 and v1.8.0 spans 259 commits across 747 files. Nine contributors touched it. Three themes stand out: an internal re-architecture, real graphics features, and new-platform support layered over a pile of Xorg-parity fixes.
The headline feature is VRR. Contributor @ariel3259 built it, in two flavors. --vrr turns variable refresh rate on for a monitor being directly scanned out, meaning a fullscreen client is composited straight to the screen. --vrr all pushes further, applying it to every directly scanned-out window, NVIDIA proprietary clients included. Those don't set the _VARIABLE_REFRESH property, so yserver instead leans on the same app lists NVIDIA and Mesa already use. You can whitelist or blacklist specific programs either way.
Tearing on demand is also from @ariel3259. Fullscreen clients that ask for asynchronous presentation get uncapped direct scanout. They flip frames as soon as they're ready, no cap. The catch is deliberate. Such clients may tear. yserver advertises PresentCapabilityAsync rather than the more permissive PresentCapabilityAsyncMayTear, so it doesn't oversell the deal.
Hardware cursors on atomic KMS are another win. yserver assigns a cursor plane to every CRTC when a full assignment exists, and cursor moves no longer kill direct scanout. Previously a cursor could force a re-composite. Now updates stay cheap.
Gamma correction now routes through the modern atomic GAMMA_LUT property. The old SETGAMMA ioctl is gone, which is cleaner and plays nice with tools like redshift.
Multi-monitor setups get hardened too. Direct scanout now tolerates monitors with slightly mismatched refresh rates. Flip one off or yank a cable and the others stay lit. An xrandr change to one output leaves the rest alone.
There's progress on macOS as well. The experimental Apple Silicon support gained rootless mode, where each X window becomes its own native Mac window. A Settings window landed inside yserver.app too. And after FreeBSD, yserver now runs on OpenBSD, reaching beyond Linux into another BSD with Linux-compatible DRM and UEFI display APIs.
That's not nothing. It's a lot of surface area for one release.
The refactor nobody'll see but everyone needs
A big chunk of v1.8.0 doesn't show up in a demo. It's housekeeping, and it matters more than most of the flashier features for the project's long-term health.
yserver grew some enormous single source files. Dehaes split them apart. Tests moved out of the biggest files, process_request.rs broke into per-extension modules, and the Vulkan renderer plus scene compositor got their own dedicated yserver-render crate. A CI check now enforces the new source-layout rules, and clippy runs on FreeBSD.
The architecture breaks into four crates. yserver-protocol handles wire-level X11 encode/decode with its own generated parsers. yserver-core holds the protocol-level core: clients, windows, atoms, selections, input dispatch. yserver-render is the new one. And yserver itself is the binary, covering both the nested ynest and the standalone DRM/KMS server.
The core loop is single-threaded on purpose. No Arc<Mutex> shared state, no per-client pump threads. The logic is that protocol invariants stay obvious when threads can't step on each other.
The rendering side splits further under kms/render/. PlatformBackend owns the DRM device and Vulkan instance. DrawableStore is the single source of truth for every drawable. RenderEngine turns drawing requests into Vulkan command buffers. SceneCompositor walks the window tree once per present. FrameBuilder coalesces a whole frame's worth of painting into one submission.
yserver speaks native-endian X11 only. No endian-swapped clients. It implements the extensions real desktop software depends on: BIG-REQUESTS, COMPOSITE, DAMAGE, DRI3, GLX, PRESENT, RANDR, RENDER, SHAPE, XInput2, XKB, XTEST. It validates protocol completeness by running the X.Org X Test Suite (xts5) against itself. Around mid-2026 that scored 66.2 percent, respectable given the project's explicit callout that it won't replicate every Xorg quirk. The wave of parity fixes in v1.8.0 suggests meaningful progress past that figure.
Two capabilities compile in only when you ask for them. The tcp-transport flag enables a TCP listener; the xdmcp flag enables thin-client XDMCP. Both sit off by default in packaged builds. Dehaes' reasoning is that listening on TCP widens exposure, so the capability should simply be absent rather than merely switched off.
The security model is worth flagging. yserver doesn't yet enforce per-client capability restrictions. A client can read other clients' windows, watch global input, and inspect the clipboard. Those are the inherited structural flaws of X11 itself, carried over into this build. There's no xhost-style access control either. The MIT-MAGIC-COOKIE-1 cookie is the entire boundary. The setup docs flag this before you expose a display over TCP.
It's a lot to take in for a display server, and the AI-assisted angle cuts both ways. X11's protocol is famously intricate, which makes this a genuinely high-stakes test case for AI-generated codebases. Yserver being largely built with Claude Code is a curiosity in its own right, and the bigger question, whether old, intricate protocols can be faithfully rewritten by AI tools, stays open.
On the upside, yserver targets near-Xorg performance, and Dehaes openly invites people to run Steam games on it. That's an ambitious bar for a from-scratch server. The fact that it drives DRM/KMS and Vulkan directly is what gets it there without a translation layer.
Whether yserver becomes your daily driver is another matter entirely. Wayland dominates now, and though it still has rough edges for remote desktoping, accessibility, and legacy toolkits like Motif, its install base is enormous. yserver fills a real niche. It's modern X11 without 30 years of baggage, which matters for holdouts and tinkerers, but it's a niche for those crowds, not the mainstream.
Head here to the GitHub release page if you want to try it. The source, binary packages, and full changelog all live there.
