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.

Get Started Read the Docs Explore on GitHub

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?

Four kinds of builder, one stack

DisplayXR is designed so application developers, display vendors, OEMs, and vertical integrators can each pick up exactly the layer they need without forking the rest.

Application developers

Writing an OpenXR app for spatial displays?

Standard OpenXR — your existing app code works unchanged. Native compositors mean no Vulkan-interop layer; D3D11, D3D12, Metal, Vulkan, and OpenGL each get their own. Opt into XR_EXT_display_info for 3D-display geometry, eye-tracking modes, and the data needed for asymmetric (Kooima) projection.

Browse extensions →

3D display vendors

Making a glasses-free 3D display panel?

Implement the display-processor vtable for your weaving / depth-mapping / eye-tracking integration. Five API variants (D3D11, D3D12, Metal, Vulkan, OpenGL) so your weaver runs natively in whatever graphics API the application is using. Vendor-agnostic by design — Leia SR is the first integration, not a privileged path.

Vendor integration guide →

OEMs

Shipping a finished 3D-display product (laptop, monitor, tablet, phone, TV)?

Three reasonable bundles: bare runtime + DP for the lightest install, runtime + reference DisplayXR Shell with a sidecar manifest that brands the tray for your product, or runtime + your own workspace controller for a SKU-tailored experience. Activation is gated by orchestrator-PID match — the runtime trusts whatever binary it was configured to spawn, not a brand string.

Architecture & workspace controllers →

Vertical integrators

Building a focused single-purpose 3D experience (CAD, medical, automotive HMI, kiosk, AI agent)?

Run the bare runtime + your application for a kiosk-class deployment — the runtime gives you OpenXR session management, native compositing, and display calibration. Or write a vertical-specific workspace controller against XR_EXT_spatial_workspace + XR_EXT_app_launcher to compose multiple apps for your domain (medical imaging suite, CAD viewer + reference panels, automotive cockpit). Embed displayxr-mcp to expose the same surface to an AI agent.

Workspace extension surface →

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

displayxr-runtime

Core OpenXR runtime with native compositors for D3D11, D3D12, Vulkan, Metal, and OpenGL.

displayxr-extensions

OpenXR extension specs and headers for tracked spatial display capabilities.

Engine Plugins

displayxr-unity

Active

Unity engine plugin (UPM package) with eye-tracked stereo rendering, sample scenes, and standalone editor preview.

displayxr-unity-test

Active

Ready-to-open Unity 6 test project for the DisplayXR plugin — clone, open, and hit Play.

displayxr-unreal

Beta

Unreal 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

Active

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.

Applications

displayxr-demo-gaussiansplat

Active

Real-time 3D Gaussian Splatting viewer (macOS + Windows). One repo per demo — see the org page for others.

displayxr-shell-releases

Active

Reference spatial workspace controller — built on XR_EXT_spatial_workspace and XR_EXT_app_launcher. 3D window manager with multi-app compositing, 2D window capture, dynamic layouts, and focus-adaptive rendering. One example of a privileged compositor client; build your own for verticals, kiosks, OEM-branded workspaces, or AI-agent drivers.

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.

Read the Docs Explore Demos View on GitHub