I give up, this is a big hammer but should fix doc only changes MRs from not
triggering builds properly. We could technically try only build certain jobs
on doc only changes but I couldn't get it to work.
For one thing this applies the calibrated gyro and acceleromater bias
provided by the Reverb G2 controllers via the WMR protocol to
to the according sensor values of the controller. For another,
this applies the temperature mixing matrix in the same, partial way as
it is applied to the HMD. That is it currently disregards the polynomial
coefficiency nature - which is okay for the Reverb G2 as any temperature
dependant, non-constant coefficients in the mixing matrix seem to always
be 0 in the calibration data for it.
All this is, in theory, to reduce drifting. However for the Reverb G2 it
did not eliminate it completly, seemingly like for the HMD the
controllers were never temperature calibrated (controllers and HMD use
the same TDK/InvenSense ICM-20602 chip).
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Similar to the HP Reverb G2 controllers apply the rotations
provided by their calibration data.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
We can't take the IMU values of the Reverb G2 controller as is.
We need to compensate for how the IMU chip is oriented on the
hardware.
Similar to the WMR HMD the WMR controllers' firmware configuration
provides us with the transformations necessary to adjust the
controller orientations. So apply them to fix the orientation
issues.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Not only the sensor values from the HMD need to be transformed from WMR
to OpenXR but also the sensor values from the controllers. Therefore
restructuring the according code to be useable by both the WMR HMD and
WMR controller code.
No functional changes.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
This adds a fence signal + CPU wait on the compositor queue before destroying
the swapchain. It fixes a crash in the OpenXR CTS automated tests for D3D12.
