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.
Implement support for SteamVR's Lighthouse driver (on Linux).
Only tested/works with the OG Vive and Vive wands, but adding new
device support should be simple.
While in the Monado debug GUI the squeeze trigger is detected fine and
it is also listed in the SteamVR "Test Controller" page, pushing the
squeeze trigger would not be detected in SteamVR.
Fixing this by not just populating the xrt_inputs squeeze click but also
the squeeze value.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
By using an extra, final entry in the according inputs enum instead
of using a hard coded number it should be slightly safer and easier
to verify that the to be allocated inputs array is of correct size.
No functional change.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
SteamVR requires the serial number to be set. Otherwise after creating
the controller it will fail to activate it.
Before:
...
monado: Creating Controller WMR Left Controller
monado: Using Monado Controller profile
monado: Render model based on Monado: locator_one_sided
monado: get controller serial number:
Driver 'monado' attempted to add tracked device with no serial number
monado: Added left Controller: WMR Left Controller
monado: Creating Controller WMR Right Controller
monado: Using Monado Controller profile
monado: Render model based on Monado: locator_one_sided
monado: get controller serial number:
Driver 'monado' attempted to add tracked device with no serial number
monado: Added right Controller: WMR Right Controller
...
After:
monado: Creating Controller WMR Left Controller
monado: Using Monado Controller profile
monado: Render model based on Monado: locator_one_sided
monado: get controller serial number: Left Controller
Driver 'monado' started activation of tracked device with serial number 'Left Controller'
monado: Added left Controller: WMR Left Controller
monado: Creating Controller WMR Right Controller
monado: Using Monado Controller profile
monado: Render model based on Monado: locator_one_sided
monado: get controller serial number: Right Controller
Driver 'monado' started activation of tracked device with serial number 'Right Controller'
monado: Added right Controller: WMR Right Controller
With this change the HP Reverb G2 controller is recognized and activated
fine in SteamVR for me. "Active Controller" nows says:
"monado_hp_mixed_reality_controller". The SteamVR controller test page
now works and recognizes button presses. The controllers can also
(kind of) be used in the home environment.
Several issues still exist to be fully useable:
* middle finger button not recognized in the SteamVR test page
(all other buttons seem to work)
* high gyro drift
* no positional tracking
The serial is set to "Left Controller" and "Right Controller" for now,
just like for the Rift S controller. This should probably be updated to
a proper serial number once read_controller_config() can parse it from
the firmware.
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Store controller calibration block into a cache file and
use that if available, to save time on subsequent startups
Re-disable reading of extra firmware blocks, accidentally
left enabled during recent controller/connection splitup
With the Reverb G2 controllers connected to the Linux host system via
Bluetooth the following segmentation fault occurs for me when starting
SteamVR with the SteamVR-Monado plugin installed:
```
$ gdb ...
...
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x00007f82de21bac7 in CDeviceDriver_Monado_Controller::RunFrame (this=0x7f82bc610e40)
at /home/linus/dev-priv/vr/monado/src/xrt/state_trackers/steamvr_drv/ovrd_driver.cpp:966
#2 0x00007f82de218b5d in CServerDriver_Monado::RunFrame (this=0x7f82de7c6ca0 <g_serverDriverMonado>)
at /home/linus/dev-priv/vr/monado/src/xrt/state_trackers/steamvr_drv/ovrd_driver.cpp:1574
#3 0x00000000004b7a77 in ?? ()
#4 0x0000000000000000 in ?? ()
(gdb) l /home/linus/dev-priv/vr/monado/src/xrt/state_trackers/steamvr_drv/ovrd_driver.cpp:966
959 if (m_xdev->hand_tracking_supported && m_skeletal_input_control.control_handle) {
960 vr::VRBoneTransform_t bone_transforms[OPENVR_BONE_COUNT];
961
962 timepoint_ns now_ns = os_monotonic_get_ns();
963 struct xrt_hand_joint_set out_joint_set_value;
964 uint64_t out_timestamp_ns;
965
966 m_xdev->get_hand_tracking(m_xdev,
967 m_hand == XRT_HAND_LEFT ? XRT_INPUT_GENERIC_HAND_TRACKING_LEFT
968 : XRT_INPUT_GENERIC_HAND_TRACKING_RIGHT,
969 now_ns, &out_joint_set_value, &out_timestamp_ns);
```
This happens because the "m_xdev->hand_tracking_supported" flag is set
but m_xdev->get_hand_tracking() is not implemented for WMR controllers.
Fixing this crash by setting hand_tracking_supported to false for
WMR controllers for now until get_hand_tracking() is implemented.
Link: https://gitlab.freedesktop.org/monado/monado/-/issues/251
Fixes: c4db3dfccc ("d/wmr: Add basic Reverb (G1, Bluetooth) motion controller support.")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
The swapchain code was creating a whole bunch of samplers, two for each image.
The thought was that samplers might depend on format, but this was not the
case. So just add a few common ones on the render_resources structs and use
them everywhere. Also fixes the bleeding distortion problem.
The type "uint" doesn't seem to exist on some platforms at least
(for example alpine linux), and it's only used in a single file,
so it seems like a good idea to change the two uses to "uint32_t".
Closes#258
This is due to the use of `${SDL2_LIBRARIES}` over `SDL2::SDL2`.
On some 'old' OSes such as Ubuntu 20.04, the SDL2 CMake config does
not set an SDL2:SDL2 target but rather defines SDL2_LIBRARIES and
SDL2_INCLUDE_DIRS variables.
This patch creates an SDL2::SDL2 target, if not already set, based on
those 2 variables.
Fix the following warning:
sdl_program.cpp(25): warning C4566: character represented by universal-character-name '\u2603' cannot be represented in the current code page (1252)
We would leak frame_id and active_wait_frames increment that would cause bad
states where we hadn't fully waited but would allow xrBeginFrame to complete.
Also improve error handling so that on error conditions the semaphore is
properly decremented and the application can call xrWaitFrame again.
This was caused by unreal doing something like this:
* xrBeginFrame <-- Error
* xrWaitFrame
* xrBeginFrame
* xrEndFrame
* Called at the same time:
* xrWaitFrame
* xrBeginFrame <-- Would get state from non-completed xrWaitFrame
Switch the device name and input/binding mappings for
Odyssey+ controllers to differentiate them from OG WMR
controllers, allowing applications to load the correct
controller model
Add a 100ms timeout for firmware reads from the HMD,
and error out if it takes longer. Fixes problems
sometimes waiting forever on my G2 when it gets
into a bad state.
Add macros for logging hexdumps of memory blocks to help
with driver development. Only macros for trace and debug
level logging are provided, as noone should be logging
hexdumps except for development.
Reuse MonadoView when "Display over other apps" is enabled. Move surface
creation logic to compositor for consistency. With this approach, compositor
implementer controls the way surface is created.
In its original call location, this diagnostic/warning function gets
called for each composition cycle even for client frames which have
not yet been delivered for display, because the frames target display
time "XrFrameEndInfo frameEndInfo.displayTime" (as provided by the
OpenXR client) has not been reached yet. Iow. if a OpenXR client
specifies a target frameEndInfo.displayTime in the future, to request
frame presentation in the future, this will cause a flood of false
"Frame late ..." messages by the compositor, despite nothing being
wrong with the timing, until the frame is actually delivered.
E.g., if frameEndInfo.displayTime is 1 second in the future, we'll
get this for each client xrEndFrame() invocation:
WARN [log_frame_time_diff] Frame late by 11.11ms!
WARN [log_frame_time_diff] Frame late by 22.22ms!
... another 87 like these ...
WARN [log_frame_time_diff] Frame late by 988.43ms!
I think what we want is to only check client frames that are actually
delivered the first time by multi_compositor_deliver_any_frames() for
initial display in the current compositor work cycle, and then report
if this first frame display onset was not on or close to the OpenXR
client requested frameEndInfo.displayTime, but too early or too late,
in violation of the clients wishes.
Moving the call check and call of log_frame_time_diff() achieves this
and gives meaningful debug output.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
This allows to use the metrics logging in "streaming mode" where
records are written out with low delay, e.g., into a Unix fifo
file / pipe for live consumption by some tracing or recording
application.
XRT_METRICS_EARLY_FLUSH=true enables this "streaming mode".
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Does not do anything yet within Monado, but documents how to parse
button state of left headphone volume up/down buttons and right
headphone microphone mute button.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
1. Bump Kotlin version to 1.7.10.
2. Bump Hilt version to 2.45.
3. Add implementation of lifecycle-viewmodel-ktx dependency explicitly
to fix duplicate class error.
Signed-off-by: utzcoz <utzcoz@outlook.com>
And move it to an internal struct instead. Better to keep it internal to the
prober as it was only used for the bluetooth probing. And there was a function
that applications should use to get strings from xrt_prober_device.
With the SLAM_OPENVR_GROUNDTRUTH_DEVICE we can select a device (HMD, right/left
controller, vive tracker) to use as the groundtruth provider for a SLAM tracker.
This is useful to record euroc datasets with lighthouse groundtruth.
The pulse 0xFD of the report 0x25 comes at 54hz and thus we are assuming its
timestamp are the camera frame timestamps. However, it seems that this report
stops coming when the lighthouses are enabled and instead we get a 0x28 report.
This commit silently handles the 0x28 instead of throwing errors and fallbacks
to using v4l2 timestamps instead of the previous timestamps from pulse 0xFD.
Fixes OpenCV exception on startup with Playstation Move controller:
what(): OpenCV(4.7.0) /usr/src/debug/opencv/opencv-4.7.0/modules/features2d/src/blobdetector.cpp:93: error: (-5:Bad argument) 0<minArea<=maxArea in function 'validateParameters'
* Sort lists
* Add all entries to exposed cmakedefines list
* Remove duplicate hand-tracking entry
* Move SLAM entry to feature list as it's called feature
After turning on the display, the Rift S
sends a burst of stale data and it can lead to
wildly incorrect clock estimates that then
recover really slowly and cause SLAM tracking to
lag horribly.
Throw away the first 100 samples, which seems to be
enough (only the first 20 or so seem to be bad).
Also reduce the clock a2b cutoff frequency, for
faster adaptation to changes.
Tested-By: Nova <technobaboo@gmail.com>
Some drivers says that they can export/import Vulkan formats that doesn't
have a direct mapping to a AHardwareBuffer format. Our import/export code
doesn't handle that case so make sure to filter out those formats.
Before we were not doing this because we have a hardcoded gravity vector.
Due to this, if the IMU gravity is too different, it causes the prediction to
bounce around slightly.
In practice the difference seems to be sufficiently small so as to be almost
not noticeable and we get the latency improvements we get are probably worth it.
Closes#234.
All credit for debugging and figuring out what the problem is goes to Mateo, I
made a different fix for it.
Co-authored-by: Mateo de Mayo <mateo.demayo@collabora.com>
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
Some drivers do not advertise support for VK_KHR_maintenance2 in
Vulkan 1.1, because it has been promoted to core.
This caused a validation error on compositors that use Vulkan 1.1
because the scratch image is allocated with unorm format and STORAGE
usage: an image view with srgb format can not be created with STORAGE
usage on many GPUs.
a/d3d: Improve allocation
Enable D3D11 and D3D112 depth images using DXGI handles
Allow D3D depth by default
D3D: only use DXGI handles
NT handles don't support depth formats and may fail to properly interop with Vulkan with some image dimensions.
Removed D3D_COMPOSITOR_ALLOW_DEPTH env.
D3D now always imports depth.
Added authorship.
Format pass
Fix D3D compositor tests
ipc: Fix HANDLE bit twiddling code
Merge into commits related to D3D depth changes. Makes the code compile
as C++, useful for Windows traceing
Co-authored-by: Robbie Bridgewater <ebridgewater@magicleap.com>
Co-authored-by: Fernando Velazquez Innella <finnella@magicleap.com>
Co-authored-by: Jakob Bornecrantz <jakob@collabora.com>
The last enum index was used to determine the size of the inputs array.
The "clever" solution of aliasing enum values saved a minor amount of space
when allocating the xrt_device, while still allowing to dynamically assign
any input profile.
It also has drawbacks of being confusing and making it impossible to
validate that inputs from the correct xrt_input_name is requested.
Therefore just get rid of it, the minor space savings is not worth it.
fixes 2be4cbf4c3
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>
Use INPUT_INDICES_LAST instead of 0 for checking if control_mapping[i]
is unassigned for index i, ie. for skipping input.
As 0 is a valid mapping assignment defined in "enum input_indices", this
lead to dead input for SIMPLE_SELECT_CLICK and OCULUS_TOUCH_X_CLICK, both
assigned to 0.
This commit makes the Oculus Rift CV-1 left touch controllers X-Button
work in Monado OpenXR native and SteamVR via. Monado driver plugin.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Goodbye, sweet prince.
This was my first attempt at the "optimizer" piece of our optical hand tracking, and it *did work* dammit! It just wasn't anywhere near as flexible or efficient as Levenberg-Marquardt.
It's worse in every way to the `kine_lm` optimizer, and getting hard to maintain, so we're getting rid of it. Gone, but never forgotten.
