Latest Oculus Beta version breaks OpenXR Toolkit

This is very bad. I know many quest users who use the meta app to cable connect to the PC, and rely on OpenXR toolkit to improve performance when using aims such as iRacing and MSFS! If the meta app breaks the use of this, there will be much howling on Reddit and an even greater migration to other headsets.

Please meta, stop treating the Meta PC app as an afterthought. For a large number of users, PC connect is the major use for our VR experience.

I can also confirm this. I use the Beta Branch to run my Quest 3 at 120jhz  I play mostly ATS and ETS  which both support OpenXR natively, neither will launch with OpenXR anymore.  I tested it with SteamVR and it runs fine. I also did a full reinstall and it worked until the update gets pushed then it’s non functional again it won’t even launch using the “spoof” OpenVR dll

I need the 120hz for ATS/ETS to maintain a minimum 60fps for smooth performance.  

I ONLY play via the Link cable so I rely on the Oculus App  using OpenXR for all my VR usage. 

I mean this is really my first real major issue with the program. I get that it’s Beta so this where we expect possible issues. Well this is one and being reported and confirmed.  I am a Beta Tester so this isn’t my first rodeo but when an issue is reported the whole point of Betas is to push fixes to rectify them before going into the public channel…

Its a big problem and it looks like in v68 Meta did some kind of bugs in his codes: https://www.reddit.com/r/oculus/comments/1e6lq00/comment/lecf5bu/

Release General Availability #3 - Hotfix 2 (1.3.2) · mbucchia/OpenXR-Toolkit (github.com)

Apparently v68 is going live today - it's unclear if Meta / Oculus have acknowledged / fixed this bug.

Its a bug with Meta, not with OpenXR toolkit.

From Reddit: 

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));

<image>
(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.

Honestly, this is my last ever meta product. The utter lack of care they take with the products is beyond a joke.   I never had this issue with my HTC vive. I never had this issue with my valve index. yet I get a quest 3, and first I have the USB C debris in the charger software issue, that took them many months to fix, and then i have this.  I compete in iracing leagues, In a few hours, I race the last round, in a championship, where if I do well i win the championship.  Right now my headset doesn't work, i am having to reconfigure everything. I SPECIFICALLY TOLD MY HEADSET TO NOT UPDATE. yet i still have the problem, presumably because the windows app updated automatically.

I've never experienced such appalling treatment as I have as a customer of meta. They should be ashamed of themselves.  If I was this terrible at my job I'd have no customers and be fired. Disgusting. 

Yep, they went ahead and rolled out v68 despite having been advised about the bug. Shame 😞

Yep. Getting reports on a Discord channel I help run, and it's going to be an issue.

I get that Meta don't really understand the OpenXR toolkit, and probably don't have any experience of using it, plus the PC app is always treated like the unwanted child, however, that all being said, they were told this would happen and yet, still went ahead and rolled it out.

A large number of sim users, racers and drivers, and flyers, are all going to be negatively affected by this rollout.

It's bad optics, and bad policy. 

Something needs to be reviewed so this problem is not repeated in the future.

For a start, product managers need to listen to the needs of the customers, especially when those needs are so clearly stated in threads like this.

F- for this Meta.