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.
1. Add feature info pose extension
2. Make pose extensions toggleable on runtime
3. Add timestats helper for external system to keep track of info for pose extensions
Currently, there is a single command pool in the vk bundle, shared by
everyone. Since command pools (and command buffers allocated from those
pools) can only be used on one thread at a time, this requires locking.
However, the main point of having these annoying command pool things in
the first place is that you can use one for each thread/lifetime/area in
the app and avoid the overhead of the locks (both computational and
cognitive).
In this change I have given the rendering bits of the compositor its own
command pool. Instead of allocating and freeing a command buffer every
frame, a single command buffer is allocated from the pool during
initialization, and the pool is reset at the beginning of each frame.
Normally, multiple pools would need to be used, but this is not
necessary in monado because frames are serialized. The `TRANSIENT` and
`ONE_TIME_SUBMIT` flags have been added, which can allow for some driver
optimizations. The render code no longer takes out the command pool
mutex. The shared command pool is still there for a few remaining
places where vulkan work needs to be done outside the compositor.
I used the command buffer vulkan helpers when possible, but I would
maybe propose the idea of removing them, since they aren't really
wrapping much at this point. The `C` macro helps a lot and it's a bit
easier to see the Vulkan details in front of you instead of needing to
switch back and forth between the helper.
Later, I think it would be cool to apply and document some constraints
like "the queue is only accessed in functions XYZ, the render_resources
command pool must only be accessed in layer_commit from 1 thread" etc.
Previously this was using math_quat_len which was always 1 for
these unit quaternions. This commit assumes math_quat_ln works properly which is
not exactly true at the moment and the returned angle will be twice as large.
Previously, math_pose_invert would apply a multiplication in the wrong
order. This lead to the position of the 'original' pose being rotated.
This patch fixes that, and adds a unit test to check this case.
An isometry is a rigid body transform. In this context I'm using the term to
refer to 4x4 homogeneous matrices in SE(3). I.e., matrices comprised of a
3x3 rotation, a 3x1 translation, and a [0,0,0,1] last row.
This matrix represent both rigid body transforms.
Isometry3f is a 4x4 matrix transform that performs only rotation and translation
(an SE(3) matrix). Its inverse can be computed trivially by Eigen compared to a
regular 4x4 transform.
