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 timing.
predictedDisplayTime is 78 hours after xrConvertWin32PerformanceCounterToTimeKHR
xrConvertWin32PerformanceCounterToTimeKHR (with the performance counter returned by QueryPerformanceCounter) returns a time that is roughly the amount of time since the application started. On the other hand, xrWaitFrame returns a time in predictedDisplayTime that is roughly 78 hours later.
I assume this is a bug in SteamVR. I don't know if that is the cause of the "xrWaitFrame: would have blocked, skipping frame instead" spam every frame, and the fact that nothing is drawn, but it would make sense if it is choosing not to block for 78 hours.
To use the Oculus OpenXR runtime instead of the SteamVR OpenXR runtime, open Registry Editor and change the key from <steam folder>\SteamApps\common\SteamVR\steamxr_win64.json to C:\Program Files\Oculus\Support\oculus-runtime\oculus_openxr_64.json
Of course, the Oculus OpenXR runtime is equally full of bugs, or at least it was the last time I tested it, so I have no way of continuing OpenXR development.