About DisplayXR

An open-source OpenXR runtime and the extensions OpenXR needs for spatial displays: one way to build spatial content for every display, from every vendor.

What is a spatial display?

A spatial display gives you a volumetric experience of what it shows. Content is perceived, and felt, in 3D space, in front of and behind the screen, instead of lying on a flat 2D plane.

On a flat display, content lies on the screen plane. On a spatial display, content occupies depth in front of and behind the screen.Flat display: on the screenSpatial display: in front of and behind itscreenscreen

The family is broad:

  • Glasses-free displays: tracked stereo, which follows your eyes, and light-field or multiview panels.
  • Stereo displays you wear glasses for.
  • And, by extension, headsets.

DisplayXR is for all of them, with or without glasses.

Headsets and spatial displays

The same person at the same desk: on the left in a headset, on the right in front of a display with 3D windows and no headset.

Both show spatial content to two eyes in real time, and both track the viewer. The difference is the device. A headset is worn and runs one exclusive session that owns everything you see. A spatial display sits on a desk, is a screen with a physical size and location, and shares that screen with ordinary 2D windows.

What they have in common is the content, and the contract an app uses to show it: OpenXR, the Khronos standard for XR applications.

Where OpenXR needs extending

OpenXR was written for headsets, so a few things a display needs have no words in it yet. DisplayXR adds them as XR_DXR_* extensions, under an author ID registered with Khronos, on top of an open-source OpenXR runtime that runs the official Khronos conformance suite. It builds on OpenXR; it is not a separate standard. Four examples:

Each eye's view converges on the physical display rectangle, an off-axis frustum per eye.

Where the display is

OpenXR assumes a headset: A headset moves with your head, so OpenXR hands the app a symmetric field of view.

On a display: A display has a physical size and stays put, and both eyes look at the same rectangle from different places.

DisplayXR adds: The panel's size and position in metres, the tracked eye positions and the rendering modes, so each eye gets the right off-axis view. A 10 cm cube renders 10 cm.

XR_DXR_display_info · XR_DXR_view_rig

Three 3D apps in three ordinary windows on one desktop monitor.

Many windows, not one screen

OpenXR assumes a headset: A headset session is exclusive: it owns the whole display, because on a headset that is the whole world.

On a display: On a desk, several 3D apps share the screen in ordinary windows you drag, resize and overlap.

DisplayXR adds: Window binding: the app hands the runtime its own window, and each window keeps its 3D while it moves.

XR_DXR_win32_window_binding · XR_DXR_cocoa_window_binding · XR_DXR_xlib_window_binding · XR_DXR_wayland_surface_binding · XR_DXR_android_surface_binding

A laptop showing a web page whose product image is in 3D while the page around it stays flat.

2D and 3D in the same window

OpenXR assumes a headset: Core OpenXR's layers (projection, quad, cube, cylinder) describe a world, not a 3D region inside a 2D window.

On a display: Most of a screen is text and menus. The 3D is one region inside the window, with the flat page around it.

DisplayXR adds: 2D/3D zones: 3D inside, a flat page around it. This is the same capability a 3D object inside a web page uses.

XR_DXR_display_zones · XR_DXR_local_3d_zone · XR_DXR_weave

A friendly 3D character standing over ordinary desktop windows, transparent around it.

3D over the desktop, when you want it

OpenXR assumes a headset: In a headset there is no desktop: one compositor draws everything the eyes see.

On a display: On a desk, 3D can sit over ordinary flat windows, see-through around its edges, with clicks passing to the window behind.

DisplayXR adds: Transparent presentation and a depth budget, so 3D content can live on top of the desktop without taking it over.

XR_DXR_depth_budget · XR_DXR_spatial_workspace

Why it is modular

Displays differ, and they should: the optics, the eye tracking and the calibration are what each display maker does best. So DisplayXR draws one line. Apps talk only to OpenXR and the extensions. Each display maker ships a display plug-in that does the display-specific work, and tracking hardware plugs in the same way through a separate input-provider plug-in.

Apps never touch a vendor, and vendors never touch an app. The runtime itself carries no vendor code, and its build checks that. An app written once runs on every display that has a plug-in, and a new display runs every app that already exists.

The open DisplayXR runtime on one side of a plug-in boundary; each vendor's plug-in, and the simulated display, on the other.

Why the web matters

Most spatial content will not be an installed app. It will be a product on a shopping page, a movie, a photo, a call. The DisplayXR Browser and its SDK let anyone make and share that content with a few lines of JavaScript and a URL, and the same page stays an ordinary page on every other screen.

The direction: one framework

Today a headset and a spatial display are different device classes with a common contract. Where this is heading is one framework for spatial content on both: the same content and the same API, whether you wear the display or put it on your desk. That is why DisplayXR extends OpenXR rather than standing apart from it.

Open, neutral, and how to reach us

The runtime, the extensions, the engine plug-ins and the demos are open source. DisplayXR is vendor-neutral: any display maker can write a plug-in, free of charge and without permission. How decisions are made is on the governance page.

Questions and ideas: GitHub Discussions. Partners and press: partners@displayxr.org.

The Ecosystem

More than a runtime

DisplayXR is developing as a full ecosystem — runtime, extensions, engine plugins, projection math, demos, and reference workspace controllers.

See it running

The DisplayXR Gallery is a live gallery of 3D photography: a curated set of stereo captures, woven natively in the DisplayXR Browser and degrading to a cursor-driven parallax preview in any other browser. It doubles as the reference for how an inline-3D page should behave — the same page serves both, with no separate 3D build.

Every photo carries per-eye depth, so a Depth view can turn any shot into its own depth map. On a 3D display that view stays dimensional rather than flattening into a picture of a depth map — which is the difference the format is for.

Core

Engine Plugins

Libraries

displayxr-common
Shipping

Shared math and common library — off-axis (Kooima) projection, atlas tiling, and window/canvas helpers — including one Linux app window that picks native Wayland or X11 by capability probe, with shared client-side window chrome — consumed by the runtime, engine plugins, and demos from a single source of truth.

displayxr-mcp
Shipping

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.

displayxr-vendor-template
Early

Vendor-neutral starter kit for building a DisplayXR display-processor plug-in — the ABI, discovery, and build scaffolding a new 3D-display maker needs, with no vendor SDK required. Fork it to bring up a plug-in against the sim_display path, then swap in your own weaver.

displayxr-cef-host
Experimental

The original proof that XR_DXR_weave works — not a browser to use, which is DisplayXR Browser. A small CEF (Chromium Embedded Framework) offscreen-render app that hands the runtime a stereo texture and a window rect and composites the weaved result; it never weaves itself. Kept as the smallest worked example of driving the weave from your own present-owner without forking Chromium, and because it builds in minutes where the browser fork takes hours. It is pinned to the first revision of the weave spec, far behind the runtime's current one, so it does not exercise batched submit, the 2D overlay atlas, N-view input, the Android handle kinds, or IPC brokering — treat it as a starting point to read, not a current conformance harness.

displayxr-web
Shipping

The inline-3D JavaScript SDK, published on npm as @displayxr/inline3d — 3D photos, video, models, Gaussian splats, a 3D media player and 3D video calls in a few lines — plus its live samples on GitHub Pages, which double as the DisplayXR Browser's start page. Every page renders as ordinary 2D in other browsers.

displayxr-models
Active

Content-addressed ONNX depth and inpainting models behind the DisplayXR Browser's Convert to 3D — permissively licensed only, published as permanent release blobs.

Demo Applications

Workspace Controllers