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.
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>
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.
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'
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>
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>
One alternative to this is to use the CreateWaitableTimerExW function
with the CREATE_WAITABLE_TIMER_HIGH_RESOLUTION flag. On my systems the
function/flag was either as good or worse then timePeriod[Begin|End].
Setting the state globally or just just around the wait didn't seem to
have an impact on the precision.
