Found by clang-15.
src/xrt/auxiliary/math/m_permutation.c:133:15: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
m_do_the_thing()
^
void
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>
Use factory data for SLAM calibration. Sensor rotations are off in most calib
files we saw (or at least we can't figure something better) so this won't work
very well. It's still necessary to properly calibrate the headset for good
results but at least now something works without that step.
Port across the Oculus Rift S driver from OpenHMD as a native
Monado driver.
This is mostly the same as the OpenHMD 3DOF driver, with
slightly better HMD distortion correction, various small
fixes, some capsense touch detection support.
Controller poses are rotated 40° to match grip pose.
* Removed depthai_tracked_device - now you create a "SLAM" device, plug any frameserver into it and you're done
* Consolidated the grayscale frameservers into just one that gives you SLAM sinks
* Allows for different framerates and half-size for ov9282s
* Added debug frame sinks
* Added the ability to wait at startup for a number of frames for the streams to stabilize before submitting them to SLAM
By ensuring imgui.ini exists.
Also enabled u_config_json_open_or_create_file for Windows as this OS has an
implementation of u_file_get_path_in_config_dir available now.
Add a way to pass in extra information about camera views, this new
struct is merged with the old image boundary information struct.
Co-authored-by: Moses Turner <moses@collabora.com>
Co-authored-by: Jakob Bornecrantz <jakob@collabora.com>
This solves a problem where OpenXR timestamps could become invalid
(negative) in certain circumstances:
The timestamps that the OpenXR state tracker returned were offset such
that they appeared to start at OpenXR application startup time.
However monado-service is a long running service using system timestamps.
Because of this, if monado-service started work using a system timestamp
acquired before an OpenXR application started, then this system timestamp
could not be converted into an OpenXR without becoming invalid.
With this change, the OpenXR timestamps for OpenXR applications are offset
such that they appear to start at monado-service startup time instead.
As a side effect, all OpenXR applications connected to the same
monado-service instance will receive timestamps from the same domain.
Use a sink in the middle of the stream to correct for v4l2 timestamps with
hardware timestamps to monotonic clock.
This sink, together with other utilities related to data streaming, lives in a
new vive_source entity, with similar functionality to wmr_source or rs_source.
The vive_source lifetime is managed by the builder xfctx, which prevents
deallocation dependencies between vive_device and the v4l2_fs to cause segfaults.
