Governance

DisplayXR is an open incubator for spatial-display extensions to OpenXR, with the aim of upstreaming proven extensions into the official specification. The project is maintainer-led during incubation, with governance intended to broaden as adoption grows.

Project status

DisplayXR is in its incubation phase, maintained by a small core team. During this phase, vendor neutrality rests on three structural guarantees:

Open by license

Extension specs, runtime, engine plugins, and demos are permissively licensed open source — the runtime is a Monado-derived codebase under the Boost Software License.

Neutral by architecture

Every display vendor integrates through the same documented plug-in boundary; no vendor has a privileged code path. The first such plug-in targets Leia-based displays — one implementation of that boundary among the many it is designed to support.

Decided in public

Design rationale is recorded as public Architecture Decision Records. Architectural decisions take effect when they're written down.

How an extension becomes part of the standard

The lifecycle is modeled on the OpenXR working group's own process. Extension identifiers are provisional until registered with Khronos through the official process.

  1. 1

    Proposal

    An issue or spec PR on displayxr-extensions: the problem, the API surface, and which display classes it serves.

  2. 2

    Spec + implementation

    No spec lands without a working implementation in a conformant runtime. Both are reviewed together — the OpenXR working group's own rule.

  3. 3

    Experimental

    Merged extensions ship in the runtime marked experimental; the API can still move in response to real-world use.

  4. 4

    Stable

    Once shipped applications depend on it and a full release cycle passes without breaking changes, the extension is frozen.

  5. 5

    Upstream

    Extensions proven across multiple vendors' hardware become candidates for the official Khronos OpenXR registry.

The path to shared governance

The transitions below describe the direction the project intends to take as adoption grows — a statement of intent for how governance will broaden, not binding commitments.

Today — incubation

current

Maintainer-led by a small core team. All design happens in public: specs, ADRs, issues, and PRs. Neutrality is enforced by architecture and license.

A second, independent vendor adopts the plug-in boundary

The project intends to form a Technical Steering Committee with representation from participating organizations alongside maintainer seats, and to move extension approval to that committee.

Extensions in production across multiple vendors' hardware

The project intends to pursue formal Khronos engagement — an exploratory-group proposal and/or submission of proven extensions to the OpenXR working group.

Khronos adoption

Specs migrate to the official OpenXR registry. The project intends to continue as the open reference implementation and the incubator for the next round of extensions.

How to participate

A second independent vendor plug-in is the milestone at which the project intends to move toward shared governance. Display vendors start with the plug-in guide; developers and contributors start at Contribute. No membership, fee, or affiliation required.

Read the full governance document