Tests do not support returning XR_ERROR_FORM_FACTOR_UNAVAILABLE for xrGetSystem

[aidanhowie19]

Hi,

I am writing an OpenXR runtime to support a remotely connected device. The runtime will return XR_ERROR_FORM_FACTOR_UNAVAILABLE from xrGetSystem until the remote device has connected and passed it's relevant information (Rendering Information and Controller Type). Once established, this will return XR_SUCCESS, if the system information is supported, to continue to create the session and begin rendering. This design has been influenced from the specification which states: "If the form factor is supported but temporarily unavailable, xrGetSystem must return XR_ERROR_FORM_FACTOR_UNAVAILABLE. A runtime may return XR_SUCCESS on a subsequent call for a form factor it previously returned XR_ERROR_FORM_FACTOR_UNAVAILABLE. For example, connecting or warming up hardware might cause an unavailable form factor to become available.".

Currently, the conformance tests do not support this and instead fail on the first return of XR_ERROR_FORM_FACTOR_UNAVAILABLE. Could the tests instead wait and retry xrGetSystem after a short period of time? This could be tried for a period of time, say 30s, and fail afterwards.

Thanks in advance,

Aidan

[rpavlik-bot]

An issue (number 1947) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#1947 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

[rpavlik]

We are looking into it, good catch. You're right that your behavior is definitely permitted by the spec. One thing that was brought up, is that not all applications will retry, so if you always return not available to the first call, there may still be compatibility problems. (Yes, you found what seems in hindsight to be a design flaw in the spec 🤦) I'm not sure about the details of your implementation, but you might consider having a long running process in the background do connecting ahead of time, or alternatively cache the most recent system data so you can return success on the first get system call as long as you're actually in contact. (I think you're actually allowed to block in that call too, as another alternative)

[aidanhowie19]

Thanks for the reply and following up on this issue. My main target applications will often be built with Unity which I already have a feature request open for to support this. For other applications which do not currently support this functionality, I will look into some options for users to force a fallback when using my runtime. Since my runtime supports multiple different remotely connection devices (HoloLens 2, Quest 2 etc.), I cannot assume a single default.

[rpavlik]

The working group is wondering whether you have filed the paperwork, etc to be an official adopter and be able to submit conformance results. Normally per the adopter agreement, this would fall under your responsibilities as a "bug in the CTS" or as part of porting. (See section 6, "Conformance Test Source and Porting".) The WG may have capacity to take this request on through a contractor but wants to confirm you have contributed to the funds that were used to hire the contractor.

See the agreement/process doc here https://www.khronos.org/files/conformance_procedures.pdf and further details on becoming an adopter at https://www.khronos.org/conformance/adopters/

[aidanhowie19]

My company is in the process of filling out the paperwork and will submit hopefully in the near future. Since OpenXR is a large spec, we have began development in parallel to have a conformant runtime when the paperwork and payment are complete.

I was unaware of the "Conformance Test Source and Porting" section you have indicated above. If my suggestion is deemed acceptable, I am happy to change the source code and submit this in the Waiver Statement of our Submission Package.

[rpavlik]

The change needed has been shipped in the latest CTS release, 1.0.29.0: "Improvement: Optionally poll xrGetSystem before running test cases."

You do need to pass a command line argument to enable this behavior, but it is conformant to do so.