Prior to this, the existing `xrt_device_name` entry
`XRT_DEVICE_HAND_INTERACTION` was re-used for `XR_EXT_hand_interaction`
bindings however this `xrt_device_name` is used to look up the older
hand-interaction profile `XR_MSFT_hand_interaction`. This commit adds a new
`xrt_device_name` entry dedicated for `XR_EXT_hand_interaction` and fixes the
incorrect profile look for suggested bindings during runtime.
Currently there does not seem to be a way to access the SteamVR
dashboard with the Reverb G2 (controllers).
This adds a binding that allows to use the system/home button to
open the SteamVR dashboard.
Remark: In the OpenXR 1.0 spec there is no binding for
/input/system in XR_EXT_hp_mixed_reality_controller. However on Windows
this button would supposedly allow to (indirectly?) access the
SteamVR dashboard. (Which I can't confirm myself, as I don't have
access to a Windows OS right now.) To properly support system buttons in
OpenXR introduce XR_MNDX_system_buttons.
Co-authored-by: Jakob Bornecrantz <jakob@collabora.com>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
A requirement of interaction profile (extensions) specify that some/all
actions must be supported by all other profiles. This commit
modifies the binding generation to support data-inheritance in bindings.json:
* Adds support for profiles in bindings.json to inherit & override other profiles
* Adds a new concept of virtual profiles for profile like extensions
(e.g. `XR_EXT_palm_pose`) which do not define a profile themselves but
require their newly defined actions to be supported by all profiles.
* Generates verify bindings functions which only check extensions actions
only if the extension is enabled.
Add an optional switch -s or --steamvr to steamvr_profiles.py, which enables
a different naming scheme for the "controller_type" field in the generated
SteamVR profile json files.
If the switch is provided and an interaction profile in bindings.json
provides the optional new property "steamvr_controllertype", that property
will be used for the "controller_type" field of the written out .json,
instead of the regular auto-generated name.
This allows to generate json files which use controller_type names normally
used by SteamVR, so Monado provided controllers are mapped to the same
OpenXR interaction profiles that SteamVR would normally map them to.
E.g., the standard controller_type for Oculus touch controllers used by
SteamVR is "oculus_touch" instead of Monado's "monado_oculus_touch_controller".
That in turn allows OpenXR clients to use the SteamVR/OpenXR runtime to
access controllers provided by Monado's SteamVR driver plugin. Without such
compatible json files, only standard OpenVR clients can use controllers
exposed by Monado's SteamVR driver by default, but not OpenXR clients.
Tested with an Oculus Rift CV-1, and shown to now enable OpenXR clients
to make full use of the Oculus touch controllers.
The mappings for controllers other than Oculus Touch are derived from
SteamVR log output, but not actually tested due to lack of suitable hw.
Per discussion for the merge request, we enable this '-s' flag by
default in the make file for SteamVR style naming scheme.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
When using the Monado SteamVR driver plugin together with an Oculus
Rift CV-1 and Oculus touch controllers, the grip / squeeze sensors
(e.g., /user/hand/left/input/squeeze/value) and the thumbsticks did not
work.
This because SteamVR expects those controls to be exposed under a
different path than what one would use for OpenXR, e.g.,
OpenXR /input/squeeze --> SteamVR /input/grip and
OpenXR /input/thumbstick --> SteamVR /input/joystick
The same is true for some other controller types.
To fix this, add some new code for input subpath substitution, to perform
this remapping, depending on binding type:
For type "trigger": Substitute squeeze with grip
For type "joystick": Substitute thumbstick with joystick
For rare controller types where this would be the wrong thing to do,
e.g., Valve Index (for type "joystick", needs the path to remain
"thumbstick" as before), and for special cases not covered, we add
a new optional parameter 'steamvr_path' which can be used in bindings.json
to handle such mismatches in path flexibly to allow a dedicated path
name for SteamVR, overriding the regular "OpenXR style" input path or
auto-substituted path is if the parameter is omitted.
This makes the Oculus Rift CV-1 touch controllers fully work under SteamVR.
I haven't tested this with other controllers, as I only have Oculus
controllers for testing atm. But after reading about the HTC Vive controllers,
i did add a "steamvr_path" override for /input/menu -> /input/application_menu.
Cfe. https://github.com/ValveSoftware/openvr/wiki/IVRDriverInput-Overview
Also, a minor typo fix in steamvr_profiles.py as a bonus.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
We now have a cmake-format config file.
We no longer use list variables for sources, instead using
target_sources when we need to add, in accordance with current
best practice. (This makes it a lot easier to edit too.) There's no more
include_directories(), add_definitions(), or other gently-deprecated
directory-scoped commands, nor any CMake scripts that include
a parent directory reference (named targets instead)
In our model we have a "subpath" for each hardware input like "/input/trackpad".
Each of these hardware inputs has "features" like "click", "touch", "position", "force".
Ideally each of these "features" is bound to some monado input in the "monado_bindings" dict
but this is not required. bindings.json will know about hardware features even if we don't bind them (yet).
For each of these features bindings.py generates a group of related paths for a single monado binding:
For a monado input XRT_INPUT_???_TRACKPAD these paths would be generated:
/user/hand/left/input/trackpad/x
/user/hand/left/input/trackpad/y
/user/hand/left/input/trackpad
The generated files should be in auxiliary/bindings/*.{c,h}. For this to work
meson.build has to be in the bindings/ subdir:
https://github.com/mesonbuild/meson/issues/2320
Move CMakeLists.txt there too for some consistency.
Also fixes the previous include hack.
