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.
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
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.
