Some devices like Android smartphones have displays which are
rotated, meaning the compositor needs to rotate its output.
Add support for this to the compute compositor by rotating the
contents of the textures it uses for distortion lookups. This
requires postponing the calculation of that texture and adding
code to recreate it if the rotation changes (which is allowed,
but unlikely to happen in practice.)
Make sure to stop the USB thread before destroying the debug sink
as cancelling the transfers is not sufficient to guarantee
there will be no final callback (or one in progress)
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.
Use a sink in the middle of the stream to correct for v4l2 timestamps with
hardware timestamps to monotonic clock.
This sink, together with other utilities related to data streaming, lives in a
new vive_source entity, with similar functionality to wmr_source or rs_source.
The vive_source lifetime is managed by the builder xfctx, which prevents
deallocation dependencies between vive_device and the v4l2_fs to cause segfaults.
Fixes error
/home/haagch-collabora/monado/src/xrt/drivers/survive/survive_driver.c:384:53: error: passing 'const union xrt_output_value *' to parameter of type 'union xrt_output_value *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
int ret = survive_controller_haptic_pulse(survive, value);
^~~~~
/home/haagch-collabora/monado/src/xrt/drivers/survive/survive_driver.c:340:89: note: passing argument to parameter 'value' here
survive_controller_haptic_pulse(struct survive_device *survive, union xrt_output_value *value)
The vk bundle currently creates a single queue, calls vkGetDeviceQueue,
and stores it in the bundle. There's only ever 1 queue from 1 queue
family right now, even when using the compute compositor.
It doesn't really make sense for the renderer to re-request this queue
instead of using the one in the bundle. If we wanted to store a local
version to it, it should probably be assigned directly (i.e. r->queue =
vk->queue) to ensure that it's the same. If we decide we want multiple
queues later, that would be a good time to add this sort of thing back.
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.
Similar to how this was being done for SLAM.
It's significantly less jittery and still has a good response.
Smarter filters might benefit from raw measurements so the functionality can
be enabled again with a checkbox.
Hopefully this is an improvement and not just a rewrite. Some ideas were:
1. Keep poses in WMR space as much as possible.
2. Add an explicit function that precomputes a handful of transforms that allow
converting between WMR and OpenXR coordinates.
3. Make naming of variables in line with a relatively common T_A_B notation.
4. I wasn't able to figure out why `wmr_config_compute_pose` worked before,
in any case, hopefully the new notation convention helps understanding
why P_oxr_{acc,gyr} work.
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.
