YServer 1.7.1 lands with eight fixes, no feature list, for the from-scratch Rust X11 server
A surgical point release targets KDE highlight glitches, stalling GPUs, and adds per-second telemetry.
YServer 1.7.1 landed today. There's no feature to talk about. There are eight fixes, each aimed at a small spot where the from-scratch Rust X11 server behaves differently from Xorg and somehow breaks a real desktop.
That's kind of the whole game here. yserver was never about being new. Maint Jos Dehaes built it to run real desktop environments, window managers, and stubborn legacy apps on modern Linux without the decades of baggage Xorg dragged along. Eight more pixel-perfect fixes fits right in.
The architecture is the usual selling point: yserver drives the kernel's DRM/KMS directly through Vulkan, no EGL, GBM, or Mesa GL indirection of its own, and it runs a single-threaded core loop to dodge the Arc<Mutex<...>> threading headaches Xorg inherited. Dehaes says the goal was never to clone Xorg, just to deliver something practical. Keep in mind that "yserver" itself is a working title, the first idea that popped into his head. It stuck.
What actually shipped
The fixes cluster around two themes: behaving like Xorg, and showing you where the GPU is actually spending its time.
The KDE fix is the most relatable. On Plasma in X11 mode, hover highlights in Dolphin and menus stick to the pointer after you move away, then flicker. KWin collects damage in batches and samples pixels through DamageSubtract and FetchRegion. If a second paint was still waiting on the GPU when KWin looked, it kept stale pixels. The fix makes those calls flush pending paint first, exactly like Xorg. Verified on real hardware, an RX 6800 running upstream Plasma X11.
The GPU-stall fix is the one with the numbers that make you sit up. On a slow Intel HD 500, clicking in a GTK file chooser could hang the whole GPU and end your session. The cause was staggering in its simplicity: each antialiased trapezoid was rasterized as if it covered the bounding box of the entire request, not just itself. The chooser sends roughly 7,900 trapezoids per repaint. Multiply that by a huge bounding box on weak silicon and you blow past the kernel's hang timeout.
Now each trapezoid covers only its own extent. The stress test is byte-identical to a per-pixel CPU reference. On RADV it dropped from 396ms to 5ms. On lavapipe it went from a hard timeout to 20ms. On an Intel HD 620 the chooser reportedly went from painful to near-instant.
There's a Present optimization too. A Present now signals completion on the paint submit that carries the copy, instead of firing a second, signal-only submit. On an HD 620 session that removed about 47,000 of roughly 148,000 submits. present_signal fell from 46,860 to 4. That's not a rounding error.
The release also adds per-second vk submit cost telemetry, toggled with YSERVER_LOOP_TELEMETRY=1. It breaks down real vkQueueSubmit2 calls by cause, CPU time, command buffers per submit, and live GPU allocations. On top of that, the smaller fixes are still real: XI2 Enter/Leave no longer fires an extra one per physical mouse, XSendEvent clicks now reach windows that also listen for XI2, moving or raising a window exposes what it uncovers, uncovered root areas keep their grey instead of going white, and RENDER text stops losing glyphs after a long session. Eight changes. None would show up in a keynote. All of them would show up if you hit them.
Anyone scanning yserver's recent commits will notice something, though. Many are co-authored by an AI coding assistant. The commits carry a Co-Authored-By: Claude Opus 5.5 (1M context) tag, and PR descriptions are stamped "Generated with Claude Code."
That's worth pausing on, since it's a live question in open source right now. Is the code actually sound, or did a model write it and hope for the best?
The answer, from what's visible, is that a human still steers. PR #222 shipped an 8,000-primitive stress test checked against a per-pixel CPU oracle. Releases run the full vng regression suite before packages build. The fix descriptions read like real post-mortems; symptom, cause, fix, verification with hard numbers , but the work underneath is rigorous. It's a concrete example of a mature project using AI to speed up the writing and the verification narrative, while a person keeps the keys to correctness.
Not a silver bullet, but it works when the human has the discipline to verify what the model produces.
yserver's 2026 cadence has been rapid and, increasingly, about maturity. Version 1.5.x hardened DRI3 video and reverse-PRIME. 1.6.0 made TCP transport optional and fixed picom and awesome startup. 1.7.0, the week before, ran CDE on yserver, capped VRAM growth, made Motif/Xaw/Tk apps start as fast as on Xorg, and tied releases to the vng regression suite. 1.7.1 is the polish on top, the release that smooths over the exact spots where a real desktop still stumbles.
The project gauges its own completeness against the X.Org X Test Suite, which takes roughly 50 minutes and, per the docs, is best run unattended because it drives the mouse on some tests. Don't touch the keyboard during those. As of now the repo sits at nearly 600 stars and over 30 forks.
Getting it running
yserver ships for Arch via the AUR, and as loose binary files for Fedora, Debian, Ubuntu, and Alpine, in both x86_64 and aarch64 builds.
Fedora:
sudo dnf install ./yserver-*.rpm
Debian/Ubuntu:
sudo apt install ./yserver_*.deb
Alpine installs with sudo apk add --allow-untrusted ./yserver-*.apk, signed with a per-build key.
From source it's basically just install-local, then add yourself to the video and input groups and log back out. Because yserver drives atomic KMS with no seat manager, it needs access to /dev/dri/* and /dev/input/event* plus a working Vulkan driver. Then, from a free console, run starty. Full setup details live in docs/setup.md.
You can grab 1.7.1, read the full changelog, and file bugs over on the GitHub releases page. Head here for the repo, and the linked 1.7.0 release if you want to see what set this one up.
