This matches the OpenXR usage: the array is the plural of the element type,
and the count is the singular element type plus "count" (usually CountOutput
because of the two-call idiom)
Includes fixes to other code to match API changes.
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>]"
This enables binding two different inputs to the same action, for example
/user/hand/left/input/select/click and /user/hand/left/trigger/click to
the same grab action.
Also takes care of using the correct timestamp of the input that is
responsible for the last overall value change.
Abandons the assumption that in oxr_system.xdevs[], index 0 is HMD,
1 is left controller, 2 is right controller.
Now to represent the dynamically assigned roles, oxr_system.role contains
the index for a device in oxr_system.xdevs[] for head, left and right.
This role assignment happens on the client side and currently can not be updated
from the server side.
Also adds an enum that device drivers set indicating allowed assignments
(many controllers are physically designed to be held in a specific hand).
This also adds support for configurations with only a HMD and a right controller.
This caused a action set to act as if it has been attached, one might say that
this commit fixes a overly attached action set.
Extreme programmed with Ryan Pavlik, which I also ~~stole~~ borrowed the header
comments from verbatim.
Action timestamps were missing this conversion to XrTime with time_state_monotonic_to_ts_ns()
which caused them to be out of sync with the predicted frame times and device "pose at" timestamps.
Fixes d62c2d2011
For any one action, multiple bindings may be suggested. The preferred/matched
input path depends on which binding is active.
Each bindings already stores a list of actions for which the suggested bindings
matched any of the input paths, just add a corresponding list *which* path matched.
