yserver: an X11 server written in Rust that drops the legacy baggage

What yserver drops before it starts

The project states its intent in the first paragraph of the README: the goal is not to clone Xorg. The aim is a practical X11 server that runs real desktop environments, window managers and applications on modern Linux while dropping legacy baggage.

The list of what goes is specific, and it is the most informative thing in the project. Non-TrueColor visuals are out, so the server does not carry the old visual formats that nothing renders today. Indirect GLX is out, which removes the indirect rendering path that has been deprecated for years. The DDX driver ABI is out, so there is no module for out of tree driver hacks. Endian-swapped clients are out as well.

Two more constraints shape the server. It is Unix socket only, which is why there is xauth support but no xhost ACL support, since there is no network listener to authorise. And XDMCP session negotiation with a display manager, together with a TCP listener, are optional Cargo build features that are off by default.

That is a coherent position rather than a list of omissions. Each removed item is a compatibility burden that modern clients do not need, and removing them is what lets a small Rust codebase implement the protocol in the way a Rust programmer would want to.

Four crates: protocol, core, render, and the server binary

The workspace definition shows the shape of the implementation, and it is a deliberate four way split.

[workspace]
resolver = "3"
members = [
  "crates/yserver",
  "crates/yserver-core",
  "crates/yserver-protocol",
  "crates/yserver-render",
]

The workspace metadata carries the version and the licence in one place.

[workspace.package]
version = "1.7.1"
edition = "2024"
repository = "https://github.com/joske/yserver"
license = "MIT"

Reading the names, yserver-protocol is the wire protocol layer, yserver-core holds the server logic, yserver-render is the rendering side, and yserver is the executable that ties them together. The dependency list in the workspace makes the separation explicit, because the core and the render crate are declared as path dependencies with default features disabled.

yserver-core = { path = "crates/yserver-core", default-features = false }
yserver-protocol = { path = "crates/yserver-protocol", default-features = false }
yserver-render = { path = "crates/yserver-render", default-features = false }

The crates directory also sits next to an examples directory, a tools directory, a docs directory, a Justfile for task running, clippy.toml, rustfmt.toml and a rust-toolchain.toml, and the repository carries both AGENTS.md and CLAUDE.md, which tells you that automated coding assistants are part of the workflow here. A single maintainer with a structured repository is a different maintenance model from the multi person Xorg project it resembles.

The dependency set: DRM, GBM, Vulkan and libinput

The libraries the server binds to describe the architecture more clearly than any diagram would.

drm = "0.15"
gbm = { version = "0.18", default-features = false }
input = "0.10"
xkbcommon = "0.9"

The drm crate is the kernel interface for modesetting, the gbm crate is the buffer manager for graphics memory, input handles devices through libinput, and xkbcommon handles keyboard layout. Together they say the server is a DRM and KMS implementation from the ground up, not a compatibility shim over an existing X server. ash appears in the list as the Vulkan binding, and the README notes the server runs on Vulkan 1.2 GPUs such as Intel Haswell and Ivy Bridge, with older drivers producing a clear error naming what is missing.

The pin on libc is a small but telling detail.

# 0.2.190 removed FreeBSD's NOTE_PCTRLMASK, still required by nix 0.31.3.
libc = "=0.2.189"

An exact version pin with a comment explaining the reason is what careful dependency work looks like. The README also records that the seat model was changed to direct only, and the libseat dependency dropped, which is the same philosophy applied to the display server side: keep the surface small.

The lints section of the workspace file makes one more design choice public, since the project allows the clippy warning about argument count and explains that X11 request handlers naturally take one parameter per wire field, so wrapping them in structs would add churn without aiding readability.

How far the protocol implementation actually reaches

The recent work list is the best available evidence of coverage, and it is long. The Common Desktop Environment runs, with dtsession, dtwm and its panel, dtterm, dtfile, dtpad and the Motif and Xaw applications around them. Old style toolkits draw as they do on Xorg, with lines, text, clipping, exposures and GetImage of windows with children. Fonts are indexed and cached, and compressed bitmap fonts work as expected.

The graphics side is deeper than a minimal server would be. Fractional scaling runs through RANDR transforms at 125 percent and 150 percent, along with screen rotation and reflection, virtual monitors through xrandr --setmonitor, and xrandr --dpi now works. DRI3 1.4 sync objects are served through DRM with GPU fences published to the client's release points, GLX pbuffers are backed by a real GPU pixmap so Chrome and Steam get hardware acceleration, and with TFP implemented the server supports compiz.

Input handling covers one XInput device per physical device, as on Xorg, with per device pointer acceleration profiles taken from desktop settings, and the README records that the RECORD extension is implemented for global input listeners such as pynput.

The status section is candid about the state of play. The server is described as standalone DRM and KMS, able to run full desktop environments, and the claim about games is that you can run Steam games on yserver and have it perform almost on par with Xorg, with an invitation to try it and report. Almost is the operative word, and the project's own wording is the fairest summary of where it stands.

Testing against Xorg in a virtual machine

One line in the recent work list describes the test strategy, and it is unusual. The project has a regression suite that runs the real server in a virtual machine and compares it with Xorg, in CI.

This matters because X11 has no conformance suite that a server can simply pass, and because the failure modes are visual. A server can be protocol correct and still render a window with a clipped border, or repaint the wrong region, or leave a ghost window on the next workspace. The README lists several such defects as fixed, including the XFCE dialogs losing their button bar when scrolled under the compositor, MATE tray icons losing their pixels when moved, the Cinnamon lock screen failing to appear, and window backgrounds flashing in odd colours with sloppy focus.

Running the comparison in a virtual machine is what makes it repeatable in CI, and a virtual machine is also where you can put two servers side by side and diff the result. The cost is real, since a comparison suite needs a defined corpus of applications and a way to judge equivalence, and the README does not describe the corpus.

For an adopter, this is a reason to expect fewer surprises, and also a reason to expect the project to keep improving. The alternative for a new X server is manual testing against a long tail of applications, which is exactly the workload that stopped other reimplementations from finishing.

Packaging, optional features and the starty launcher

Running the server is not only a matter of building it from source. The project ships binary packages for aarch64 as well as x86_64, with binary releases for Fedora, Debian, Ubuntu and Alpine, and FreeBSD is supported. The musl build on Alpine works, and the README records a fix for the stable toolchain build on Ubuntu 26.04.

There are example configuration files in the examples directory, including a LightDM configuration template named lightdm-99-yserver.conf.in and a systemd tmpfiles file named yserver.tmpfiles, which indicate integration with a display manager and with systemd, and the setup documentation is in docs/setup.md.

A separate launcher called starty is included, described as startx style, with display number picking, MIT-MAGIC-COOKIE-1 handling and session teardown. That last detail is what a session manager needs, and it is the kind of small piece of glue that usually gets left to a distribution package.

The optional features deserve attention because they are off by default. XDMCP negotiation and the TCP listener are Cargo features that a distributor or a user has to turn on deliberately. For a local session that is the right default. For a terminal server or a remote desktop workflow, the feature has to be enabled at build time, which is a different deployment conversation.

Where yserver is the wrong tool

The gaps are concrete, and they are the reasons this stays a project to try rather than a project to install on a work machine.

The hardware floor is the first. The server is built on DRM and KMS with Vulkan 1.2 for the graphics path, and a machine with an older driver gets an error rather than a fallback. There is no indirect rendering path to fall back to, because indirect GLX was deliberately removed.

The second gap is the network. The server is Unix socket only, so no X client on another machine can connect, and remote use means a network proxy in front of it rather than a server option.

The third gap is scope. A full X11 implementation has a very large surface, and the README's own list of what runs is a list of things that were made to work rather than a claim of completeness. Extensions are the practical dividing line, and docs/extensions.txt is where that list lives. The project also names the visual features it will not support, and applications that rely on those are out of reach by design.

There is a fourth, softer limit. This is one maintainer's project, and the work is delivered in a steady stream of individual fixes. A workstation that cannot lose its display server is a different risk profile from a laptop that can be rebooted.

Licence, release rhythm and the direction of travel

The licence is MIT, declared in the workspace package metadata and carried by a LICENSE file at the root of the repository, so the code can be reused and modified in commercial products without a per seat fee, provided the notice travels with it. That is a permissive grant and it carries no support obligation, which is consistent with a project maintained by an individual.

The release rhythm is fast. Version 1.6.0 was published on 2026-09-22, 1.7.0 on 2026-10-06 and 1.7.1 on 2026-10-09, and the last push to the default branch was on 2026-10-20. The repository is not archived, so the work is current, and the project describes the server as being able to run full desktop environments today.

The direction of travel is the interesting part for anyone planning a longer term. The server implements a large part of the X11 protocol directly, it targets modern graphics stacks rather than the legacy ones, and the design document lives at docs/high-level-design.md with the extension list at docs/extensions.txt. The name is not settled, since the README explains that yserver is a working name and that multiple projects on GitHub share it, none of them X11 servers.

For an adopter, the practical reading is that this is a fast moving implementation with a permissive licence and an unusually open engineering style, and that the two documents worth reading before anything else are the design document and the extension list.

Editorial conclusion

yserver is worth adopting for anyone who wants an X11 server built for a contemporary Linux machine, and it is a reasonable base for a Wayland transition because the X11 protocol surface is implemented directly rather than emulated. It is not a drop in replacement for Xorg on a general purpose workstation, since it requires a DRM and KMS stack with a Vulkan 1.2 capable GPU, it is Unix socket only with no XDMCP or TCP client support enabled by default, and the project itself describes game performance as almost on par with Xorg. Before trying it, read docs/high-level-design.md and docs/extensions.txt for the scope, and check docs/setup.md for the optional build features that are off by default.

Frequently asked questions

Official sources

1. Issues
2. joske/yserver on GitHub
3. License: MIT
4. README
5. Releases