Setting XrApplicationInfo.apiVersion to the correct version

[rickyjames35]

I'm developing a native C++ OpenXR app for the Meta Quest 3 but I can't seem to properly set the api version to anything other than XR_MAKE_VERSION(1, 0, 0)

Ideally this should work assuming I'm using a supported OpenXR version:

XrApplicationInfo applicationInfo;
applicationInfo.apiVersion = XR_CURRENT_API_VERSION;

However this results in a:

xrCreateInstance: API Version [281479271677988] not within supported range [281474976710656,281474976710656]

If you do the math 281479271677988 is 1.1.36 and 281474976710656 is 1.0.0

If I use XR_API_VERSION_1_0 as shown in the example here: https://developer.oculus.com/documentation/native/android/mobile-openxr-instance-session/

It works without any issues. But I can't seem to set it to the correct version. At the time of writing this Meta OpenXR SDK 67.0 is based on OpenXR 1.1.36 https://developer.oculus.com/downloads/package/oculus-openxr-mobile-sdk/ I'm guessing the discrepancy between what version of Meta OpenXR SDK vs OpenXR has caused this issue? I'm thinking I can just ignore this and just hard code it to 1.0.0 which is likely what the Meta OpenXR runtime is hard coded to expect? I'm also thinking / hoping that the Meta OpenXR runtime won't actually stop me from making newer 1.1.x API calls even though I told it I was using 1.0.0. Let me know if my assumptions are correct.

XrApplicationInfo Manual Page for reference: https://registry.khronos.org/OpenXR/specs/1.1/man/html/XrApplicationInfo.html

[lionleaf · Accepted solution]

Hi rickyjames35,

At the time of writing, using the latest 1.0 version number given by XR_API_VERSION_1_0 is the correct version to use for the Meta Quest devices. Note that it is important to not just use the 1.0.0 version, since that might opt you into compatibility behavior including old bugs.

Thanks for highlighting the confusing error message, I will forward that internally. 

Best,

Andreas Selvik 

[rickyjames35]

Thanks for the reply @lionleaf. Your suggestion does work, but now I have a followup about how the versioning is intended to work.

As you pointed out, using XR_API_VERSION_1_0 is the correct thing to do. XR_MAKE_VERSION(1, 0, 0) and  XR_API_VERSION_1_0 are not the same. Under the hood it XR_API_VERSION_1_0 gives you:

#define XR_API_VERSION_1_0 XR_MAKE_VERSION(1, 0, XR_VERSION_PATCH(XR_CURRENT_API_VERSION))

Since I'm using the latest OpenXR library at the time (1.1.38), this actually gives me the equivalent of XR_MAKE_VERSION(1, 0, 38). This does run and work on the device but seems very strange given 1.0.38 was never an OpenXR release. Is Khronos doing something different with how they are handling semantic versioning and are support both the 1.0 and 1.1 api at the same time on the same branch and the patch number applies to both api versions?