Hi,

I have seen a few posts here about using the SDK via generic OpenXR interface rather than using the Unity or Unreal SDKs and see it should be possible.

We are in the process of implementing this for our engine which already supports OpenXR on other platforms.  We have also tried using the OpenXR tutorials to remove any doubt of incorrect API usage through our engine, specifically https://github.com/KhronosGroup/OpenXR-Tutorials  Chapter 2 example which creates an XrInstance.  

We have sideloaded the OpenXR Runtime Broker and that is showing "Snapdragon Spaces Services" installed and selected as the OpenXR runtime.

The call to xrCreateInstance is returning the error code XR_ERROR_INITIALIZATION_FAILED, which implies our XrInstanceCreateInfo structure contains a platform specific extension for a different platform. There are no API layers enabled and only 2 enabled extensions: XR_EXT_debug_utils XR_KHR_vulkan_enable

Is there any specific additional requirements to create a snapdragon spaces instance?  Our next step will be to look through the Unreal source to see if there is anything specific but if there were some pointers to get us there faster that would be helpful.

Thanks,

Richard.

I'm in New Zealand, I have had issues with my followup posts never showing up.  After posting they say they await moderation and then do not show.

Trying to connect via a standard OpenXR implementation but with the replaced libopenxr_loader.so and gotten us further.  We can now create an instance however creating an XrSession fails with XR_ERROR_INITIALIZATION_FAILED.  We also see the following error message in the log "glQueryContextImpl:1063 error 3006 (EGL_BAD_CONTEXT)".  Using this standard OpenXR approach we still see our activity as the main and we render our own OpenGL context on screen.  As far as I can tell this is how the StereoKit implementation works.

The question I have is about application life cycle, and if we should not launch our intent, but rather embed the "openxr_input_plugin", "device_access" and "older-runtime-compatibility" projects and set the launching intent to the SplashScreenActivity class.  These projects and corresponding activities seem to be in control of connecting to the headset and creating the wireless display connection.  It seems using this system would create the on phone trackpad controls and by modifying LaunchHelper.java we could launch our own activity.  The confusing part is that the SteroKit implementation does not seem to go down this route and instead launches its own activity.  The issue we are having with this approach is that the kotlin plugin for packaging fat aar files is failing which requires further investigation.

So should we focus on figuring out the cause of the session creation failure and run with our own custom UI rendering on the phone, or use the provided java classes/activities to handle connecting to the glasses and find out why packaging the supplied activities is failing?