Rust X11 server tests a leaner path for Linux desktops

A Rust developer has built yserver, an X11 server that can run full MATE, XFCE, and Cinnamon desktop sessions while cutting parts of the Xorg model that few current Linux users need.

The maintainer frames the project as a practical X11 server for current Linux desktops. The goal sounds narrow, which gives the work its interest. Instead of cloning Xorg, yserver targets the parts of X11 that real desktops and applications still use, then leaves aside old paths such as multiple screens, non-TrueColor visuals, indirect GLX, the DDX driver ABI, endian-swapped clients, and similar baggage.

That choice puts yserver in a strange slot in the Linux graphics conversation. Wayland owns much of the future-facing discussion. Xorg still carries a huge amount of working software. yserver asks a different question: Can developers keep the X11 contract while replacing the server beneath it with code that matches current kernels, Mesa drivers, and Rust conventions?

The adoption signal comes from desktop coverage, hardware coverage, and protocol coverage. The maintainer says yserver can run MATE, XFCE, and Cinnamon as a standalone DRM/KMS server. The project also lists FVWM3, e16, and wmaker among tested window managers. That matters because an X server can pass toy demos and still fail under a panel, compositor, file manager, terminal, toolkit, and settings daemon.

yserver also lists support for extensions that desktop sessions expect: Composite, DAMAGE, DRI3, GLX, Present, RANDR, RENDER, SHAPE, SYNC, XFIXES, XInputExtension, XKEYBOARD, XTEST, and GLX_EXT_texture_from_pixmap, among others. The project points readers to its high-level design document for scope and design details, and to test status for X.Org X Test Suite numbers.

The hardware list gives the project a second credibility marker. The maintainer reports end-to-end tests on AMD RDNA2 and Polaris systems, Intel Kaby Lake graphics, Snapdragon X1 with Adreno graphics, Apple M1 and M2 machines on Asahi Linux, and virtio-gpu inside virtme-ng. That spread covers common Mesa paths and a few newer Linux graphics stacks that expose driver assumptions fast.

Nvidia proprietary drivers remain outside the target. The maintainer says yserver cannot work on Nvidia's proprietary driver and reports trouble bringing up Xorg with nouveau on a GTX 1050 test machine. That limit will matter for desktop users with Nvidia systems, even if the project gains more coverage elsewhere.

The project also shows useful integration work. Users can run yserver from a TTY through just startx, which starts the server and runs ~/.xinitrc or the system xinit fallback. LightDM can launch yserver as its X server through an xserver-command setting, which lets users test a graphical login flow with PAM and keyring handling.

Those details separate yserver from a protocol experiment. A display server has to survive awkward desktop plumbing: input devices, seat management, scanout, login managers, screenshots, compositors, shared memory, fonts, and GL. The maintainer chose libseat for seat management when users have it, and yserver can drive atomic KMS with direct access to /dev/dri/ and /dev/input/.

The Rust angle will attract attention, but the language choice should not drown out the systems question. Xorg carries decades of compatibility and driver history. A smaller Rust server can trade some compatibility for code that a new contributor can reason about. That trade gives yserver room to move, provided the maintainer keeps the scope tight and proves behavior against real desktops.

Skeptics have strong arguments. X11 compatibility contains many traps, and applications lean on odd corners of the protocol. Dropping legacy features helps the codebase, but users only notice the missing piece when their workflow breaks. A server that runs common desktops still needs long exposure to window managers, compositors, toolkits, games, remote setups, accessibility tools, and mixed-DPI displays.

The project also faces the Wayland question. Many Linux desktop developers have spent years moving toolkits, compositors, and apps toward Wayland. Some will see a new X11 server as effort spent on a shrinking surface. Others will see value in a cleaner X11 implementation for systems that need compatibility, lightweight desktops, niche window managers, or a migration bridge.

yserver's strongest case comes from measured scope. The maintainer does not promise a universal Xorg replacement. The repository describes a server that runs real desktops on current Linux hardware and drops features that clash with that target. That clarity makes the project easier to judge: users can test their desktop, check the extension list, review the X test results, and decide whether yserver covers their path.

Developer interest will likely follow visible demos and bug reports. The repository already mentions Compiz support through texture-from-pixmap, with a demo video linked in the README. If users keep adding desktop sessions, GPUs, and failure cases, yserver could become a serious test bed for X11 compatibility without Xorg's full historical weight.

For now, yserver gives the Linux graphics community a concrete artifact to inspect. It runs known desktops, names its limits, and exposes design documents. That combination beats vague nostalgia for X11 and vague pressure to abandon it. Developers can clone the GitHub repository, read the design notes, run the test suite status, and decide whether a lean X11 server still has work to do.