Develop

Meta OpenXR SDK

Download

Updated: Jun 5, 2025|

Version

77.0

Includes OpenXR API resources for native development of Meta Quest devices. Create portable code that can be used on devices from multiple vendors.

Version 77.0 Release Notes

The Meta OpenXR SDK is now available on GitHub.
You can access the GitHub repository through the following link: https://github.com/meta-quest/Meta_OpenXR_SDK
Current OpenXR Version
1.1.46
What’s New
Introduced stationary reference space as an experimental extension extx2_stationary_reference_space. See XrSceneModel sample for its usage.
What's Fixed
Fixed some clang errors sample framework
Runtime Behavior Changes

We sometimes find that the runtime shipped with a bug or non-conformant behavior and in such cases we may change the runtime so that future applications get conformance and bug fixes.

In cases where such bug fixes or behavior changes may be incompatible with existing applications, the OpenXR version number that an application is compiled against is used to gate the behavior change. This allows older applications that may have been working around the issue continue to work as expected, while newly-built applications can receive the conformant or correct behavior.

For example, if your app builds with version 1.0.25 and a behavior change is gated on 1.0.26, then your application will continue to function as expected even with a newer Oculus OS runtime built to support OpenXR version 1.0.26 or greater. However, if you rebuild your application with 1.0.26 or greater, the new behavior will be enabled for your application.

The following list is intended to give developers forewarning of such behavior changes in order that they might be addressed when applications are updated and built on against newer OpenXR headers.

Behavior Changes On Upcoming OpenXR Version:
Clients linking against OpenXR version >= 1.1.49 will have "/user/hand/{left|right}/input/aim/pose" match the system shell. However there was a bug in this implementation that resulted in the pose being rotated 180 degrees around the z axis; this bug will be resolved in OpenXR version >= 1.1.53.
If you update your application to OpenXR >= 1.1.49, and notice that your controllers are rendering upside down, then you are affected by this issue.
To mitigate this bug take one of the following actions:
If you are already using the grip pose for rendering controllers, you should need no additional changes. This covers all apps using OVRPlugin for input.
If you are using the aim pose for rendering controllers, but can change to using the grip pose, that can solve the issue. This is preferred because the grip pose is preferred for rendering the controller.

One way to accomplish this is to apply this transform to the grip pose, which will convert the grip pose to the old aim pose, then you can use the grip pose as the old aim pose.

Vector3(0.000000, -0.019641, -0.100981), \ Quaternion(0.866025, -0.500000, 0.000000, 0.000000)

Please note: This offset is specific to the Horizon OS runtime and may not work properly if you cross-publish to other platforms.
- If you cannot change to rendering with the grip pose, then you can opt to stay on OpenXR version 1.1.48 or below, and wait until OpenXR version >= 1.1.53 when the mitigation will go live. This will flip the aim pose back around, but keep the direction the same. With this option you will still get new OpenXR extensions and features, but will not get updates via patches to existing OpenXR functionality.

Behavior Changes On Previous OpenXR Version:
Apps linked against OpenXR headers older than 1.0.22 have their XrSwapchainCreateInfo.next pointer ignored to prevent Unity applications from crashing due to an uninitialized next pointer.
Apps linked against OpenXR 1.0.23 or newer treat the XrCompositionLayerImageLayoutFB.flipY flag correctly. Prior to 1.0.23 there was a bug in the OpenXR implementation where this flag was ignored.
Prior to OpenXR version 1.0.23 the thumbs joints of our hands were rotated in a way that did not match OpenXR specification. Apps linked against 1.0.23 and greater should get thumb joint rotations that match the specification.
Apps building against OpenXR version 1.0.24 or higher can enable STAGE space when a stationary Guardian is configured.
Apps linked to OpenXR versions prior to 1.0.24 would not receive data to the khr/simple_controller action profile and grip and aim poses were broken. Apps linking to 1.0.24 or greater should receive the correct data.
Clients linking to OpenXR version 1.0.28 or higher will now have output structs types correctly validated. Applications that are passing invalid structure types to xrEnumerateConfigurationViews or xrLocateViews may now be returned an XR_ERROR_VALIDATION_FAILURE error where they previously were not.
Clients linking to OpenXR version 1.0.29 or higher cannot rely on the return value of xrGetFaceExpressionWeightsFB to know if the returned expression weights values are valid. Instead they should check the valid flag on the XrFaceExpressionWeightsFB struct. Note that the valid flag is set on older OpenXR versions as well.
Clients linking against OpenXR version >= 1.0.29 will have the XR_HAND_JOINT_PALM_EXT pose calculated as (XR_HAND_JOINT_MIDDLE_METACARPAL_EXT pose + XR_HAND_JOINT_MIDDLE_PROXIMAL_EXT pose) / 2.
Clients linking against OpenXR version >= 1.0.31 need to request the scene permission com.oculus.permission.USE_SCENE in the app to display the permission dialog and get user consent before they can query scene data use XrQuerySpacesFB.
Quest 2 clients linking against OpenXR version >= 1.0.34 will default to the Display P3 color space. To maintain the previous behavior, clients must explicitly set the Rift CV1 color space with xrSetColorSpaceFB.
Clients linking against OpenXR version >= 1.0.37 will only be able to query action states on subaction paths that were explicitly enumerated when the action was created. If XR_NULL_PATH is used to create an action, then subaction paths will not be queryable on this action.
Clients linking against OpenXR version >= 1.0.38 will be able to receive scene data corresponding to multiple rooms from xrQuerySpacesFB.
Clients linking against OpenXR version >= 1.0.40 will use the path up until the identifier to determine the priority to use for an action during priority resolution. Prior versions will use the full path, meaning less conflict between actions.
Clients linking against OpenXR version >= 1.0.40 will be able to receive visibility mask data from xrGetVisibilityMaskKHR.
Clients linking against OpenXR version >= 1.0.40 will be able to set and enable the XR_SPACE_COMPONENT_TYPE_SHARABLE_FB on Rooms - XrSpace with XrRoomLayoutFB component, via the xrSetSpaceComponentStatusFB API.