Extensions

Custom OpenXR extensions that enable tracked spatial display capabilities not covered by the base OpenXR specification.

Why custom extensions?

Standard OpenXR was designed for headsets and controllers. Tracked spatial displays have different requirements: they need to communicate display geometry, support window-hosted compositing, and provide spatial display models that don't map to existing OpenXR concepts.

DisplayXR defines focused extensions to fill these gaps while remaining compatible with the OpenXR architecture and extension model. The goal is practical interoperability, not a competing specification.

Tracked off-axis projection: an asymmetric frustum from the tracked eye position to the corners of the fixed display plane, recomputed every frame as the eye moves, so rendered content reads as depth behind the glass.

Display capability

What the runtime tells apps about the 3D display they're rendering on.

XR_EXT_display_infoShipping

Display Info

Provides applications with spatial display geometry, resolution, eye-tracking modes, and the data needed for correct off-axis (Kooima) projection and view configuration. Each rendering mode declares whether it consumes live eye tracking, and apps receive an edge-triggered event on tracking loss and recovery. Spec v16 adds a desktop-position query so a window-owning app can learn where the 3D panel sits in the virtual desktop and open its window there.

Rendering & projection

How an app drives the runtime's view math and tells it which parts of the window are 3D versus flat 2D — instead of re-implementing the projection or 2D/3D compositing itself.

XR_EXT_view_rigEarly

View Rig

Lets an app drive the runtime's view-rig math instead of re-implementing the off-axis (Kooima) projection from raw eye positions. The app chains a small rig descriptor — virtual display height and ipd/parallax/perspective factors for a display rig, or convergence and vertical FOV for a camera rig — onto xrLocateViews and consumes standard, render-ready XrView{pose, fov}, exactly as on any other OpenXR runtime. A raw-result channel still exposes the untransformed eye and display-plane inputs for aware consumers that keep doing their own math.

XR_EXT_local_3d_zoneBeta

Local 3D Zones

Lets an app declare which regions of its window are 3D versus flat 2D via a per-pixel 3D-ness mask, authored as the whole window, a list of rects, or a freeform render target. The runtime composites a flat 2D layer over the weaved 3D output gated by the mask, and a hardware display processor can drive a switchable-lens panel so only the 3D regions weave. Spec v3 adds the 2D side as a first-class post-weave composition layer submitted through the normal frame loop.

XR_EXT_display_zonesBeta

Display Zones

Declares a layout of independent 3D zones and flat 2D zones across a single display, each 3D zone carrying its own view rig, plus a wish mask the vendor display processor honors when driving a switchable-lens panel. Powers mixed 2D/3D compositions — a weaved 3D object beside a flat 2D HUD, for example — and underpins the out-of-process display compositing used on Android.

XR_EXT_weaveExperimental

Window Weave Service

A window-bound, synchronous weave service for present-owners — callers that own their OS window and present it themselves, but want the runtime's vendor display processor to weave a sub-rect of that window for them. The caller hands the runtime a pre-weave stereo (side-by-side) texture and a window-relative rect and gets back a weaved shared texture plus a fence to composite and present. The caller never weaves; it is the runtime half of the inline-3D-in-a-browser path.

App window binding

How an app hands its native window to the runtime so the compositor can output into it.

XR_EXT_win32_window_bindingShipping

Win32 Window Binding

Allows applications to bind an existing Win32 HWND to the DisplayXR session. The runtime composites into the application's own window rather than creating a separate one.

XR_EXT_cocoa_window_bindingShipping

Cocoa Window Binding

macOS equivalent of the Win32 window binding. Binds an NSView to the session for compositor output into the application's window.

XR_EXT_xlib_window_bindingBeta

Xlib Window Binding

Desktop-Linux equivalent of the Win32 and Cocoa window bindings. An app hands the runtime its own X11 window (Display* + Window) so the native Vulkan/XCB compositor renders into the app's window instead of creating its own — enabling windowed (non-fullscreen) rendering and app-owned keyboard and mouse input.

XR_EXT_macos_gl_bindingShipping

macOS GL Binding

macOS-specific OpenGL context binding for the Cocoa window-binding path. Lets GL apps share a CAOpenGLLayer-backed surface with the runtime compositor.

XR_EXT_android_surface_bindingShipping

Android Surface Binding

Android equivalent of the Win32 and Cocoa window bindings. Binds an Android Surface (SurfaceView) to the session so the runtime composites into the app's surface, and carries the surface lifecycle the out-of-process Android compositor follows across rotation, background, and resume.

Workspace controller surface

How a swappable workspace controller (the DisplayXR Shell, or any third-party / OEM / vertical equivalent) drives multi-app composition and the launcher on top of the runtime.

XR_EXT_spatial_workspaceShipping

Spatial Workspace

Defines how a privileged workspace controller process drives multi-app composition, window pose, hit-test, and capture on the runtime. The contract that lets the DisplayXR Shell — or any OEM, vertical, kiosk, or AI-agent controller — replace the spatial-desktop layer without runtime modifications.

XR_EXT_app_launcherShipping

App Launcher

Companion to spatial_workspace: lets a workspace controller register launcher tiles, query installed apps, and drive launch/lifecycle events. Decouples the launcher UX from the runtime.

XR_EXT_workspace_file_dialogBeta

Workspace File Dialog

An async, spatial-native file picker. An app calls for a picker and receives the result through the event queue; the picker is a peer workspace window spawned by the active controller, not a layer inside the app's own window. Workspace-scoped, with graceful fallback to the platform file dialog when no controller advertises support.

Agent control

How applications plug into the AI-agent surface — exposing their own actions to agents and voice drivers through the same MCP framework the runtime and workspace controllers use.

XR_EXT_mcp_toolsEarly

App MCP Tools

Lets an application register its own Model Context Protocol tools with the runtime's agent surface. AI agents and voice drivers can then invoke app-defined actions — tool calls arrive through the OpenXR event queue, the app answers inline, and tools are namespaced by the app's manifest id.

Capture

Getting the composed 3D frame back out of the runtime — for screenshots, recording, and dataset generation.

XR_EXT_atlas_captureEarly

Atlas Capture

A vendor-neutral, non-privileged way to snapshot the multi-view atlas the runtime composes for a session to a PNG, at a caller-selected compositor stage. The runtime does the readback from its own atlas image, so apps drop the per-graphics-API staging-texture readbacks they each reimplement today. Any app — handle, texture, hosted, or IPC — can call it.

Extension philosophy

●Minimal scope — each extension does one thing well. No monolithic specs.
●OpenXR-compatible — follows the standard extension registration and dispatch model.
●Vendor-independent — designed for any tracked spatial display, not tied to a specific hardware vendor.
●Explicitly versioned — specs evolve through clear versioning so apps and runtimes can negotiate capabilities.

All extension specifications and headers are in the displayxr-extensions repository.

Where to next

Build an app

Install the runtime and opt into these extensions from your own OpenXR app — no special hardware required.

Implement an extension

Add or extend an OpenXR extension in the runtime — the contributor guide walks through the wiring end to end.

Integrate a display

Vendors: ship a display-processor plug-in that consumes XR_EXT_display_info and the window bindings.