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.
Fixes error
/home/haagch-collabora/monado/src/xrt/drivers/survive/survive_driver.c:384:53: error: passing 'const union xrt_output_value *' to parameter of type 'union xrt_output_value *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
int ret = survive_controller_haptic_pulse(survive, value);
^~~~~
/home/haagch-collabora/monado/src/xrt/drivers/survive/survive_driver.c:340:89: note: passing argument to parameter 'value' here
survive_controller_haptic_pulse(struct survive_device *survive, union xrt_output_value *value)
Similar to how this was being done for SLAM.
It's significantly less jittery and still has a good response.
Smarter filters might benefit from raw measurements so the functionality can
be enabled again with a checkbox.
Hopefully this is an improvement and not just a rewrite. Some ideas were:
1. Keep poses in WMR space as much as possible.
2. Add an explicit function that precomputes a handful of transforms that allow
converting between WMR and OpenXR coordinates.
3. Make naming of variables in line with a relatively common T_A_B notation.
4. I wasn't able to figure out why `wmr_config_compute_pose` worked before,
in any case, hopefully the new notation convention helps understanding
why P_oxr_{acc,gyr} work.
Commit e41cc1eec3 added support for the XRT_INPUT_SIMPLE_AIM_POSE pose
input in the QWERTY driver. Unfortunately it didn't change the code that
identifies whether the pose for a controller or HMD is being read.
In the QWERTY driver, the hands are positioned relative to the HMD, so
if you move or rotate the HMD the hands stay in the same place
on-screen. Whether a pose lookup is multiplied by the HMD transform
depends on whether the pose being looked up is that of a controller.
Thus the aim pose would not be positioned relative to the HMD.
Previously the pose on the remote driver controllers would always have
the set pose and the valid-tracking flags set. Leaving the pose set
makes sense (you might want to track how your game behaves when a
controller looses tracking but still has a pose set, for example
tracking issues caused by occlusion) but it wasn't possible to test with
the pose marked as not being tracked.
Therefore this patch deactivates the tracking flags when the controller
is not marked as active.
In an Odyssey+, it seems that before the first IMU sample the frame timestamps
do not make sense and thus can make the SLAM system crash.
Also, this commit enables SLAM submission from start unless specified.
SLAM for WMR headsets now works "out of the box" :)
