Not Resolved - Open XR was broken with v68 Oculus Link

[bOOba_SciFi]

Hi,

As a conversation here: https://www.reddit.com/r/oculus/comments/1e6lq00/comment/lecf5bu/

we have broken code in v68. How quick can we have an update from Oculus?

[XtreamerPt]

Using quest 3 with Meta Quest Link 68.0.0.433.361 (68.0.0.433.361)

Every PCVR game with openXR, i mean the developer from openXR aproach meta about the error in test software. You don't need any more information about the trouble, openXR dev posted in reddit about what to do to fix it.

Here i pasted it, fix the damm thing before v69!

For what it's worth, I broke my rule and I looked into the OpenXR Toolkit crash in PTC.

Conclusions: 100% a bug on Meta's side.

They are failing a perfectly valid call to xrEnumerateInstanceExtensionProperties() that follows the proper "two-call idiom" per OpenXR 1.0 spec, section 2.13. "Buffer Size Parameters".

They incorrectly return error XR_ERROR_SIZE_INSUFFICIENT, while this call is clearly following a valid pattern:

uint32_t extensionsCount = 0;
CHECK_XRCMD(xrEnumerateInstanceExtensionProperties(nullptr, 0, &extensionsCount, nullptr));

(somehow reddit's making this very small, click above to enlarge)

See the relevant bits of OpenXR spec:

A two-call idiom may be employed, first calling xrFunction (with a valid elementCountOutput pointer if in parameter form), but passing NULL as elements and 0 as elementCapacityInput, to retrieve the required buffer size as number of elements (number of floats in this example)

It is valid to pass 0 for the elementCapacityInput parameter (i.e. capacity of 0 does not return XR_ERROR_SIZE_INSUFFICIENT). The function sets elementCountOutput to the required size in number of elements.

This bug isn't obvious at first because the error code seems to be swallowed by the OpenXR Loader. However because OpenXR Toolkit is very special software, it goes around the OpenXR Loader (by necessity), and is exposed to the bug first-hand.

Also FYI, other projects based on my API layer template, such as OXRMC or OpenXR-OBSMirror, will all hit the same issue I believe.

Now the good news is: such bug is likely to get fixed, if people report the above to them.

EDIT: If someone really want to waste their time on this, you can remove the CHECK_XRCMD() wrapping that function call in dispatch.cpp. This effectively ignores the bogus return value from Meta's runtime and allows everything else to proceed (confirmed myself).

EDIT2: I wrote a detailed bug report and sent it directly to the Meta developers in the Khronos chat room (that's the people who write this code).

EDIT3: I have messaged a few fellow API layer developers to inform them of this issue and the possibility to workaround it in their projects.

---

---

---

[Sentryuk]

The devs are already aware - infact even eagle dynamics who make dcs where aware the v68 update was going to break openxr toolkit ( they noted it in their latest patch release notes !) before you even released it - as it was found in the dev branch and people tried it - yet meta went a head and released it anyway ! Someone in the community figured out the issue and contacted the devs on Kronos (might spelt that wrong ) and the devs replied it would be fixed in v69. Now frankly that’s not good enough -you knew it was an issue before even releasing it and someone needs to roll out an urgent fix -you can’t leave a huge part of the community waiting a month !! 

meta need to be doing a far better job and it’s about time some one senior put a post on these forums - acknowledging you done a crap job of testing releases and promising to take far greater care of the pcvr community cos given the repeated breakages  people are now thinking of going elsewhere - I certainly am.  

[TheAntiSocializer · Accepted solution]

Hey guys, looks like I've already heard back from our internal team. They wanted me to let you all know that it appears these apps aren't from our store but from different platforms. Along with that, some users mentioned a graphics card driver update resolving the issue, so please feel free to give that a shot.

The other thing that they mentioned would be best in the meantime is to uninstall/disable OpenXR Toolkit.

Other than that, the best thing I can personally recommend would be to submit bug reports as you run into these issues. This way they'll go straight to the engineers with more in-depth info of that they'd need.

UPDATE 8/2:

The team just let us know that a hotfix is in the works of being deployed and is starting to be pushed to the PTC for the PC app. They are suggesting users having this issue should try swapping to the PTC for the PC app.

[herve177]

Hello

What driver update ?  the printer ..

[HattrickSwayze]

If they're aware of it, are there any plans for a hot fix? A lot of PCVR users rely on OpenXR toolkit to manage FPS and quality. It sounds like this was reported to you guys before V68 was released but it was released anyways. I'm losing quality/FPS by not being able to use OpenXR toolkit.

[ModusPatrick]

It's worth noting that this is not only affecting  Open XR Toolkit. I do not use Toolkit, but our software does utilize the Open XR API to Unreal Engine 4.27

Suggesting that Open XR Toolkit is the culprit (and disabling it is a suggested fix) is not helpful.

[Y0.Y0]

Which driver update?

[Squirrel_SA]

For anyone looking for a short-term workaround, you can set SteamVR to be the default OpenXR runtime. You still need the headset connected via Meta Link, but the runtime will be Steams OpenXR and the Toolkit and other API reliant apps should work. For instance I am running iRacing via the SteamVR OpenXR runtime with the toolkit functional and overlays. There's a small performance overhead so it's a trade-off.

EDIT: Further testing and usage has made me change my opinion, this isn't a viable work-around. Performance is wildly variable between apps and even situations within apps (different tracks in iRacing for instance Okayama is unplayable) so nope, don't do this. Sorry!

[ModusPatrick]

In our testing, the performance hit is massive when using Steam VR as the Open XR Runtime in conjunction with Meta Quest Link.

Steam Link is a better option, but seems to have a high amount of CPU overhead, so may not be viable for some.

Virtual Desktop is a viable solution, but isn't free. Depending on your use case, it may be worth the $25 investment (especially if you're a Racing/Flight Sim person)

[Squirrel_SA]

Interesting - I am using a wired solution so Steam Link/VD would require some additional hardware, but for me the performance hit of Steam VR as the runtime seems to be about 10-15% fps (from 90 to 72-80) - this is only in iRacing mind, and on wired connection.

EDIT: This is no longer the case for me, in certain situations Steam OpenXR run time performed really well, but in broader testing in iRacing, X-Plane, and other OpenXR titles it's not a solution. Performance for me is wildly variable - 90 fps and smooth, to 12 fps and nausea. Sorry all. Not a work-around.