OpenXR for Spatial Displays
DisplayXR is an open runtime and extension stack for 3D displays, including tracked stereo and multiview lightfield displays. Build portable spatial display applications across engines, graphics APIs, and vendor hardware runtimes.
The Problem
Spatial displays deserve a common interface
OpenXR standardized how applications talk to headsets and controllers. But a growing category of spatial displays — tracked spatial display monitors, laptops, and related systems — has no equivalent.
Today, every vendor ships its own SDK with its own compositor, its own rendering path, and its own way of handling eye tracking and display geometry. Developers who want to target multiple displays must write and maintain separate integrations for each.
The result is fragmentation: duplicated effort, inconsistent behavior, and a higher barrier for both developers and vendors entering the space.
What DisplayXR Provides
A practical stack for tracked spatial displays
Runtime
A full OpenXR runtime with native compositors for every major graphics API — no interop layers required.
Extension Specs
Custom OpenXR extensions for display info, window bindings, and spatial display capabilities not covered by standard OpenXR.
Native Compositors
Per-graphics-API compositors (D3D11, D3D12, Vulkan, Metal, OpenGL) that avoid cross-API translation overhead.
Engine Integrations
Unity plugin shipping with UPM support. Unreal plugin in beta (UE 5.3+). Standard engine workflows, no custom forks.
Vendor Display Processor
A clean boundary where vendor-specific processing (weaving, interlacing, calibration) plugs in without touching app code.
Workspace Extensions
XR_EXT_spatial_workspace + XR_EXT_app_launcher — a documented surface for swappable workspace controllers that compose multi-app 3D layouts, drive window placement, and register launcher tiles. The DisplayXR Shell is the reference; OEMs, vertical integrators, kiosks, and AI-agent drivers can ship their own.
Who is this for?
Three audiences, one stack
DisplayXR is layered so app developers, contributors, and display vendors can each pick up exactly the part they need without forking the rest.
The Ecosystem
More than a runtime
DisplayXR is developing as a full ecosystem — runtime, extensions, engine plugins, projection math, demos, and reference workspace controllers.
Core
Engine Plugins
displayxr-unity
ActiveUnity engine plugin (UPM package) with eye-tracked stereo rendering, sample scenes, and standalone editor preview.
displayxr-unreal
BetaUnreal Engine plugin (UE 5.3+) with eye-tracked Kooima stereo, camera- and display-centric rigs, Blueprint components, material expression nodes, and zero-copy atlas handoff. Windows, macOS, Android.
Libraries
kooima-projection
Off-axis frustum projection math library for spatial display rendering.
displayxr-mcp
ActiveTiny 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.
Demo Applications
Why Now
Spatial computing is not headset-only
Spatial computing is still largely framed around headsets. But spatial displays are becoming a real category — tracked spatial display monitors, laptops, and related display systems are shipping from multiple vendors.
These devices need a common interface layer. Without one, the ecosystem fragments before it has a chance to grow. DisplayXR brings that missing layer, so developers and hardware vendors can build against a shared interface rather than isolated SDKs.
Start building for spatial displays
DisplayXR works in simulation mode — no hardware required. Read the docs, explore the demos, or dive into the source.