The STOPPING state has two possible follow up paths:
STOPPING -> IDLE -> READY
STOPPING -> IDLE -> EXITING
After EXITING, the application must call xrDestroySession; there is no meaningful
session state after EXITING.
To go to the READY state again, the application should first create a new session.
Applications that are lazy and drain the entire event queue and only handle
the last encountered state would be affected by "skipping" the EXITING state.
XR_KHR_vulkan_enable2:
physicalDevice VkPhysicalDevice must match the device specified by xrGetVulkanGraphicsDevice2KHR
XR_KHR_vulkan_enable:
physicalDevice VkPhysicalDevice must match the device specified by xrGetVulkanGraphicsDeviceKHR
XR_KHR_vulkan_enable:
Add a trivial check that xrGetVulkanGraphicsDeviceKHR is called before xrCreateSession.
(our cached suggested device will be XR_NULL_HANDLE if it has not been called).
The XR_KHR_vulkan_enable2 code path already contains this check.
Subaction paths are the /user/X/Y part of the full path describing the input source/device.
"Subaction paths are a mechanism that enables applications to use the same action name and handle on multiple devices. Applications can query action state using subaction paths that differentiate data coming from each device."
Subpaths, are the input or output specific part of the full path, e.g.
"Each input source path must match the following pattern: …/input/<identifier>[_<location>][/<component>]"
hand_origin is confusing because it implies it is the origin of the coordinate system the hand is in.
It actually is the hand pose in the "global" coordinate system.
Rename XRT_FEATURE_OPENXR_LAYER_EQUIRECT_LEGACY to XRT_FEATURE_OPENXR_LAYER_EQUIRECT1.
Use correct define in verify_equirect1_layer function.
Rename equirect to equirect1.
meson: enable equirect1 by default.
The compositor now moves immediately to visible/focused when polling.
The state tracker will generate relevant openxr state changes once the session is synchronized.
Properly working alternative to e03ee48dce (reverted in e7643de8db)
The application synchronizes its frame loop by "by calling xrWaitFrame,
xrBeginFrame and xrEndFrame in a loop."
Applications can discard frames by not calling xrEndFrame. If initial
frames are discarded, we should not consider the frame loop synchronized.
Previously a sequence like
xrBeginFrame, xrWaitFrame, xrBeginFrame, xrWaitFrame, xrPollEvent, xrBeginFrame
failed because xrPollEvent the compositor emitted transitions to visible
and focused but they were not emitted in the state tracker, because the
oxr session had not internally tranisitioned to the synchronized state.
