OpenXR: xrSyncActions, and related processes, should be limited to focused state.

[BastiaanOlij]

Tested versions

• Reproducible in 4.5.beta (46c495c)

System information

Any OpenXR system (tested on Windows 11, Quest over steam link)

Issue description

This is currently a silent error that we ran into by accident but is now causing a real issue.

After the OpenXR session is created we call xrSyncActions each frame. This function however is designed to only be called when the OpenXR session status is set to focused. It returns a XR_SESSION_NOT_FOCUSED return status but as this is not considered an error, this is ignored.

As we continue processing action related things we run into a number of minor behavioural problems:

1. We're processing actions without an updated action state. The result of this is somewhat undefined. Best case scenario is that we just fetch the latest state. Worst case scenario is that the state indicates a loss of controller data with game breaking results.
2. We retrieve controller binding information too early and thus obtain the wrong information. As no XR_TYPE_EVENT_DATA_INTERACTION_PROFILE_CHANGED event may be issued, we don't capture the update. This does not have an effect on how the game operates, but may present misleading binding information.
3. For PR OpenXR: Add support for render models extension #107388 the same applies for the XR_TYPE_EVENT_DATA_INTERACTION_RENDER_MODELS_CHANGED_EXT event, which turned out to be a breaking issue.

Fixing this will result in a behaviour change as the 3 points up above will be fixed and this could effect users who've found workarounds to these issues.

Steps to reproduce

Behaviour 1 can be reproduced with any XR project as long as you output input states and take the headset of mid game.

Behaviour 2 can be reproduced with SteamVR using https://github.com/godotengine/godot-demo-projects/tree/master/xr/openxr_hand_tracking_demo by making sure controllers are tracking before the demo starts. I've also seen this behavior on PICO devices.

Behaviour 3 can be reproduce with the logic in #107388 with its workaround solution removed.

Minimal reproduction project (MRP)

See projects in https://github.com/godotengine/godot-demo-projects/tree/master/xr

[BastiaanOlij]

After a lot of discussions with a couple of people in the OpenXR group there is some further clarity on these issues.

First, xrSyncActions is supposed to be run every frame as soon as the session is created. XR_SESSION_NOT_FOCUSED is returned purely as information. This gives xrSyncActions the chance to clear controller state when we loose focus. This means "behaviour 1" as described above, is intended behaviour.

Users should correctly react to the state change, by reacting to the OpenXRInterface.session_visible signal and ensure their game behaves correctly.

Behaviour 2 lies a little more difficult. The OpenXR spec does not define any dependency that governs when it's safe to call xrGetCurrentInteractionProfile, it should be safe to call this as soon as the session reaches the synchronised state, and we thus seem to be doing to correct thing.
So the behaviour witnessed here might indicate an issue on the runtime side that needs to be investigated further.
However, it is possible runtimes don't have access to this data until further on, and it is possible runtimes omit to providing the XR_TYPE_EVENT_DATA_INTERACTION_PROFILE_CHANGED event in this scenario.

There is ground for moving checking xrGetCurrentInteractionProfile to after xrSyncActions and making things a little more robust.

Behaviour 3 seems to indicate a bug on the runtime side and thus should not require a change in our approach.