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>
The last enum index was used to determine the size of the inputs array.
The "clever" solution of aliasing enum values saved a minor amount of space
when allocating the xrt_device, while still allowing to dynamically assign
any input profile.
It also has drawbacks of being confusing and making it impossible to
validate that inputs from the correct xrt_input_name is requested.
Therefore just get rid of it, the minor space savings is not worth it.
fixes 2be4cbf4c3
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>
