OpenXR Development

When I try `xrGetCurrentInteractionProfile` for `/user/hand/left` on the quest (v1), I get `/interaction_profiles/oculus/touch_controller` (as expected).However, when I try to suggest a binding for the path `/user/hand/left/input/squeeze/value` with `xrSuggestInteractionProfileBindings`, I get `XR_ERROR_PATH_UNSUPPORTED`.The openXR spec shows that this binding _should_ be supported here: https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#_oculus_touch_controller_profile , and further, specifies that it _MUST_ be supported through this line: "A runtime must accept every valid binding in the allowlist though it is free to ignore any of them."But to be clear, I'm not concerned with "spec correctness" for its own sake- I simply can't access the grip input on quest 1 with openxr at all until this is fixed.Is it true that there are just _no_ openXR applications available for quest 1 which use the grip button? or am I missing something elsewhere?If this is a bug, who can

Oculus OpenXR Mobile SDK: https://developer.oculus.com/downloads/package/oculus-openxr-mobile-sdk/Prototype OpenXR Support for PC Development: https://developer.oculus.com/documentation/native/pc/dg-openxr/Please post your questions and issues with the OpenXR Framework in this forum for your fellow developers to see and answer - chances are these questions and issues will be shared! If you need extra eyes on an issue you're experiencing, please submit a ticket through https://developer.oculus.com/contact with the Issue Type "Development - OpenXR". We'll file a task on your behalf to the OpenXR team to take a look at your issue.

I'm working on a Mixed Reality library called StereoKit, and I'm currently in the process of porting it to Android/Quest. I've made a fair bit of progress, and the native component of my library does in fact compile and run on the Quest 2!However, my library is primarily consumed through C#, so now I'm working on loading up the library through Xamarin. I've got this working without OpenXR for flatscreen phone devices, but I'm still trying to figure out how to get this part working on the Quest. I'm currently at the state when OpenXR seems to initialize properly and my application begins to run, but OpenXR never transitions from the IDLE state to the READY state. I do get this message from the log 'xrCreateSession: Activity is not yet in the ready state.' which I'm guessing might be the culprit, but I'm uncertain what would be causing this or how to fix it. From JNI, I initialize everything after the window is initialized, which works great. Under Xamarin, I initialize after a SurfaceVi

I'm using a quest with link, through the oculus runtime, which opened steamVR, using steamVR's OpenXR runtime (if there's a way to more directly use a quest->link->oculus->openXR runtime, I'd appreciate learning how).As I said: `xrWaitFrame` logs `xrWaitFrame: would have blocked, skipping frame instead` for every frame. This results in the HMD displaying steamVR's "Next Up: MyAppName" indefinitely (though the monitor rendering continues perfectly, even correctly tracking the HMD position).When I use a valve index (so, index->steamVR->openXR) I do not get this problem, and the application works perfectly. This leads me to believe there is something strange with the oculus runtime.The openXR documentation says that xrWaitFrame should block if the frame is being requested more than once per frame, and if it's being requested insufficiently per frame. Is there external timing required here? I was under the assumption that xrWaitFrame itself should be the driver of frame timi

HelloWe are looking for developers who can change XR input to Steam VR input on the Unity engine so that the game works on Valve Index and HTC VIVE.If you are interested, please contact me at: admin@source-byte.com

I've built for quest with the oculus openxr sdk, have explicitly loaded libopenxr_loader, got procaddr for xrInitializeLoaderKHR, it isn't null, I initialized the loader, but then it fails with XrResult = -1 on xrCreateInstance.The only way I've been able to debug is with logcat + printf. (I can print a message before xrCreateInstance and one after, and I only see the former). If there is some way to debug this, I would love to hear it (I've asked that question directly in another thread with no responses).Here is my backtrace, which isn't very helpful: (the "assert(0)" is what happens when xrCreateInstance fails)08-16 15:00:39.390 23044 23044 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***08-16 15:00:39.390 23044 23044 F DEBUG   : Build fingerprint: 'oculus/vr_monterey/monterey:7.1.1/NGI77B/821490.13210.0:user/release-keys'08-16 15:00:39.390 23044 23044 F DEBUG   : Revision: '0'08-16 15:00:39.390 23044 23044 F DEBUG  &nbsp

The xrLocateSpace function sometimes takes literally forever (ie. it never returns), making my application appear to have hung. Sometimes the application will run correctly for a second or two before this happens.

Using the Oculus runtime, xrConvertWin32PerformanceCounterToTimeKHR() appears to have a bug (at least on my system).QueryPerformanceFrequency() returns 10000000 (1e7) on my machine, while XrTime is in nanoseconds. So intervals expressed in XrDuration should always be exactly 100 times larger than the corresponding differences between values reported by QueryPerformanceCounter().On my machine, instead, intervals computed from the XrTime values given by xrConvertWin32PerformanceCounterToTimeKHR() are always exactly 10 times larger than the differences in QPC values.The bug might have gone unnoticed because the absolute value of XrTime computed by xrConvertWin32PerformanceCounterToTimeKHR() is more or less 100 times larger than the QPC value (something like 99.9945 at application start), but when you compute differences between successive calls it's clear that the relative times are off by a factor of 10.The same function works correctly with the Microsoft WMR runtime:

Hi.  I am a software engineer but not working in VR.  Lately, I've been using a Quest a lot for my hobby of simracing (iracing).  VR for iRacing is great, but there is one weak area.  Third party overlays are a very popular and important thing in the iRacing community, Google "best iracing overlays" to get more of an idea.  Unfortunately, all of these apps are tricky in VR generally and more so for Oculus specifically.  Although iRacing has native VR support for Oculus, none of the third party overlays do at this time.  The current practice is to use browser windows.  A user must launch a browser(s) and the overlay software provides an endpoint that implements an overlay item (2D), which the user provides a URL for to the browser.  On Oculus, the user must go through the process of manually positioning the browser windows, usually taking multiple iterations to get right, and pinning them.  The user must do this for every racing session.