duplicate call to xrCreateInstance when using OpenComposite + Monado
#7905
Comments
emily-is-my-username
added a commit
to emily-is-my-username/Proton
that referenced
this issue
Jul 15, 2024
When using OpenComposite, both OpenVR and OpenXR functions will call the same underlying OpenXR loader. Because the OpenXR loader only supports a single active instance, `initialize_vr_data` currently fails because an OpenXR instance has already been initialized when XR extensions are queried. For SteamVR, the runtime already needs to be running for `xrCreateInstance` to succeed. To support both setups, this commit tries to query XR extensions before OpenVR initialization, but still defaults to the previous behavior if the first try was unsuccessful. Fix for: ValveSoftware#7905
emily-is-my-username
added a commit
to emily-is-my-username/Proton
that referenced
this issue
Sep 29, 2024
…itialize_vr_data` When using OpenComposite, both OpenVR and OpenXR functions may call the same underlying OpenXR loader. Because the OpenXR loader only supports a single active instance, `initialize_vr_data` currently fails as an OpenXR instance has already been initialized ath the time XR extensions are queried. This commit fixes the problem by cleaning up the temporary OpenVR context *before* initializing OpenXR instead of keeping it open until the end of the call. Fix for: ValveSoftware#7905
Plagman
pushed a commit
that referenced
this issue
Oct 3, 2024
…itialize_vr_data` Patch written by Emily <[email protected]> #8126 When using OpenComposite, both OpenVR and OpenXR functions may call the same underlying OpenXR loader. Because the OpenXR loader only supports a single active instance, `initialize_vr_data` currently fails as an OpenXR instance has already been initialized ath the time XR extensions are queried. This commit fixes the problem by cleaning up the temporary OpenVR context *before* initializing OpenXR instead of keeping it open until the end of the call. Fix for: #7905 Signed-off-by: Paul Gofman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, VR initialization in Proton seems to require OpenVR and thus SteamVR, even for OpenXR-only games, which complicates setup for other OpenXR runtimes such as Monado. One workaround (as suggested here) is using OpenComposite to bridge all OpenVR calls to the OpenXR runtime.
However, if OpenComposite uses the same openxr_loader library as Proton, VR initialization still fails with:
Loader does not support simultaneous XrInstances. There are two OpenXR instances active simultaneously, which is unsupported by the loader.As @eburema explained here and in the OpenComposite issue, that happens because of the order of operations in
steam_helper'sinitialize_vr_data: First, OpenVR is initialized, and the first OpenXR instance is created through OpenComposite, thenwineopenxr's__wineopenxr_get_extensions_internalis called, tries to create the second instance and triggers the error.This is easily fixed by cleaning up the OpenVR client before invoking the OpenXR loader, as the client is not used anymore and gets closed later in the function anyway.
There may be better ways to support other OpenXR runtimes, for example by requesting the XR extensions independently from OpenVR - directly from the OpenXR runtime (as suggested here), but I deliberately want to keep the scope as small as possible - this is not intended as a feature request for out-of-the-box Monado compatibility.
I also understand that this is not strictly an issue with Proton itself, but using OpenComposite is a useful workaround to run OpenXR games in Monado without changing the OpenVR / SteamVR specific parts of Proton.
OpenComposite issue:
Related Proton issues:
Fix:
initialize_vr_data#8126The text was updated successfully, but these errors were encountered: