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.
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.
The code creates a frame with the timing information, and keeps track of the
times the applications does various things during the frame loop. Like
starting to render and finished rendering and so on. It keeps track of that
frame until it has determined that the application or the system compositor
will never do anything thing with that frame.
Now the allocation side of thing is very simple, just a long array of
FRAME_COUNT size that is reused with frame_id % FRAME_COUNT. So if the
application or the compositor keeps a frame along for too long it will try to
reuse that frame. The code has asserts to catch this. Making FRAME_COUNT makes
that re-use more unlikely.
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.
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.
