Roadmap

Monado fork focused on spatial displays

Forked from the Monado OpenXR runtime, removed VR and headset-specific code, and refocused the codebase entirely on spatial displays

Native compositors for every major graphics API

Dedicated compositor implementations for D3D11, D3D12, Metal, OpenGL, and Vulkan — no cross-API translation layer required

Custom OpenXR extensions

Extensions for querying spatial display geometry, rendering modes, eye tracking, and binding compositor output to application windows across Windows, macOS, Android, and Linux (X11 and Wayland)

Unity plugin with sample scene

UPM package for Unity with a working sample scene to get started quickly

Unreal Engine plugin (beta)

Initial release of the Unreal plugin for UE 5.7 on Windows, macOS, and Android — eye-tracked Kooima stereo, camera- and display-centric rigs, Blueprint components, material expressions, and zero-copy atlas handoff

Standard OpenXR app compatibility

Apps built against the standard OpenXR API work with DisplayXR without modification

Multi-app compositing

Runtime support for compositing multiple applications into a single spatial scene — D3D11, D3D12, Vulkan, and OpenGL apps running simultaneously

Spatial desktop shell

A 3D window manager built on the runtime — spatial windowing, window chrome, layout presets, Z-depth, rotation, persistence, and 8 layout modes including Theater, Carousel, and Expose

2D app support

Standard desktop applications captured as flat panels in 3D space via Windows.Graphics.Capture, with auto-adoption of visible windows and head-tracked parallax

Focus-adaptive rendering

Display automatically switches between 2D and 3D mode based on the focused app type — 2D apps get full-resolution flat rendering, 3D apps get stereo with interlacing

App launcher, graceful exit, and lifecycle

Spatial app launcher with 3D icon tiles, system tray integration, registered apps config. Graceful exit restores captured windows to original desktop positions

3D screenshot and capture

Capture stereo atlas frames via hotkey (Ctrl+Shift+C) or IPC — full-resolution SBS output before display-specific processing, with JSON sidecar metadata

AI-native runtime control (MCP)

Live spatial state and control exposed to AI agents over the Model Context Protocol — introspect stereo projection, capture frames, arrange windows in 6-DOF, save/load workspaces, all via natural language. Framework extracted to displayxr-mcp (May 2026) so the runtime, the reference shell, and any third-party workspace controller can embed the same agent surface

WebXR Bridge (shipped, since retired)

A Chrome extension plus a local bridge that gave WebXR pages the full DisplayXR surface — display info, rendering mode switching, tracked eye poses, HUD overlay, and input forwarding. Retired in runtime v2.11: it only ever helped pages explicitly written against session.displayXR, and that audience is better served by inline 3D in the DisplayXR Browser. Standard WebXR still runs on the runtime unaugmented

Workspace controller surface

XR_DXR_spatial_workspace header shipped, launcher tiles via *.displayxr.json app manifests, controller registration via Windows registry contract, and the reference shell now ships separately as its own installer. Any third-party (OEM, vertical, kiosk, AI-agent driver) can ship a workspace controller with the same first-class authority

Multi-compositor performance pass

Cross-process D3D11 fence to move sync off the render thread, capture-thread as the sole workspace-render driver (3.2× per-cube fps), and vendor 3D-state poll caching (37→59 fps per cube to hit 60Hz P0)

Standalone demo apps

A growing family of demos ships from their own repositories — a real-time Gaussian-splat viewer, a glTF 2.0 PBR model viewer, a spatial media player for stereo photos and video, a transparent click-through 3D avatar that floats over the desktop, and a streaming 3D city viewer on Google Photorealistic 3D Tiles

Truthful per-mode eye tracking

Rendering modes now declare whether they consume live eye tracking, isTracking reports the real tracker state end-to-end (including out-of-process apps), and apps get an edge-triggered event on tracking loss/recovery — shipped as a coordinated runtime + Leia plug-in release

Android runtime

The same OpenXR runtime now ships on Android, driving integrated 3D tablets and handhelds (ZTE Nubia Pad 2, Red Magic Explorer 3D) through the native Vulkan compositor. The vendor display processor runs out-of-process with a zero-copy buffer handoff, rendering is orientation-aware across portrait and landscape, and mixed 2D/3D display zones, per-mode eye tracking, and see-through transparency all carry over from the desktop. Model-viewer and media-player demos ship Android builds

Extensions under the DXR vendor author tag

All fourteen DisplayXR extensions renamed from the provisional XR_EXT_* naming to XR_DXR_*, under the project's vendor author tag (officially registered with Khronos, July 2026), and shipped as a coordinated v2.0.0 release train — runtime, shell, vendor plug-in, engine plugins, demos, and meta-installer moving together. Apps built against the old names keep working on runtimes before v2.0.0 or rebuild against the v2.0.0 headers; migration is one command (scripts/dxr_rename.py in the runtime repo)

One compositor pipeline, with OS-native app switching

The service runs a single always-on compositor pipeline with one display processor per panel, so any number of concurrent apps share the display instead of contending for it. Which app the panel shows follows the operating system's foreground window — connected apps carry a taskbar and Alt-Tab entry, focusing one hands it the display, and an app can take the panel over a running workspace and hand it back without either being torn down. Panel ownership is leased with mode changes applied on the render thread, client commits are paced to the display, and a plug-in that implements the new re-bind slot switches apps without the panel dropping to flat and back

Linux runtime — native Wayland

Linux is a shipping platform, and native Wayland is its primary target: glasses-free 3D windows run as native Wayland apps on Ubuntu 24.04 and 26.04 with GNOME, through a native Vulkan compositor and XR_DXR_wayland_surface_binding. Windows carry a translucent, rounded client-side title bar that sits outside the weave; a GNOME Shell extension shipped with the runtime tells it where each window is and keeps every step of a drag on the lens's phase lattice at any output scale, so the 3D stays locked while a window moves; and a window spanning the 3D panel and another display weaves only the part on the panel. Transparent apps float 3D over the live desktop, captured with the app's own window excluded and only while the content is actually transparent, and an opaque window declares an opaque surface so GNOME can scan a fullscreen weave out directly. All five demos ship one binary per app that picks native Wayland automatically by capability probe. X11 and XWayland remain supported as the legacy path (XR_DXR_xlib_window_binding), weaving only when the panel is addressed 1:1 at an integer scale. Every component ships a .deb built on the oldest supported release, and the meta-bundle installs runtime, vendor display-processor plug-in and all five demos with one command. Ubuntu 22.04 is supported with an X11 session recommended, but not yet hardware-validated. The out-of-process service path on Linux remains on the roadmap

Shell input forwarding

Keyboard and mouse input forwarding to captured 2D windows, including modern WinUI/XAML apps

macOS spatial shell

Port the multi-compositor and shell to macOS via Metal

DisplayXR Browser

A Chromium-based browser that renders the web normally and weaves glasses-free inline 3D on DisplayXR hardware, built on the runtime's window-bound weave service. The weave is GPU-resident — no per-frame CPU readback — and inline-3D web samples plus a JS helper library ship alongside it. 1.0 release channel: security updates follow Chrome stable

Expand demos and engine integrations

3D capture pipeline

Session recording, spatial replay, and dataset generation from live spatial content

Multi-display workspaces

Extend the spatial desktop across multiple tracked displays, starting with a single machine

Broader ecosystem and standardization