Components
Plug your display, tracker or 2D-to-3D model into DisplayXR. The runtime is one trunk that nobody forks. Everything hardware- or model-specific is a component it discovers at startup, so you ship a library from your own repo and every DisplayXR app runs on it, unchanged.
Each component class has its own entry point, its own ABI version and its own discovery root, and the runtime ships a reference implementation for each, so the whole system runs on a laptop with no hardware. The runtime owns selection and policy; a component owns one capability. The model is accepted in ADR-054.
Building a spatial display? Start here
- Clone the vendor template. It builds green with no vendor SDK, so the first thing you see is a working pixel path.
- Replace one function, the weave. Two of about nineteen vtable slots are mandatory (
process_atlasanddestroy); the rest are optional and NULL-safe. - Ship the library and an installer from your own repo, on your own cadence. Check it with
displayxr-cli selftest.
Expect about a week of DisplayXR plumbing. Your weaver and calibration stay inside your binary and never cross the ABI. Onboarding guide →
Display processors
ShippedMakes your panel show 3D: weaving, calibration and the panel's own eye tracker.
xrtPluginNegotiate · ABI 5 · ADR-019
A display processor is the one component that knows your panel. It turns the rendered views into whatever the optics need, carries the calibration and, where the panel tracks the viewer, owns that tracker. The compositor calls it every frame and never weaves itself; the runtime carries zero vendor identifiers, and its build checks that.
Discovery: on Windows your installer registers the library under HKLM\Software\DisplayXR\DisplayProcessors; on macOS and Linux a JSON manifest points at it. The first one whose hardware is present wins, and sim_display always loses to real hardware. Discovery spec →
- sim_displayreferenceNo hardware: renders to an ordinary window on Windows, macOS, Linux and Android.
- Leia SR display processorvendorThe first vendor display processor. Windows, Linux and Android.
- Vendor templatetemplateBuildable, ABI-correct starter with no vendor SDK.
Input providers
ShippedBrings hands, controllers and navigation devices into the standard OpenXR action system.
xrtInputPluginNegotiate · ABI 1 · ADR-034
An input provider surfaces tracked hands, controllers or a navigation device from any tracking source. Apps read them through xrSyncActions with no idea where the poses came from, and a display maker is never obliged to implement input. Discovery, probe order and ABI gating mirror display processors.
There is no input-provider template yet: start from the display-processor template's build scaffolding and the discovery spec. displayxr-cli input list shows what loaded.
- sim_inputreferenceDeterministic, no hardware.
- net_inputdiagnosticLoopback TCP with a documented wire protocol: drive the action system from any language.
- Ultraleap hand trackingbuild-verified: Not yet hardware-testedvendorThe first third-party input provider. Builds where the Ultraleap SDK is installed.
Conversion providers
ShippedTurns 2D into 3D: depth, disparity, extra views or Gaussian splats, by task.
xrtConversionPluginNegotiate · ABI 1 · ADR-053
A conversion provider turns 2D into 3D: depth from an image or a video, disparity from a stereo pair, extra views from one image, Gaussian splats from a photo. It declares what it can do per task; the runtime picks one provider per task, hosts it and shares it across every app. Apps reach it through XR_DXR_lift and never ship a model.
Two providers ship today beyond the reference: the display vendor's own module, and an open-model provider that gives every box a converter. Providers run in a supervised conversion host process, so a crashing model cannot take the runtime with it, and the runtime's model store fetches and verifies model packs by checksum. Starting one? Fork the conversion template.
This opens DisplayXR to model makers who are not display makers: a depth or view-synthesis model reaches every panel without a display partner. displayxr-cli conv list shows the providers and which one serves each task. Discovery spec →
- DisplayXR-SimConversionreferenceCPU-only and deterministic; exercises every task and readiness state.
- Leia conversion providervendorThe display vendor's own 2D-to-3D module, as a separate DLL that the runtime hosts out of process. Windows.
- Open-model providerbuild-verified: First release; the installer is unsignedreferenceDepth models on ONNX Runtime (DirectML on Windows, CPU elsewhere), so every box has a converter without a vendor module. Models come from the runtime's model store.
- Conversion templatetemplateVendor-neutral starter kit: a CPU-only provider skeleton, a fake host and dev registration scripts.
Viewer-tracking providers
DesignedLook-around from a webcam or any tracker, for displays without their own eye tracker. The class is accepted in ADR-054; its contract and code are not on main yet. When a display tracks the viewer itself, its own tracker wins.
Licensing
The runtime and the plug-in contract headers are BSL-1.0; the XR_DXR_* extension headers and the vendor template are Apache-2.0. There is no copyleft anywhere, so a closed-source component owes an attribution notice and nothing else.
Bring your hardware or model to DisplayXR
We'll help you scope a component and get it onto the platform. A second independent display vendor is also the milestone that moves the project toward shared, multi-vendor governance, so get in touch early.