0xide

0xide is a from-scratch tiling Wayland compositor, written in Rust on top of wlroots. It’s the userspace sibling of snert, a from-scratch kernel project — same working style, one layer up the stack.

Most people who want a tiling Wayland compositor install one. 0xide exists for a different reason: to understand, concept by concept, what a Wayland compositor actually is — the backend, the Wayland server, the renderer, xdg-shell, input routing, tiling, real display output — by building each one instead of importing it. It’s a learning project first and a daily driver second, though it’s grown into something usable on real hardware. Design decisions are collected in Design & ideas.

The mental model

A Wayland compositor sits between two things it doesn’t own:

        clients (foot, firefox, ...)
                    │
                    ▼
   ┌────────────────────────────────┐
   │             0xide               │   ← this project
   │  policy: tiling, workspaces,    │
   │  keybindings, config            │
   └────────────────────────────────┘
                    │
                    ▼
              wlroots (C library)
        DRM/KMS, GLES2 renderer, libinput,
        scene graph, protocol plumbing
                    │
                    ▼
             the Linux kernel

wlroots is the engine; 0xide is the driver. wlroots does the parts that are the same for every compositor — talking to the kernel’s display and input subsystems, decoding the Wayland wire protocol, drawing GL buffers. 0xide decides policy: which window goes where, what a keypress does, how workspaces and monitors relate. That split is deliberate and shows up again, one level down, inside 0xide itself — see Architecture.

Why phases

Rather than a progress percentage or a loose TODO list, 0xide’s roadmap is a sequence of stages, each ending in a concrete thing you can see or test — “a nested window shows a solid color,” “a terminal appears,” “I can type into it.” That’s not a documentation choice, it’s how the project is actually built: see Why phase gates for the reasoning, and the Build Phases chapters for what each stage was and how it went.

Status

0xide runs nested inside another Wayland session for fast iteration, and as a real DRM/KMS session on a bare TTY. It tiles windows, switches workspaces, reads a config file, survives VT switching, and drives multiple monitors with configurable position and scale. It’s being grown into something to daily-drive, one capability at a time — see the repository README for the current feature list, or jump straight to the build phases for the story of how it got there.