YServer 1.6.0 brings networked, multi-user login to the from-scratch Rust X11 server
New TCP transport, session reset, and XDMCP support let YServer act as a drop-in Xorg replacement in shared networked desktops, though both new capabilities ship off by default.
YServer 1.6.0 is out, and it's the release that finally gives the from-scratch Rust X11 server the tools to quietly replace Xorg in places where many users share one desktop over the network. Version 1.6.0 shipped September 22, 2026. It adds TCP transport, server-side session reset, and XDMCP negotiation. Those are exactly the hooks a LightDM-style display manager reaches for to drive a networked shared display.
YServer was never trying to be Xorg. Maintained by Jos Dehaes under the MIT license, it's a deliberate modern re-imagining of the X server. The point is to run real desktops on modern Linux while dropping legacy baggage like non-TrueColor visuals, indirect GLX, the old DDX driver ABI, and endian-swapped clients.
The 1.6.0 work actually got started over a feature request. A user named sinirajapan asked for multi-user HPC shared desktops, noting that distributions such as RHEL10 are phasing out Xorg entirely while XDMCP still runs the show on shared visualization nodes. Fair point, though the XDMCP protocol itself is old enough that most people under 40 have never had to configure one by hand.
A network-ready server, default off
TCP transport is first. YServer can now bind an X port right beside its Unix socket, so a client arriving over the network is treated like a local one. It's off by default, switched on with -listen tcp. Worth a second look: when the feature isn't compiled in, the capability is simply absent rather than merely disabled, which is a bolder stance than most servers take.
Server reset is more about housekeeping. A display can now end one session and start the next without the whole process exiting, which is the X11 "generation" boundary. Every client gets torn down, resources get released, a fresh authorization cookie gets issued, and a new generation gets installed. If a composite overlay somehow outlived its session, the server refuses to install another generation on top and shuts down cleanly, much like -terminate. LightDM requires exactly this behavior, which is the entire point.
The third piece is XDMCP negotiation. YServer now runs the full Query/Willing/Request/Accept/Manage exchange with a remote display manager. A LightDM on one host can drive a YServer display on another, the way a thin client logs in through Xorg. The maintainer validated this cross-machine on real hardware and confirmed that each Generation(1) to Generation(2) transition issues a fresh 16-byte cookie.
It isn't a complete port, and the project says so without hedging. IPv6 is out. -listen tcp binds only 0.0.0.0, and address resolution skips non-v4 hosts. Host access control via xhost or an ACL is deliberately unimplemented, which means anyone who can reach the port and present a valid cookie walks right in. GLX over TCP was parked for later.
The design docs spell out the threat model plainly. TCP fails closed until a valid cookie shows up, or in XDMCP mode a generation-bound session cookie from an Accept packet. Keep in mind that the default build ships with neither feature, so out of the box YServer remains a Unix-socket-only server. That's deliberate, and honestly a smart default for something this reachable.
Build-time opt-in and the rendering cleanup
You can make TCP and XDMCP optional at build time instead. PR #149 turns both into Cargo features — tcp-transport and xdmcp, the latter implying the former — both off by default. The idea is that minimal or security-constrained builds can prove a capability is absent just by reading the source, and avoid shipping roughly 5,300 lines of unused XDMCP codec. A build missing a feature doesn't silently ignore the switch. The parser stays on, and the server exits at startup with a message naming the missing feature, before it ever touches hardware or binds a socket. --version now ends with a machine-readable suffix like features=[tcp-transport,xdmcp] or just features=[]. Distro packages deliberately ship the empty variant.
A large batch of correctness fixes rounds out the release, targeting picom, awesome, i3, KDE Plasma, QtWebEngine, and games. Highlights include a scanout change that stops flooding the log at INFO, plus a scene revocation fix. picom and awesome get startup, rendering, and scanout work. GLX gains a QtWebEngine native-pixmap config and advertises a stencil-free glmark visual. RANDR CRTC model hotplug gets a relight fix. XKB advertises an empty KeyBehaviors section in GetMap. MIT-SHM now honors GC clip in PutImage.
Where the project stands
YServer already runs full desktops on standalone DRM/KMS, with the maintainer claiming near-Xorg game performance. The work leading up to 1.6.0 picked up damage-clipped repaint, which brings compositing GPU load down to about a third, along with direct compositor scanout, DRI3 1.4 syncobjs, Present vsync tweaks, reverse-PRIME, and per-device pointer acceleration. Binary packages exist for x86_64 and aarch64.
It's been tested end-to-end against a wide spread of window managers and desktops: Cinnamon, MATE, XFCE, FVWM3, sonic, wmaker, openbox, awesome, picom, compiz, icewm, blackbox, bspwm, i3, and enlightenment e16 through e27. Hardware runs the gamut too, spanning AMD, Intel, NVIDIA, Snapdragon X1, Apple M1/M2 via Asahi Linux, and virtio-gpu. Regression coverage is measured against the X.Org X Test Suite, which takes roughly 50 minutes to run end to end.
Installation is a short sequence. From a source checkout, run just install-local to build and install, then sudo usermod -aG video,input $USER before logging back in. Switch to a free console and start YServer with starty. There's no seat manager here, since YServer drives atomic KMS directly, so it needs access to /dev/dri/*, /dev/input/event*, and a working Vulkan driver. Full steps live in docs/setup.md.
For those who'd rather not build, packages are scattered. Arch and derivatives have yserver on the AUR. Fedora, Debian, Ubuntu, and Alpine get loose files attached to the GitHub release, installed by path:
sudo dnf install ./yserver-*.rpm sudo apt install ./yserver_*.deb sudo apk add --allow-untrusted ./yserver-*.apk
The v1.6.0 release ships 8 binary packages across x86_64 and aarch64, plus separate Alpine doc packages, all downloadable from the release page. Head here to the tag for the full list.
It's a somewhat narrow set of wins for the everyday desktop user, since XDMCP is mostly an HPC and enterprise concern. But the engineering rigor is unmistakable: unusually detailed design docs, real hardware validation, and an unflinching list of what was intentionally left out. For anyone tired of tracking Xorg's decline, YServer 1.6.0 is worth a look.
