- 27 Jan, 2021 5 commits
-
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
This works around a bug in the OpenXR CTS and mirrors better what at least on other OpenXR runtime does.
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Christoph Haag authored
-
- 26 Jan, 2021 3 commits
-
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
The problem: * xrCreateVulkanDeviceKHR is passed a VkPhysicalDevice, but not a VkInstance. * xrGetVulkanGraphicsDevice2KHR is passed a VkInstance and returns a VkPhysicalDevice that is a child of that instance. * xrCreateVulkanDeviceKHR must verify that the xrGetVulkanGraphicsDevice2KHR has been called and that the passed VkPhysicalDevice matches the one returned by xrGetVulkanGraphicsDevice2KHR. We have to consider: * xrCreateVulkanDeviceKHR has to work on the "correct" VkInstance, which the passed VkPhysicalDevice is a child of. The reqirement > If the vulkanPhysicalDevice parameter does not match the output of > xrGetVulkanGraphicsDeviceKHR, then the runtime must return XR_ERROR_HANDLE_INVALID. is not 100% clear whether calling xrCreateVulkanInstance multiple times is allowed and how a second call to xrGetVulkanGraphicsDevice2KHR with a dfferent VkInstance should be handled. For this implementation xrCreateVulkanDeviceKHR will only consider the most recent call to xrGetVulkanGraphicsDevice2KHR and the VkInstance that was used for this call. This enforces at least that VkPhysicalDevice is a child of the cached VkInstance when xrCreateVulkanDeviceKHR is called, because using a different VkPhysicalDevice would be an error.
-
- 25 Jan, 2021 6 commits
-
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Dan Weatherford authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
- 23 Jan, 2021 2 commits
-
-
Dan Weatherford authored
-
Dan Weatherford authored
-
- 22 Jan, 2021 2 commits
-
-
Jakob Bornecrantz authored
The CHECK_LAYER_TYPE tests would falsely pass on the IPC layer as it always implements all of the functions.
-
Christoph Haag authored
-
- 21 Jan, 2021 5 commits
-
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-
- 20 Jan, 2021 17 commits
-
-
Christoph Haag authored
In our model we have a "subpath" for each hardware input like "/input/trackpad". Each of these hardware inputs has "features" like "click", "touch", "position", "force". Ideally each of these "features" is bound to some monado input in the "monado_bindings" dict but this is not required. bindings.json will know about hardware features even if we don't bind them (yet). For each of these features bindings.py generates a group of related paths for a single monado binding: For a monado input XRT_INPUT_???_TRACKPAD these paths would be generated: /user/hand/left/input/trackpad/x /user/hand/left/input/trackpad/y /user/hand/left/input/trackpad
-
Christoph Haag authored
The generated files should be in auxiliary/bindings/*.{c,h}. For this to work meson.build has to be in the bindings/ subdir: https://github.com/mesonbuild/meson/issues/2320 Move CMakeLists.txt there too for some consistency. Also fixes the previous include hack.
-
Christoph Haag authored
Follow up to 543804e53cafa83c52b61f70894696bc4d95fa7c
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
Move json profile generator to auxiliary/bindings and make generated_bindings static library. aux/bindings: Add hardware type aux/bindings: Add various steamvr specific things to bindings Paths like "/input/menu/click" are used in SteamVR input profiles.
-
Christoph Haag authored
Subaction paths are the /user/X/Y part of the full path describing the input source/device. "Subaction paths are a mechanism that enables applications to use the same action name and handle on multiple devices. Applications can query action state using subaction paths that differentiate data coming from each device." Subpaths, are the input or output specific part of the full path, e.g. "Each input source path must match the following pattern: …/input/<identifier>[_<location>][/<component>]"
-
Christoph Haag authored
-
Christoph Haag authored
-
Christoph Haag authored
Useful for C++ compilers.
-
Christoph Haag authored
-
Christoph Haag authored
-
Jakob Bornecrantz authored
-
Jakob Bornecrantz authored
-