I am also dropping this question here in case someone already got a bit further with setting up a OpenXR Client for CloudXR (instead of OpenVR)
In Order to use later features of the Meta Quest 3 of the OpenXR Api we are trying to move the sample from OpenVR to OpenXR but always end up with a crash. We have noticed the same behavior for CloudXR 3.2 as well as 4.0:
“I am currently trying to build a CloudXR client based on OpenXR by integrating the CloudXR functionality into the hello_xr sample from the OpenXR SDK.
I am currently having an issue with the following error:
2024-09-19 13:01:04.669 11502-11588 libc com.nvidia.cloudxr.ovr A Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7bbcbfe6b8 in tid 11588 (Thread-3), pid 11502 (dia.cloudxr.ovr)
This occurs when calling cxrReleaseFrame (after I have previously called cxrLatchFrame). If I call cxrReleaseFrame without previously calling cxrLatchFrame, the error does not occur.
The same error also occurs when calling cxrDestroyReceiver (after I have previously called cxrLatchFrame). If I call cxrDestroyReceiver without previously calling cxrLatchFrame, the error does not occur.
The error disappears if I remove the following line from the CMakeLists.txt:
target_link_libraries(hello_xr PRIVATE openxr-gfxwrapper)
Unfortunately, I need the openxr-gfxwrapper to render with OpenXR.
My question is: How can the mere addition of the openxr-gfxwrapper lead to a segmentation fault in the CloudXR functions cxrReleaseFrame and cxrDestroyReceiver?”
Anybody out there that had more success in moving to OpenXR on the client side?