I'm on Oculus beta branch and yesterday's update has broken compatibility of the OpenXR Toolkit with many games. Have had to revert back to previous version.
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.
Absolutely agree with all of your post but your last sentence couldn’t be more accurate. I mean I’ve had my Quest 2 for probably 2 years and now a Quest 3 and it STILL says I’m not compatible (7900XTX/5800X3D) and they can’t even fix it to work properly with HDR, I mean how hard is that? Literally the only program/app that doesn’t
I just got my Quest 3 last month and the Beta Branch gave me the options I needed but then breaks the only API I use..
Sorry for soap boxing on your post, but one last thing also related. I beta test for AMD and am currently trying to get Foveated Rendering for DX11 added(OpenXR feature) Nvidia can do it fine but AMD only currently supports it in DX112. So I’m literally trying to help a whole myriad of users get a performance features for an API that is now broken.
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…
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.
