Includes a workaround for D3D12 and Vulkan interop issues in NVidia
hardware. We want to directly allocate in D3D12 to be able to use all
resource flags during creation, such as multi-gpu ones.
Add a D3D12 allocator and helper code to copy from shadow images,
the copy is needed to work around a interop issue on NVIDIA hardware.
Co-authored-by: Ryan Pavlik <ryan.pavlik@collabora.com>
Work done by lots of different authors that did various pieces of the library.
Co-authored-by: Korcan Hussein <korcan.hussein@collabora.com>
Co-authored-by: Jakob Bornecrantz <jakob@collabora.com>
Co-authored-by: Ryan Pavlik <ryan.pavlik@collabora.com>
Relation history was being accessed guarded by an external lock in a couple of
places. This is redundant since its implementation already defines an internal
lock.
Relation history was being accessed guarded by an external lock in a couple of
places. This is redundant since its implementation already defines an internal
lock.
Relation history was being accessed guarded by an external lock in a couple of
places. This is redundant since its implementation already defines an internal
lock.
This fixes a bug on NVIDIA Jetson. Note this isn't so much the NVIDIA Jetson
fault, while the code was working on desktop, Monado did something wrong.
What happned was that Monado would select a mode with one size, while then
creating a VkSurface/VkSwapchain of a different size. This would work on
hardware with scalers/panning modes. The NVIDIA Jetson apparently doesn't have
support for that so failed when presenting. This patch makes sure that the
VkSurface/VkSwapchain extents match the mode for all direct mode targets.
sdl-test uses some OpenGL4.5 features, such as Texture Objects.
Currently, sdl-test is initialized with an OpenGL3.3 context, and with
a NVidia driver (version 535.98, on Linux), the call to those features
(glCreateTextures() being the first of them) segfaults.
Fixes GCC 13 warning [-Wunused-function].
Define on_video_device and p_factory_ensure_frameserver only when PSMV
or PSVR are enabled. Drop redundant check for XRT_HAVE_OPENCV, since we
already do it above.
Fixes GCC 13 warning [-Wenum-int-mismatch].
Return xrt_result_t in the implementation of xrt_instance_create in
target_instance_no_comp.c, as declared in xrt_instance.h and already
done in target_instance.c.
Return proper xrt_result_t instead of plain ints.
Fixes GCC 13 warning [-Wenum-int-mismatch].
Use same return type in for r_create_devices definition in r_hub.c as in
the declaration in r_interface.h.
The function was already returning correct xrt_result_t.
Prior to this, the existing `xrt_device_name` entry
`XRT_DEVICE_HAND_INTERACTION` was re-used for `XR_EXT_hand_interaction`
bindings however this `xrt_device_name` is used to look up the older
hand-interaction profile `XR_MSFT_hand_interaction`. This commit adds a new
`xrt_device_name` entry dedicated for `XR_EXT_hand_interaction` and fixes the
incorrect profile look for suggested bindings during runtime.
Currently there does not seem to be a way to access the SteamVR
dashboard with the Reverb G2 (controllers).
This adds a binding that allows to use the system/home button to
open the SteamVR dashboard.
Remark: In the OpenXR 1.0 spec there is no binding for
/input/system in XR_EXT_hp_mixed_reality_controller. However on Windows
this button would supposedly allow to (indirectly?) access the
SteamVR dashboard. (Which I can't confirm myself, as I don't have
access to a Windows OS right now.) To properly support system buttons in
OpenXR introduce XR_MNDX_system_buttons.
Co-authored-by: Jakob Bornecrantz <jakob@collabora.com>
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Jakob Bornecrantz <jakob@collabora.com>
A requirement of interaction profile (extensions) specify that some/all
actions must be supported by all other profiles. This commit
modifies the binding generation to support data-inheritance in bindings.json:
* Adds support for profiles in bindings.json to inherit & override other profiles
* Adds a new concept of virtual profiles for profile like extensions
(e.g. `XR_EXT_palm_pose`) which do not define a profile themselves but
require their newly defined actions to be supported by all profiles.
* Generates verify bindings functions which only check extensions actions
only if the extension is enabled.
The binding code has support for this extenstion, but the bindings are not
used in any of the drivers so totally untested and would lead to the wrong
expectations of the applications.
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
