| CARVIEW |
Below are answers to some common questions about the processes we use to create and update the OpenXR standard. If you still can’t find the information you need, please reach out to us at memberservices@khronosgroup.org!
What are the benefits of a paid Khronos membership?
Khronos members may participate in any Khronos Working Group, including attending OpenXR virtual and in-person meetings for specification planning and development, and have access to all NDA-protected OpenXR development materials and draft specifications - including the Khronos member-only GitLab repository where most specification development occurs. Membership also provides effective networking with key XR runtime and application developers from around the industry. Although non-members can contribute to specifications on GitHub, being an active member of the OpenXR Working Group is by far the most effective way to have an inside-track understanding and influence on OpenXR’s evolution.
What is the difference between a Khronos member and an OpenXR Adopter?
Any Khronos member can join the OpenXR Working Group to directly influence the specification during its development. OpenXR Adopters implement the specification in their product. Once those products pass conformance testing, Adopters can publicly advertise their conformance and enjoy the patent licensing protection of the Khronos IP Framework. A company can choose to be either member-only, adopter-only, or both at any time. More information can be found on the Khronos Membership page and the Khronos Adopters page.
I want to help OpenXR and evaluate whether membership is right for me before I pay. Is there another way to get involved?
Yes: The OpenXR Advisory Panel is free to join. Although it does not provide direct access to Working Group meetings and materials, it does grant access to a number of IP- and NDA- protected resources, and enables providing early feedback on draft specifications to the Working Group.
I’m a developer building an application using OpenXR. Do I need to become an OpenXR Adopter to say that my app was built using OpenXR?
No: Only companies who have implemented the OpenXR Specification and wish to publicly advertise their conformance with the OpenXR specification and gain patent licensing protection under the Khronos IP Framework need to become Adopters. Using Khronos APIs is always free to application developers.
How are my Khronos membership dues and Adopter fees used?
As a non-profit, all Khronos membership dues and Adopter fees are reinvested into Khronos standardization activities for the benefit of Khronos members and the wider industry. The OpenXR Working Group is allocated an annual budget, which it uses to fund projects that advance the OpenXR ecosystem, including contracting work to evolve the OpenXR Conformance Test Suite, OpenXR Tutorials, the Monado open source sample OpenXR implementation, and the Input Rebinding Infrastructure.
What is the OpenXR Conformance Test Suite (CTS)?
The OpenXR Specification is a text document of 1000+ pages that details how an XR system should run, but it does not specify how to implement specific functions. This means one company's implementation of the OpenXR specification may differ from another, as often proprietary runtime source code is not shared. The open source OpenXR Conformance Test Suite (CTS) is used to confirm that an OpenXR implementation correctly implements the specification by performing a large number of functional tests. The OpenXR CTS is continuously improving and is an effective tool to help ensure implementation consistency and compatibility across devices.
Do I need to be an Adopter to implement the OpenXR specification in my product?
OpenXR is a royalty-free, open standard. This means anyone can view the specification, implement it in their product, test it using the publicly available CTS, and use it without being a member or Adopter. However, the OpenXR trademark is protected by Khronos and must be used within the Khronos Trademark Guidelines. If a company has a product that implements the OpenXR specification and they wish to advertise their conformance with the OpenXR standard and use the OpenXR mark on their product, they must become an Adopter and pass the latest version of the CTS. By controlling trademark use, Khronos ensures OpenXR implementations meet the high-quality standards needed for reliable cross-platform compatibility. Adopters with conformant implementations also enjoy a royalty-free patent license from all other Khronos members - a significant benefit.
Do OpenXR Implementations submit CTS results for each version of the specification?
The OpenXR trademark can be used with a product that passes a specific version of specification and conformance tests - but must report the versions that are used. We encourage all implementers to keep their implementation and conformance testing up-to-date. OpenXR is currently working on improving the CTS results to better show developers if their application will be compatible with specific hardware given their latest test results.
Do I need to be a Khronos member to contribute to propose bug fixes, updates or extensions for the OpenXR specification?
No: The OpenXR specification is a public document, and any help to improve the specification and associated software and tooling is always appreciated. Please file issues and submit pull requests depending on your needs in the Loader, Validation Layers, and Code Samples or Specification, Header Files, Spec Support Files, and Extensions GitHub repos. If you are creating a vendor extension, please review the OpenXR Extension Process and Style Guide.
How does functionality evolve to be included in the core OpenXR specification?
Core specification updates are created by Working Group members. The OpenXR specification is flexible and extensible to encourage rapid innovation, and often valuable additional functionality begins as a single-vendor extension. If there is interest from multiple vendors, the proposal may evolve into a multi-vendor extension, which, with further Working Group review and consensus, stands a good chance of being integrated into the core specification itself. This path offers a structured and collaborative approach to rapid standards innovation and adoption.
Why does it take so long to develop new API versions?
Building consensus among multiple companies will always take longer than a single company writing their own proprietary specification. But the time and effort taken to integrate the input and perspectives of multiple vendors is a feature of the standardization process - not a bug! It not only results in functionality that can be implemented on multiple devices, but the specifications resulting from leveraging expertise from across the industry often have significantly enhanced functionality and usability. Nevertheless, now that OpenXR 1.0 has achieved such wide adoption the OpenXR Working Group is working hard to increase the frequency of core specification releases to meet the evolving needs of the industry.
Why are there so many vendor extensions? What is OpenXR doing to reduce fragmentation to enable better application portability?
OpenXR enables vendor extensions to be developed for rapid deployment of new functionality. As OpenXR is still early in its evolution, this has resulted in significant experimentation and a large number of vendor extensions with single-vendor support. Now that an increasing amount of functionality is gaining cross-vendor support, OpenXR is working hard to replace multiple developer extensions with unified cross-vendor extensions, and to integrate broadly available functionality into new core specification versions. The OpenXR Extension Compatibility Matrix is a useful resource to keep developers informed about extension support across different platforms.
What is the OpenXR Device Layer?
The "Device Layer" in OpenXR is the component of the OpenXR architecture that deals with the abstraction of hardware devices. This layer enables OpenXR-compliant applications to interact with a wide range of VR and AR hardware without needing to directly implement support for each individual device. Instead, the Device Layer provides a standardized interface for accessing device capabilities, such as input, tracking, and display output, making it possible for developers to create applications that are compatible with any OpenXR-supported hardware.
I’m a hardware peripheral developer and want to introduce new technology to be used with XR systems. Is OpenXR an effective API to enable my hardware to be compatible with the various headsets?
Yes: this is the purpose of the OpenXR Device Layer. However, keep in mind that the OpenXR Device Layer is still in early development. If you want compatibility now, peripheral systems have integrated successfully using OpenXR API Layers or directly interfacing with the application.