Latest Oculus Beta version breaks OpenXR Toolkit

Известная проблема Meta Quest v68 ломает OpenXR Toolkit. Обновление Meta v68 вносит критическую ошибку в обработку вызова xrEnumerateInstanceExtensionProperties. Это соответствие совместимости с OpenXR Toolkit и API других уровней (OBS Mirror, OXRMC), что приводит к сбоям во многих приложениях (например, ATS/ETS, MSFS, iRacing) при использовании Link Cable через OpenXR. Основная причина Meta Runtime неправильно использует XR_ERROR_SIZE_INSUFFICIENT для допустимой идиомы с двумя вызовами, нарушающую спецификацию OpenXR 1.0 Spec §2.13. Обходной путь (временный), удалите обёртку CHECK_XRCMD() из send.cpp. Это позволяет обойти ложную ошибку.  Необходимое решение со стороны Мета должно быть направлено на проверку требований по охране окружающей среды в соответствии со спецификацией.  Информирование разработчиков API через Khronos/GitHub.  Предотвратить регрессию в нефтяных выпусках. Поддержка OpenXR QA в предварительной версии.

FDL: Σ-FDL::META-ERROR-AXIS::OPENXR-DISRUPTION  

With the hotfix, my version now is 68.0.0.474.361

kraszus,  can you give a little more info?   I'm also on the PTC version of both the Quest OS and the Meta Quest Link app and I'm still seeing Runtime version: 68.0.0.433.361 on the link app side which is the original version Meta released that has the OpenXR issue.   Is that the same runtime version you are seeing on the Meta Quest Link app PTC?  

8/2 Update #1: Oops nevermind I see it now: PTC now has this hotfix version: 68.0.0.474.361.   Testing now...

8/2 Update #2: I've confirmed now that this hotfix version of the Meta Quest Link app fixes the issue for us (our game is built in Unreal 4.27.2 and uses OpenXR).

And on top of that, the meta app, after it's update (more of a complete reinstall by the look of it), reset my preferences, and I found I was now set to 70Hz, and the slider was at 1.0x.

Be nice if this got mentioned in the update notes.

Microsoft Flight Simulator with OpenXR-Toolkit doesn't work either.

I wish it was possible to downgrade the meta software...

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.

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

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. 

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.