[Posted a few days ago on Stack Overflow, but no reply there yet.]
How to query the OpenXR runtime library’s API version?
xrCreateInstance requires a value for XrInstanceCreateInfo::applicationInfo.apiVersion
“If the runtime does not support the requested apiVersion [xrCreateInstance] must return XR_ERROR_API_VERSION_UNSUPPORTED”
Is there a way to query the runtime’s API version? The Windows Mixed Reality (WMR) “OpenXR Tools” application displays it, so I guess the answer should be “yes”, but I haven’t found how.
I’ve seen a suggestion to set XrInstanceCreateInfo::applicationInfo.apiVersion = 0 to supposedly guarantee that xrCreateInstance will not fail with XR_ERROR_API_VERSION_UNSUPPORTED, but I see nothing in the specification that supports that. And in fact, I tried it, but got XR_ERROR_API_VERSION_UNSUPPORTED.
Moreover, even if xrCreateInstance succeeds, the value returned in XrInstanceProperties::runtimeVersion is “not necessarily related to an OpenXR API version”.
Thanks for any suggestions.
Side note: I just updated my OpenXR SDK (headers and loader library) to 1.1.41, but now I’m getting XR_ERROR_API_VERSION_UNSUPPORTED. The WMR OpenXR tools reveals that the runtime library API version is 1.0.28 – for the Oculus (Meta Quest Link) runtime as well as the Microsoft WMR runtime on both the PC and the HoloLens.
Not sure where you heard you could set XrInstanceCreateInfo::applicationInfo.apiVersion to 0, that is definitely not a thing that has ever been true.
We used to advise using XR_CURRENT_API_VERSION there but when you upgrade your SDK from 1.0.x to 1.1.x that accidentally starts requiring OpenXR 1.1. Instead use XR_API_VERSION_1_0 if you’re writing an OpenXR 1.0 app.
The “advice” to set apiVersion = 0 was courtesy of GPT 4.0. Sometimes it’s helpful, sometimes not. It’s a better search tool than Google. I never blindly trust it. After getting that advice, I specifically searched the spec for any mention of that, and failing to find it, I said so to GPT, whereupon it “apologized” and backed off. I tested it anyway, but was not surprised that it failed.
I was using XR_CURRENT_API_VERSION, but after updating the SDK that broke some stuff.
I’m trying to make a robust application that will adapt to and work with whatever it finds. I already had a configuration option to specify which runtime to use – e.g., Oculus, or Windows Mixed Reality. So my fix was to add another configuration option to specify the API level that corresponds with the selected runtime. It occurred to me to try iterating through major.minor variations, to find the highest match, but I opted to specify the value in my config file instead to avoid the need to revise that test for every increment of the minor number.
Somehow, the Windows Mixed Reality tool is able to display the API major.minor.patch: 1.0.28 . I’m wondering how they do that, but past worrying about it. They could iterate through major.minor, but as I understand it the patch number doesn’t affect compatibility. I’ve tested that too, by configuring an arbitrarily large patch number, and xrCreateInstance seems to succeed as long as the major.minor are OK. So I’m curious how that tool determined 28 for the patch number. But at this point it’s just a curiosity, not a show stopper.
If you’re not using OpenXR 1.1+ features in your application, just use XR_API_VERSION_1_0. There are no disadvantages over using OpenXR 1.1+ other than new functions (and possibly future extensions that depend on OpenXR 1.1) not being available.
There isn’t a hard requirement that runtime must support OpenXR 1.0 (and not only OpenXR 1.1) but it’s strongly encouraged and in fact all runtimes today that support OpenXR at all do support OpenXR 1.0.
If you want to follow a more upstream issue, there is:
@Rectus et al. [“new users can only mention 2 users in a post”]: Thanks – I guess I should have suspected that. It did strike me as strangely coincidental that all of the runtimes I checked – PC Oculus, PC WMR, and HoloLens WMR – all displayed the same patch level.
@haagch Ideally it would be nice (I think) to have a robust application that uses 1.1 features if available, but falls back to 1.0 if necessary. But knowing what I know now, I can approach the problem differently.
