Beyond X11 and Wayland: Building a Protocol-Neutral Visual Kernel
A display server should not be an ideological hostage to a single graphics protocol.
For decades, we have defined our graphical environments by their application-facing wire protocols. If you run X11, your display server is a massive, monolithic interpreter that manages drivers, composition, inputs, and client state in a single, un-sandboxed address space. If you run Wayland, your compositor is a different kind of monolith, forcing layout calculation, presentation timing, display driving, and status rendering into one fragile execution loop.
In both paradigms, the graphics engine is tightly coupled to the application protocol. If you want to support a new protocol, you must rebuild the display server or write massive, intrusive translation layers.
Sophia is built on a different premise: the graphics engine should be a protocol-neutral visual kernel.
The Evolution: From Architectural Inspiration to the Sophia Engine
In the early design phases of Sophia, we drew deep inspiration from XLibre. XLibre is an actively developed, custom-patched C-based fork of the Xorg server that prototypes X11 resource virtualization and routed pointer inputs. Studying its layout and routing design provided us with invaluable architectural lessons on how X11 namespaces could be isolated.
But studying XLibre also taught us a hard lesson. Carrying or patching a massive legacy C codebase would introduce severe security and maintenance liabilities, running directly counter to our goal of a modern, memory-safe display stack built cleanly from scratch.
On July 8, 2026, we made an architectural cutover. We reframed the entire display stack around the Sophia Engine (sophia-engine) as the permanent visual and input authority.
Instead of building a display server around X11 or Wayland concepts, we built a graphics kernel that understands only one thing: abstract, anonymous visual transactions.
The Engine has no knowledge of X11 window hierarchies, atoms, selections, or grab states, nor does it speak Wayland. It exposes a protocol-neutral SurfaceContentStream that accepts anonymous buffers, damage regions, and spatial transformations. It performs page-flips via the DRM/KMS atomic API and manages input routing at the hardware level, leaving application protocol parsing to an independent layer.
The Pluggable Protocol Layer
By stripping protocol complexity out of the graphics kernel, we established a clean, pluggable Protocol Authority Layer. Sophia’s default translator is the Sophia X Server Frontend (sophia-x-authority), a clean-room X11 subset parser written entirely in Rust. It intercepts classic X11 sockets, handles resource management, and translates client requests into anonymous Engine transactions.
But because the Engine’s transaction boundaries are protocol-neutral, this frontend is entirely replaceable:
- Multi-Protocol Coexistence: A developer could write a native Wayland frontend and run it side-by-side with our X11 frontend on the same display. The Engine would composite both X11 and Wayland surfaces onto the same screen, completely oblivious to which application spoke which protocol.
- The XLibre Fallback: If legacy applications ever require complex, legacy X11 extensions that our secure Rust frontend does not yet support, the architecture allows us to restore XLibre as an optional, heavyweight legacy provider. It would run in its own sandboxed process, managing X11 semantics while feeding visual buffers to the un-compromised Engine.
- Future-Proofing: If a new, highly optimized display protocol is designed tomorrow, implementing it on Sophia requires writing a lightweight translator—not rebuilding a compositor from scratch.
This separation of concerns preserves the best aspects of the Unix philosophy: the visual kernel does one thing—guarantees visual atomicity and hardware integrity—while pluggable frontends handle the messy, evolving world of application protocols.
We invite you to explore the sophia-x-authority codebase and help us refine this pluggable architecture.