OpenXR extension headers for 3D-display runtimes. Auto-published from displayxr-runtime.
22 extensions, in 7 groups: what the runtime tells apps about the display, how an app drives the view math and 2D/3D compositing, how it hands the runtime its native window, the surface a swappable workspace controller uses, the app-agent bridge, and frame capture.
Spec links the formal specification where one is written; a dash means the header is the specification for now.
What the runtime tells apps about the 3D display they are rendering on.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_display_info |
XR_DXR_display_info.h |
23 | spec | Display dimensions, eye-tracking modes, and the data needed for asymmetric (Kooima) projection |
How an app drives the runtime's view math, declares which regions of its window are 3D, and hands pre-weave content to the vendor display processor — instead of re-implementing projection or weaving itself.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_cursor_depth |
XR_DXR_cursor_depth.h |
8 | spec | Opt-in: the app reports the nearest content under the cursor at xrLocateViews; the runtime places a cursor sprite just in front of it (and, since v5, draws it, with the app's own sprite or the OS cursor's look; since v8 also on any woven rect, so a web page's cursor is drawn by the runtime with the browser's real cursor), so the pointer never sits behind 3D content |
XR_DXR_depth_budget |
XR_DXR_depth_budget.h |
4 | spec | Advisory limit on how far behind the display plane a transparent app may render, chained on XrViewState at xrLocateViews |
XR_DXR_display_zones |
XR_DXR_display_zones.h |
3 | spec | A layout of independent 3D zones and flat 2D zones across one display, each 3D zone with its own view rig, plus the wish mask a switchable-lens panel honours; poll xrGetDisplayZoneRecommendedViewSizeDXR for per-zone sizes — XrEventDataDisplayZoneMetricsChangedDXR is deprecated and never emitted |
XR_DXR_lift |
XR_DXR_lift.h |
5 | spec | 2D-to-3D conversion as a service: depth, video depth, stereo or N views, and photo-to-Gaussian-splats, served by whichever conversion provider the runtime selects per task (apps see tasks; they may list the candidate providers read-only and hint one per stream, never set the user's default); enumerate tasks with their readiness and pushed state events, and wait for READY rather than fall back to an in-app converter; submit 2D frames (any platform image kind, explicit sync), acquire the latest result with its depth units and view metadata, or flag a weave rect as 2D so the service lifts it before weaving; the runtime owns the viewpoint policy, can derive the viewpoints from the app's own view rig, and returns depth from the same inference aligned to display space |
XR_DXR_local_3d_zone |
XR_DXR_local_3d_zone.h |
5 | spec | Per-pixel 3D-ness mask over an app's own window, with the flat 2D side as a first-class post-weave composition layer; its view-size event is soft-deprecated since spec 5 in favour of the Khronos XR_EXT_view_configuration_views_change, but still emitted unchanged |
XR_DXR_swapchain_color_encoding |
XR_DXR_swapchain_color_encoding.h |
1 | spec | Declares that a UNORM swapchain holds display-encoded (sRGB) values, so the runtime reads it like an _SRGB one: lets a 10-bit back buffer be submitted without converting it |
XR_DXR_view_rig |
XR_DXR_view_rig.h |
4 | spec | App declares a display or camera rig descriptor and consumes render-ready XrView{pose, fov}; the runtime owns the projection math — and, chained on the hand-joint locate, returns the joints in that same rig frame |
XR_DXR_weave |
XR_DXR_weave.h |
20 | spec | Window-bound synchronous weave for present-owners: hand the runtime a stereo texture and a window rect, get back a weaved shared texture and a fence (sync_file acquire/release fences on desktop Linux and Android, so the weave pipelines with the caller's GPU work); a window spanning two 3D screens is woven per screen, with each screen's eyes and each rect's per-screen parts handed back |
How an app hands its native window to the runtime so the compositor can output into it.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_android_surface_binding |
XR_DXR_android_surface_binding.h |
3 | spec | App-provided Android Surface / ANativeWindow, republished across background and resume, with the per-frame window rect and the surface's touch events for the runtime's touch input provider |
XR_DXR_cocoa_window_binding |
XR_DXR_cocoa_window_binding.h |
8 | spec | App-provided NSView, IOSurface sharing, runtime-owned phase-snapped window drag/resize (opt-out) |
XR_DXR_macos_gl_binding |
XR_DXR_macos_gl_binding.h |
2 | — | macOS OpenGL graphics binding |
XR_DXR_wayland_surface_binding |
XR_DXR_wayland_surface_binding.h |
2 | spec | App-provided wl_display and wl_surface (desktop Linux), plus the app-declared surface size that makes windowed Wayland work |
XR_DXR_win32_window_binding |
XR_DXR_win32_window_binding.h |
9 | spec | App-provided HWND, shared texture, canvas sub-rect |
XR_DXR_xlib_window_binding |
XR_DXR_xlib_window_binding.h |
2 | spec | App-provided X11 Display* and Window (desktop Linux) |
Which installed input provider drives an app's controllers, hands and gamepad, and how an app shows its user the choice and asks for one — while the user's own pins and defaults always win.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_input_providers |
XR_DXR_input_providers.h |
1 | spec | An app lists the resident input providers (the provider's own name, families it supplies, presence, which one holds this app's controllers / hands / gamepad) and requests one per family, optionally as the user's per-app pin |
The contract that lets a workspace controller — the DisplayXR Shell, or any third-party / OEM / vertical / AI-agent equivalent — drive the spatial-desktop layer on top of the runtime. Activation is gated by orchestrator-PID match; the runtime trusts whatever binary it was configured to spawn.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_spatial_workspace |
XR_DXR_spatial_workspace.h |
26 | spec | Multi-app composition across every 3D screen: screen enumeration, per-screen window placement and overlays, capture, modal input grab |
XR_DXR_workspace_file_dialog |
XR_DXR_workspace_file_dialog.h |
1 | spec | Async spatial-native file picker spawned by the active workspace controller, with fallback to the platform dialog |
How applications plug into the AI-agent surface, exposing their own actions through the same MCP framework the runtime and workspace controllers use.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_desktop_control |
XR_DXR_desktop_control.h |
3 | spec | An app's agent observes and operates the desktop (windows, UI text, typing, clicks) and, as a separate consent scope, captures screen stills, through the OS's own consent, granted to the app, never to DisplayXR |
XR_DXR_mcp_tools |
XR_DXR_mcp_tools.h |
1 | spec | An app registers its own MCP tools with the runtime's agent surface; calls arrive on the OpenXR event queue |
Getting the composed multi-view frame back out of the runtime — for screenshots, recording, and dataset generation.
| Extension | Header | Ver | Spec | Description |
|---|---|---|---|---|
XR_DXR_atlas_capture |
XR_DXR_atlas_capture.h |
3 | — | Vendor-neutral PNG snapshot of the multi-view atlas at a caller-selected compositor stage, for any app class |
XR_DXR_stereo_camera |
XR_DXR_stereo_camera.h |
6 | spec | A runtime-owned, privacy-gated stereo camera source: the display's own camera (usually the eye tracker's, supplied by the vendor plug-in without taking it from the tracker) or an opted-in plain UVC side-by-side webcam, fanned out by the service to clients as rectified newest-frame side-by-side pairs over shared memory |
Copy the headers into your project's OpenXR include path, or add this repo as a submodule:
git submodule add https://github.com/DisplayXR/displayxr-extensions.git external/displayxr-extensions
# Then add external/displayxr-extensions/include to your include pathextensions.json at the repo root is the same table, machine-readable — name, group, title, summary, specVersion, header path and spec URL — for tooling that wants the set without parsing headers.
- Extension Specs — formal specifications with examples
- Getting Started — build and integrate with DisplayXR
- displayxr-runtime — the OpenXR runtime
DXR is DisplayXR's Khronos-registered OpenXR author ID. The XR_DXR_* extensions themselves are provisional — they are not yet registered in the Khronos OpenXR registry: extension numbers and XrStructureType values sit in a provisional experimental block (1004999xxx) pending official assignment. Extension names are expected to be stable; numeric values are not. (These extensions previously shipped under provisional XR_EXT_* names; the rename did not restart SPEC_VERSION — the interface history continues.) See GOVERNANCE.md.
Apache-2.0. These headers are original, DisplayXR-authored extension definitions — the same license the Khronos OpenXR headers use, chosen for its explicit patent grant on the path to Khronos ratification. The per-file SPDX-License-Identifier is authoritative.
Headers, this README and extensions.json are all generated from displayxr-runtime on every push to its main — the header set from src/external/openxr_includes/openxr/XR_DXR_*.h, the per-extension notes from docs/specs/extensions/index.json, by scripts/gen_extensions_index.py. Do not edit them here — changes will be overwritten. Open PRs against the runtime; a header whose note is missing fails that repo's lint workflow, which is why this table cannot fall behind the headers again.