Contribute

DisplayXR is open source and vendor-neutral. Whether you want to add a feature, an extension, or a new platform, here's how the project is laid out and where to start.

You do not need a spatial display to work on one. The runtime ships sim_display, a simulated tracked panel in an ordinary 2D window with the viewer's eye position on your mouse and keyboard — side-by-side, anaglyph or blended. It is the same driver the official Khronos conformance suite runs against in CI, so the path you develop on is the path that gets tested.

Understand the design first

Where the code lives

DisplayXR is a multi-repo project under the DisplayXR org. External contributors PR directly against the relevant repo.

Libraries & tools

displayxr-common

Shared math and common library — off-axis (Kooima) projection, atlas tiling, and window/canvas helpers consumed by the runtime, engine plugins, and demos from a single source of truth.

displayxr-mcp

Tiny embeddable Model Context Protocol server framework, plus the DisplayXR MCP Tools installer that end users download to opt in to AI-agent / voice control. The framework lets the runtime, the reference shell, and any third-party workspace controller expose live spatial state and control to AI agents (Claude Code, voice CLIs, custom drivers); the installer writes a registry capability flag the runtime and shell read at startup.

displayxr-vendor-template

Vendor-neutral starter kit for building a DisplayXR display-processor plug-in — the ABI, discovery, and build scaffolding a new 3D-display maker needs, with no vendor SDK required. Fork it to bring up a plug-in against the sim_display path, then swap in your own weaver.

displayxr-cef-host

The original proof that XR_DXR_weave works — not a browser to use, which is DisplayXR Browser. A small CEF (Chromium Embedded Framework) offscreen-render app that hands the runtime a stereo texture and a window rect and composites the weaved result; it never weaves itself. Kept as the smallest worked example of driving the weave from your own present-owner without forking Chromium, and because it builds in minutes where the browser fork takes hours. Note that it is pinned to weave spec v1 while the runtime is on v9, so it does not exercise batched submit, the 2D overlay atlas, N-view input, the Android handle kinds, or IPC brokering — treat it as a starting point to read, not a current conformance harness.

Demo apps

Workspace controllers

Key decisions (ADRs)

Architecture Decision Records capture why the runtime is built the way it is. A few you'll want before touching the pipeline — the full set is in docs/adr.

Add a feature, extension, or platform

The deep guides live in the runtime repo; these are the entry points. (Writing a plug-in for a 3D-display panel instead? See the Display Vendors guide.)

Pick up an issue

Runtime dev issues live in the runtime repo; external contributors open a PR directly against it. New here? Filter for good first issue.