Phoenix: A modern X server written from scratch in Zig

Original Article ↗ Hacker News Discussion ↗

Project goals and architecture

  • Phoenix is seen as an attempt at “X12”: an X‑server‑compatible display system reimplemented from scratch, with a Wayland‑like model (combined compositor/server, isolation by default, no GLX remoting, major protocol cruft trimmed).
  • It assumes modern GPU stacks (DRI/GBM, GLX/EGL/Vulkan) and disables its compositor when a fullscreen, vsync‑off client runs to reduce latency.
  • Current implementation is very limited: mainly GL apps; many core X requests (fonts, images, colors) aren’t implemented yet.

Compatibility and legacy X11 usage

  • Several commenters question the point of an “X server” that omits traditional X drawing ops and XRender, since that breaks many classic tools (xterm, emacs, xfig, xmodmap, etc.).
  • Others argue most modern apps use client‑side rendering through toolkits, so a slimmed‑down server is acceptable, with old apps handled via a nested/rootless traditional X server.
  • “Multiple screens” being a non‑goal is clarified as X11’s specific “screen” concept; multi‑monitor and virtual desktops should still be possible later.

Relationship to Xorg, XLibre, Wayland, Wayback

  • Phoenix is contrasted with XLibre (a fork of the Xorg server), which some describe as low‑quality and poorly tested; others still prefer incremental fixes over rewrites.
  • Wayback (X11 on top of Wayland) is mentioned as another pragmatic path once Xorg ages out.
  • Some hope Phoenix could eventually serve as a cleaner XWayland‑like base.

Wayland vs X11: security, tooling, and fragmentation

  • Large parts of the thread devolve into X vs Wayland:
    • Pro‑Wayland: better security defaults (no global input snooping), better handling of tearing, HDR/VRR, per‑display DPI, and a modern architecture; X11 is called an unsalvageable fossil.
    • Pro‑X: global automation (xdotool/xmacro), uniform tools across all WMs, easy remoting, and simple scripting (e.g., focused window title) are cited as essential and either missing or DE‑specific on Wayland.
  • Critics of Wayland highlight fragmentation: minimal core protocol, many incompatible compositor‑specific extensions, volatile libraries (e.g., wlroots), and difficulty writing custom WMs.

Accessibility and productivity

  • Accessibility is a recurring concern: Wayland is described as still weak for screenreaders, eye‑tracking, and some assistive tools; X11’s established APIs are a key reason some “absolutely need X”.
  • Others say accessibility is mostly toolkit‑level (e.g., AT‑SPI) and independent of the display protocol, but acknowledge gaps in current Wayland stacks.

Naming and ecosystem notes

  • The name “Phoenix” is criticized as heavily overloaded (browser history, web framework, other projects), though some dismiss this as unimportant.
  • A few note a pattern of “pragmatic” Zig projects (like Phoenix versus Wayland) that favor interoperability and incrementalism over pure redesign.