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.

Engine plugins

Libraries & tools

displayxr-conversion-open

The open-model conversion provider: depth from images and video on ONNX Runtime (DirectML on Windows, CPU elsewhere), with a default pack of permissively licensed models fetched by the runtime's model store. Plugs into the runtime's 2D-to-3D conversion service, so every box has a converter without a vendor module.

displayxr-conversion-template

Vendor-neutral starter kit for a 2D-to-3D conversion provider: a CPU-only provider skeleton, a fake host, dev-box registration scripts and CI on Windows, Linux and macOS. Fork it to bring your own model to every DisplayXR app.

displayxr-common

Shared math and common library — off-axis (Kooima) projection, atlas tiling, and window/canvas helpers — including one Linux app window that picks native Wayland or X11 by capability probe, with shared client-side window chrome — 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. It is pinned to the first revision of the weave spec, far behind the runtime's current one, 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.

displayxr-web

The inline-3D JavaScript SDK, published on npm as @displayxr/inline3d — 3D photos, video, models, Gaussian splats, a 3D media player and 3D video calls in a few lines — plus its live samples on GitHub Pages, which double as the DisplayXR Browser's start page. Every page renders as ordinary 2D in other browsers.

displayxr-models

Content-addressed ONNX depth and inpainting models behind the DisplayXR Browser's Convert to 3D — permissively licensed only, published as permanent release blobs.

Demo apps

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 display processor or another component instead? See Components.)

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.