-
-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Khronos' OpenXR loader from Maven when supported #1405
base: main
Are you sure you want to change the base?
Conversation
Note that this requires firmware v62+ in Meta devices. It's easy to check that in OpenXR but it's likely too late. I'd love to have some "external" mechanism to prevent/filter out Wolvic from executing depending on the firmware version. v62 is from February so perhaps a bit risky to enable it in a release in the following moths. |
b461ff6
to
73f1112
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be more explicit in the commit message that this change breaks Wolvic in Meta platforms <v62.
73f1112
to
1c5db5a
Compare
1c5db5a
to
c21bae4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message of the second commit is incomplete:
"Should the test fail, a dialog with a text asking user to upgrade the" ....
c21bae4
to
38ca5cc
Compare
Good catch, updated. |
38ca5cc
to
2eec227
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In quest there is a system window that appears before showing Wolvic's logo. I doesn't show for too long, but it's clearly noticeable.
In other systems (eg, Pico) this window it's not shown, though.
Do you think that's a blocker? |
I wouldn't say it's a blocker to merge it in main, but I wouldn't select for any stable release without a solution for this issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I approve the change as it is now, but we should file a bug about the initial (void) window launched by the Control Version activity; I'd rather make it not visible, or something like that.
0f60c0b
to
66e5e0b
Compare
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own). More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo. So far this option is now available for the following flavors: * Meta Quest2, Quest3, QuestPro (requires firmware v62+) * Lynx R1 * Magic Leap 2 It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK. This change BREAKS Meta builds for OS firmwares <v62 because as mentioned, the Khronos loader is not available until v62. Fixes #1394
This new activity becomes the new MAIN activity, so it'll be launched before anything else including the VRBrowserActivity. It'll perform an OS version check. On success it'll invoke the VRBrowserActivity. Should the test fail, a dialog with a text asking user to upgrade the OS will be shown and Wolvic will refuse to start. So far the test is only performed for Meta builds (because the Khronos OpenXR loader is only available in v62+ VROS. Nevertheless it could be easily extended to other flavours. I've verified that it works as expected in: Pico4, Quest2, HVR, VisionGlass, Lenovo VRX, LynxR1 and the NoAPI flavour.
24b42fe
to
c55dba9
Compare
Most of the platforms used to distribute their own implementations/builds of the OpenXR loader. It was traditionally part of the propietary SDKs distributed by vendors. As they were under an EULA we had to keep them in a private repository only available to core devs (obviously any other external dev could download them on their own).
More recently, and driven by the AOSP flavor effort, we started to build the Khronos OpenXR loader from sources. Fortunatelly we got a well documented report explaining how to use the loader directly from the central Maven repository. This greatly simplifies the build process and also improves the open-source feel of the project by reducing our deps with the third-party repo.
So far this option is now available for the following flavors:
It does not work for neither HVR, nor SnapdragonSpaces based devices nor Pico. For these ones we still need to rely on the loader from the SDK.
Fixes #1394