It would be nice if things like Fovf and Posef implemented traits like PartialEq and Default.

Microsoft has a bunch of WIP features, e.g. XR_MSFT_hand_tracking_preview.

It would be nice to have sys bindings for these, and perhaps some optional cargo features to enable nicer APIs. I'd love to write the nicer APIs, however I'm not sure how to work the generator.

It seems like you need an xml file from the SDK, which doesn't exist for these (I can ask for one, maybe). We could potentially write one by hand and tweak the generator to accept additional xml files to be cfg-gated.

Thoughts?

More extensions will continue to be added; the ExtensionSet struct should contain an open ended Vec<String> for extensions that are unknown to this API.

The next is needed for passing, for example, XrSessionCreateInfoOverlayEXTX to create_session for extensions like XR_EXTX_overlay. Right now there is no way of setting it.

Would there be a chance of getting the loader structs into openxr_sys? They aren't listed in the registry but they are here: https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/main/src/common/loader_interfaces.h

These are necessary for writing API layers.

I was looking for extensions like XR_FB_keyboard_tracking, XR_FB_passthrough_keyboard_hands, XR_FB_render_model, etc and saw they all just weren't in the library yet. I think this mainly stems from these being recently added in the OpenXR 1.0.22 release (which was only a month ago): https://github.com/KhronosGroup/OpenXR-SDK/releases/tag/release-1.0.22.

Does updating the underlying OpenXR version happen to be easy? I imagine there's then some manual work to add the openxr view of these changes.

Is there any way I could help out with pulling the new version and updating the openxr layer?

The registry key HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenXR\1 ActiveRuntime can be set to indicate the default openxr runtime on windows. It seems like openxr-sys would be the place to implement that behavior -- perhaps enabled with a feature?

I wanted to float this here before actually implementing it.

This should be instance create info instead of application info.

Hi,

I got a problem with displaying my submitted Vulkan images. I have done as you did in your OpenGL example (except with a Vulkan setup):
https://github.com/hodasemi/Context/blob/c3d528cd53ace9f46b0b9c6854b6d0eac1c9f6f1/presentation/src/xri/openxrrendercore.rs#L429. Then I looked for Vulkan examples and I found xrgears and took its approach of using separate swapchains for each eye, but the result is the same.

When nothing is being rendered, the left side should just be green and the right side just red, because I'm just clearing the images (https://github.com/hodasemi/Context/blob/c3d528cd53ace9f46b0b9c6854b6d0eac1c9f6f1/presentation/src/renderbackend.rs#L186), but instead the screen is just black.

If I enable the renderdoc vulkan device extension, the left part of the screen is getting rendered, but with a green color, which should actually be on the right side.

So my question is, if you did experience any similar issues?
If not, could you help me, finding my issue?

openxr::FrameStream::end returns an result without an error. The C++ API of OpenXR actually returns a XrResult.

I'm currently having an issue where the result returned by openxr::FrameStream::end is the Err() variant but I don't know why because there is no error telling me why it failed.

Is there a specific reason this function doesn't return a result with a error like create_session?

With regards to session creation, Instance::create_session() takes an argument that represents the session create info for the active graphics API, but it appears the the OpenGL structure maps to the one for *nix I.E. XrGraphicsBindingOpenGLXlibKHR, whereas on Windows I think I'd need an instance of XrGraphicsBindingOpenGLWin32KHR. Maybe the crate does something to make the OpenGL enum a catch-all, but it's not clear to me how this is supposed to work. I could also just be missing something as I only started reading about OpenXR yesterday.

In my application, I have created an Action<Posef> and have obtained a Space from it by calling Action::create_space(). Now I want to locate that space within the broader tracking space with a call to Space::locate(tracking_space, time). The problem is that it doesn't seem like I'm able to obtain a time value for this Action. For Action<T: ActionInput>, there is a state() method which returns an ActionState which contains the Time that the Action was last updated, but I'm not seeing any kind of equivalent for Action<Posef>

I think that what I really need is some way to semantically say "right now" because I do just want the Posef at the moment locate() is called, but I can't seem to find that either.

I've been attempting to run the vulkan example on Windows. This has taken a while to figure out:

• Straight out of the box, the build fails (somewhat expected). The OpenXR-SDK README mentions that msbuild.exe needs to be in the PATH, but it's unclear whether this alone is sufficient.

• The Visual Studio 2019 documentation points me towards the "Developer PowerShell for VS 2019" shortcut, so I try using that to open a shell in which the CLI has the necessary tooling available. This unfortunately only supports 32-bit tooling, and the 64-bit tooling uses cmd.exe which is terrible, but this community thread has the necessary flags for creating a 64-bit PowerShell environment. I create a PowerShell script for this because I run into character limits while trying to modify the default shortcut.

• In the VS 2019 64-bit PowerShell environment, openxr-sys still fails to build, with the following error:

error: failed to run custom build command for `openxr-sys v0.8.4 (C:\Users\me\Documents\dev\rust\sat\openxrs\sys)`

Caused by:
  process didn't exit successfully: `C:\Users\me\Documents\dev\rust\sat\openxrs\target\release\build\openxr-sys-646a411395f24767\build-script-build` (exit code: 101)
--- stdout
running: "cmake" "C:\\Users\\me\\Documents\\dev\\rust\\sat\\openxrs\\sys\\OpenXR-SDK" "-G" "Visual Studio 16 2019" "-Thost=x64" "-Ax64" "-DBUILD_API_LAYERS=OFF" "-DBUILD_TESTS=OFF" "-DOpenGL_GL_PREFERENCE=GLVND" "-DDYNAMIC_LOADER=OFF" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_PREFIX=C:\\Users\\me\\Documents\\dev\\rust\\sat\\openxrs\\target\\release\\build\\openxr-sys-72146758c318d865\\out" "-DCMAKE_C_FLAGS= -nologo -MD -Brepro" "-DCMAKE_C_FLAGS_RELEASE= -nologo -MD -Brepro" "-DCMAKE_CXX_FLAGS= -nologo -MD -Brepro" "-DCMAKE_CXX_FLAGS_RELEASE= -nologo -MD -Brepro" "-DCMAKE_ASM_FLAGS= -nologo -MD -Brepro" "-DCMAKE_ASM_FLAGS_RELEASE= -nologo -MD -Brepro" "-DCMAKE_BUILD_TYPE=Release"
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
-- The C compiler identification is MSVC 19.27.29111.0
-- The CXX compiler identification is MSVC 19.27.29111.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: C:/Users/me/AppData/Local/Programs/Python/Python38-32/python.exe (found suitable version "3.8.1", minimum required is "3")
-- Found OpenGL: opengl32
-- Enabling OpenGL support
-- Could NOT find VulkanHeaders (missing: VulkanHeaders_INCLUDE_DIR)
-- Could NOT find VulkanRegistry (missing: VulkanRegistry_DIR)
-- Could NOT find Vulkan (missing: Vulkan_LIBRARY Vulkan_INCLUDE_DIR)
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE
-- Could NOT find JsonCpp (missing: JsonCpp_INCLUDE_DIR JsonCpp_LIBRARY)
-- Could NOT find glslc, using precompiled .spv files
-- Looking for secure_getenv
-- Looking for secure_getenv - not found
-- Looking for __secure_getenv
-- Looking for __secure_getenv - not found
-- Looking for timespec_get
-- Looking for timespec_get - found
-- Found and will use pre-generated xr_generated_dispatch_table.h in source tree
-- Found and will use pre-generated xr_generated_dispatch_table.c in source tree
-- Found and will use pre-generated xr_generated_loader.hpp in source tree
-- Found and will use pre-generated xr_generated_loader.cpp in source tree
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/me/Documents/dev/rust/sat/openxrs/target/release/build/openxr-sys-72146758c318d865/out/build
running: "cmake" "--build" "." "--target" "install" "--config" "Release" "--"
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1009: Project file does not exist.
Switch: install.vcxproj

--- stderr
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_ASM_FLAGS
    CMAKE_ASM_FLAGS_RELEASE
    CMAKE_BUILD_TYPE


thread 'main' panicked at '
command did not execute successfully, got: exit code: 1

build script failed, must exit now', C:\Users\me\.cargo\registry\src\github.com-1ecc6299db9ec823\cmake-0.1.44\src\lib.rs:885:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

warning: build failed, waiting for other jobs to finish...
error: build failed

It turns out that this is because the file being generated is INSTALL.vcxproj, and either CMake or MSBUILD is case-sensitive. Fortunately, renaming the generated file under target/release/build/openxr-sys-../out/build is sufficient to get past this.

• I then discover that the MSRV for the crate is greater than 1.40.0 (which is what I had installed at the time) due to these errors:

error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
   --> sys\src\lib.rs:191:6
    |
191 | impl<T> std::ops::Index<HandJointEXT> for [T] {
    |      ^ type parameter `T` must be used as the type parameter for some local type
    |
    = note: only traits defined in the current crate can be implemented for a type parameter

error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
   --> sys\src\lib.rs:198:6
    |
198 | impl<T> std::ops::IndexMut<HandJointEXT> for [T] {
    |      ^ type parameter `T` must be used as the type parameter for some local type
    |
    = note: only traits defined in the current crate can be implemented for a type parameter

error: aborting due to 2 previous errors

and the MSRV for the example is at least 1.43.0 due to the use of u64::MAX.

• After updating to Rust 1.46.0, compiling to hit the case-sensitive bug, renaming the file, and compiling again, I finally can run vulcan.exe, and it crashes:

     Running `C:\Users\me\Documents\dev\rust\sat\openxrs\target\debug\examples\vulkan.exe`
loaded OpenXR runtime: Oculus 1.52.0
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NulError(38, [86, 75, 95, 75, 72, 82, 95, 103, 101, 116, 95, 112, 104, 121, 115, 105, 99, 97, 108, 95, 100, 101, 118, 105, 99, 101, 95, 112, 114, 111, 112, 101, 114, 116, 105, 101, 115, 50, 0])', openxr\examples\vulkan.rs:65:34

which appears to be failing because CString::new (which appends a null byte) is being called on the already-null-terminated string VK_KHR_get_physical_device_properties2\x00:

There's clearly several steps in the toolchain setup process that I'm missing; it would be great to have them documented.

I tried to build the vulkan-android example. It exploded.

$ ANDROID_HOME=~/Android/Sdk/ ANDROID_NDK_ROOT=~/Android/Sdk/ndk/22.0.7026061/ cargo apk build --example vulkan-android
Using package `openxr` in `/home/thoth/vendor/openxrs/openxr/Cargo.toml`
Error: Failed to parse config.

Caused by:
    invalid type: string "false", expected a boolean for key `package.metadata.android` at line 63 column 1

How can I install this example on an Oculus Quest 2?

Hi, could you please push the updates you've made to this library in the last 12 months to crates.io?

It would be nice, if similar to ash, openxr-sys had default implementations for all of the structs, so I can not worry about the structure type and next pointer and whatnot. This would be primarily useful when writing layers. I imagine this being rather tedious to implement though. I'm considering doing it myself, but I thought I'd gather opinions first.

It seems that we do not support safe access to the Vulkan API through a crate such as Vulkano. OpenXR wants to provide the VkPhysicalDevice, which the Vulkan Rust crates do not support.

Status of support in other crates:

• Vulkano: vulkano-rs/vulkano#1396

When I try to run vulkan.rs on Windows I get

thread 'main' panicked at 'called Result::unwrap() on an Err value: ERROR_EXTENSION_NOT_PRESENT', openxr\examples\vulkan.rs:166:14

I'm using a 5700 XT with current drivers, I should have all the required extensions. Am I missing something or is there a bug present.

cargo 1.56.0 (4ed5d137b 2021-10-04)
cmake version 3.21.3
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Linux *** 5.11.0-38-generic #42~20.04.1-Ubuntu SMP *** x86_64 x86_64 x86_64 GNU/Linux

in CMake logs:
#include <xcb/glx.h> ... fatal error: xcb/glx.h: No such file or directory

Before that CMake is warning (not sure if it is relevant):

CMake Warning (dev) at src/loader/CMakeLists.txt:48 (add_library):
    Policy CMP0063 is not set: Honor visibility properties for all target
    types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
    cmake_policy command to set the policy and suppress this warning.

    Target "openxr_loader" of type "STATIC_LIBRARY" has the following
    visibility properties set for C:

      C_VISIBILITY_PRESET

    For compatibility CMake is not honoring them for this target.
  This warning is for project developers.  Use -Wno-dev to suppress it.

// I am not the rust/cpp/unix expert - I am happy to provide more info if needed :)

Dockerfile able to reproduce the issue

FROM ubuntu:20.04

ENV PATH="/root/.cargo/bin:${PATH}"

# Disable standard debian question about timezone
ENV DEBIAN_FRONTEND noninteractive

RUN apt-get update
RUN apt-get install -y build-essential cmake curl
RUN apt-get update

# https://www.rust-lang.org/tools/install
# added "-y" to proceed with defaults
RUN curl https://sh.rustup.rs -sSf | bash -s -- -y

# check in logs to ensure cargo 1.56.0 (4ed5d137b 2021-10-04)
RUN cargo -V

WORKDIR /home/someuser

RUN cargo new app --bin

WORKDIR /home/someuser/app

RUN echo 'openxr = { version = "0.15.4", features = ["static"] }' >> Cargo.toml
RUN tail -n 2 Cargo.toml # log out last 2 lines are [dependencies] \n openxr =...

RUN cargo build

You can copy-paste this docker script into file named "Dockerfile" and run docker build . given docker is installed on your machine.
Buildlog with cached steps before actual build:
buildlog.txt

In #46 I noted the following crash in the vulkan example:

     Running `C:\Users\me\Documents\dev\rust\sat\openxrs\target\debug\examples\vulkan.exe`
loaded OpenXR runtime: Oculus 1.52.0
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NulError(38, [86, 75, 95, 75, 72, 82, 95, 103, 101, 116, 95, 112, 104, 121, 115, 105, 99, 97, 108, 95, 100, 101, 118, 105, 99, 101, 95, 112, 114, 111, 112, 101, 114, 116, 105, 101, 115, 50, 0])', openxr\examples\vulkan.rs:65:34

It turns out that this is because for both Instance::vulkan_instance_extensions and Instance::vulkan_device_extensions, get_arr is returning an array with two trailing null bytes, but get_str assumes that the string will only contain one, and simply truncates a single byte.

I can temporarily fix this in the example with trim_end_matches('\x00'), but we should either understand where the extra null byte is coming from (and remove it), or alter get_str to strip as many null bytes as exist.

It seems a little counterintuitive for this to consume a session vs just taking a reference to one, like the other Action associated functions.

I'm currently experimenting with creating unity plugin, which hooks into openxr runtime. This works by providing unity with a function which takes pointer to xrGetInstanceProcAddr and returning my own pointer xrGetInstanceProcAddr. This means that I can override any function I want.

I am using openxr_sys for this and it is a big help 🙂 However, I'd like to try to use the safe wrapper for some parts, but I am unable to construct Entry, because I do not want to statically, nor dynamically load anything - this is already handled by Unity. Would you be open to a PR, which would add new way to construct Entry?

It would look something like this

    pub fn from_get_instance_proc_addr(func: sys::pfn::GetInstanceProcAddr) -> Result<Self> {
        // ...
    }

Was looking and wanted to comment on this - the leading "garbage" is in fact the "byte order mark" which keeps getting added and removed as people edit it. I have not yet found a convenient way to forcible add or remove it, but your upstream for file loading might consider handling it because some editors are apparently adding it automatically.

I'm having an issue where a Pose action is always considered inactive no matter the state of the XR hardware.

This code snippet is from initialization. Just creating an actionset with a single pose action:

Later, we attach the actionset to the session:

This code is in the main loop. I'm calling sync actions with the previously created actionset and just printing out if the controller pose action is active or not:

My application prints "Sync actions returned ok" followed by "false" every frame, regardless of the state of the hardware. I don't know how this can be as I'm calling sync_actions right beforehand. It looks like I'm doing things right by the openxr API itself, so I'm wondering if I'm just using this crate wrong.

Any thoughts would be appreciated.

Hello, I would like to ask whether it can support the openxr extension XR_FB_eye_tracking_social ?. I found the bool variable in avaliable extension side but where is the source code for eye_trakcing_social ？
Thank you!

The build.rs script seems to have have an issue configuring cmake where jsoncpp is left out somehow. Compiling with cargo check --features static results in the following excerpt:

CMake Error: install(EXPORT "openxr_loader_export" ...) includes target "openxr_loader" which requires target "jsoncpp_interface" that is not in any export set.
CMake Error in src/loader/CMakeLists.txt:
  export called with target "openxr_loader" which requires target
  "jsoncpp_interface" that is not in any export set.

Using the OpenXR SDK's README.md instructions to compile the OpenXR-SDK folder that openxr-sys clones works just fine, which leads me to believe the issue is in build.rs somehow.

Things like hand tracking are now in the core spec

https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#XR_EXT_hand_tracking

My draft PR for hand tracking may be useful for writing higher level bindings, but it's based on an older API shape: #24

Using a specific function as an example:

The OpenXR specification states that for valid usage of xrGetVulkanGraphicsDeviceKHR, vkPhysicalDevice must be a pointer to a VkPhysicalDevice value to be populated. However, openxr::Instance::vulkan_graphics_device passes in std::ptr::null():

This suggests that there is an intermediate Rust layer that allocates the required memory for VkPhysicalDevice, and sets &mut out to point to it. What I can't figure out is, where is the memory allocated?

I had to edit sys/build.rs to contain the version number in order to link the openxr_loader on Windows:

println!("cargo:rustc-link-lib=static=openxr_loader-1_0");

Unclear if this is a Windows-specific issue, or if it's an issue with the version of the openxr SDK used.

While regenerating the rust binding starting OpenXR SDK commit id 77a93e7e01854a6614c790f78bef87745562faae, script fails with above error in thread 'main' panicked at generator/src/main.rs:2145:5.

It's not entirely clear to me what the vulkan example is supposed to be rendering. When I run it with my Oculus Rift (OpenXR runtime: Oculus 1.52.0), I see the left eye viewport rendered entirely green, and the right eye viewport rendered entirely white. This suggests that at a minimum, multiview isn't working correctly (as IIUC that should cause the same image to be rendered across all viewports).

I was trying to get the Vulkan example to work, but the headset I'm using only supports khr_vulkan_enable and not khr_vulkan_enable2. How would I have to change the example to accommodate this? I'm not sure how much the specific device matters, but I'm trying to run the example on the quest 2 over USB via oculus link.

The Entry::load_from function seems to be loading function pointers in a non spec compliant way.
Looking at this code:
https://github.com/Ralith/openxrs/blob/master/openxr/src/entry.rs#L67

Take a look at the documentation for runtime loading:
https://github.com/KhronosGroup/OpenXR-SDK-Source/blob/master/specification/loader/runtime.adoc#loaderruntime-interface-negotiation

It looks to me like an openxr implementation should only export a single function XrNegotiateRuntimeRequest and then this function will provide a function pointer to load the remaining symbols.

I ran into this when trying to manually load Steam's OpenXR implementation. Running dumpbin on vrclient_x64.dll reveals that xrNegotiateLoaderRuntimeInterface is the only exported OpenXR function.

I am trying to use my vive to run a simple scene with a few triangles.
While I got it al working it feels like 1 in 3 frames lag behind, even though the chaperone does update correctly.
The fps is good (around 90) and when I animate the triangles by just updating their position, it all looks smooth
Turning or moving the headset just causes horrible stutters.

This might not be an issue with openxrs, I just don't know where to start looking for a solution.
There were some problems getting steamvr to work, I decided to just filter out 'VK_EXT_debug_marker' from the required device extensions. (not sure if this causes any issues but at least it runs this way)

Maybe someone can point me in the right direction?
Could be that this is just an issue with the openxr implementation of steam vr, but didn't see anyone else with the same issue...
Could also be an issue with my code as I am not really experienced in writing engine code.
This is the what I use to get the view projection matrix:

  pub fn get_vp(view: &View, project: &glm::Mat4x4) -> [[f32; 4]; 4] {
    let orient = view.pose.orientation;
    let orient_glm = glm::quat(orient.x, orient.y * -1.0, orient.z, orient.w * -1.0);
    let rotation = &glm::quat_cast(&glm::quat_inverse(&orient_glm));

    let position = view.pose.position;
    let position_glm = glm::vec3(position.x, -position.y, position.z);
    let translation = glm::inverse(&glm::translation(&position_glm));
    
    let view_matrix = rotation * translation;
    let vp = project * view_matrix;
    vp.into()
  }

Any help would be much appreciated!!

This is made difficult by rust-lang/cargo#5015. Prior discussion in #8. This is a somewhat fragile platform-specific feature, so testing is especially valuable.

Hellos,
I'm newer to rust and I tried digging through your source to get the intent of this but couldn't figure it out.

Action<Posef>::create_space consumes the session argument but this session argument is needed for other things -- is this intentional? And if so, how is create_space supposed to be called without consuming session?

Thanks

It could be convenient if most of the structs for enum-like constants, such as EnvironmentBlendMode implemented Hash.

While experimenting, I initially went to put the supported blend modes in a HashSet with the intention to check (on-the-fly) if an app was able to switch between opaque vs pass-through rendering. Easy enough to workaround but still it could be convenient.

The next structure chain pointer is currently harcoded to be a nullptr when creating a new instance.

This prevents usage of the extension structures provided by XR_EXT_debug_utils (as specified in "Example 1" here) and XR_KHR_android_create_instance.

Looks like the latest oculus desktop runtime (23.0.0.43.517) does not support changes from KHR_vulkan_enable2. #65
Issue affects v0.14.0.

Tested v0.13.1 - both vulkan and hello demos working.

Not sure if this means there should be a fallback option to KHR_vulkan_enable?
Wanted to document in case someone ran into the same issue.

I have added openxr as a dependency to my project like so:

[dependencies]
openxr = { version = "0.17.1", features = ["static"] }

cargo build results in this error:

error: failed to run custom build command for `openxr-sys v0.9.3`

Caused by:
  process didn't exit successfully: `/Users/valentinebriese/Developer/bevy-openxr/target/debug/build/openxr-sys-2b99eab513ccc729/build-script-build` (exit status: 101)
  --- stdout
  CMAKE_TOOLCHAIN_FILE_aarch64-apple-darwin = None
  CMAKE_TOOLCHAIN_FILE_aarch64_apple_darwin = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_aarch64-apple-darwin = None
  CMAKE_GENERATOR_aarch64_apple_darwin = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_aarch64-apple-darwin = None
  CMAKE_PREFIX_PATH_aarch64_apple_darwin = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_aarch64-apple-darwin = None
  CMAKE_aarch64_apple_darwin = None
  HOST_CMAKE = None
  CMAKE = None
  running: cd "/Users/valentinebriese/Developer/bevy-openxr/target/debug/build/openxr-sys-cfd644a5713c7f7b/out/build" && CMAKE_PREFIX_PATH="" "cmake" "/Users/valentinebriese/.cargo/registry/src/index.crates.io-6f17d22bba15001f/openxr-sys-0.9.3/OpenXR-SDK" "-DCMAKE_OSX_ARCHITECTURES=arm64" "-DBUILD_API_LAYERS=OFF" "-DBUILD_TESTS=OFF" "-DOpenGL_GL_PREFERENCE=GLVND" "-DDYNAMIC_LOADER=OFF" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_INSTALL_PREFIX=/Users/valentinebriese/Developer/bevy-openxr/target/debug/build/openxr-sys-cfd644a5713c7f7b/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -arch arm64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Release"
  -- Enabling OpenGL support
  -- Enabling Vulkan support
  -- Could NOT find glslc, using precompiled .spv files
  -- Found and will use pre-generated xr_generated_dispatch_table.h in source tree
  -- Found and will use pre-generated xr_generated_dispatch_table.c in source tree
  -- Found and will use pre-generated xr_generated_loader.hpp in source tree
  -- Found and will use pre-generated xr_generated_loader.cpp in source tree
  -- Configuring done (0.3s)
  -- Generating done (0.0s)

  --- stderr
  CMake Deprecation Warning at CMakeLists.txt:24 (cmake_minimum_required):
    Compatibility with CMake < 3.5 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.


  CMake Warning (dev) at CMakeLists.txt:27 (find_package):
    Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs modules
    are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
    the cmake_policy command to set the policy and suppress this warning.

  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Warning (dev) at src/loader/CMakeLists.txt:48 (add_library):
    Policy CMP0063 is not set: Honor visibility properties for all target
    types.  Run "cmake --help-policy CMP0063" for policy details.  Use the
    cmake_policy command to set the policy and suppress this warning.

    Target "openxr_loader" of type "STATIC_LIBRARY" has the following
    visibility properties set for C:

      C_VISIBILITY_PRESET

    For compatibility CMake is not honoring them for this target.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  CMake Error: install(EXPORT "openxr_loader_export" ...) includes target "openxr_loader" which requires target "jsoncpp_interface" that is not in any export set.
  CMake Error in src/loader/CMakeLists.txt:
    export called with target "openxr_loader" which requires target
    "jsoncpp_interface" that is not in any export set.


  CMake Generate step failed.  Build files cannot be regenerated correctly.
  thread 'main' panicked at /Users/valentinebriese/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cmake-0.1.50/src/lib.rs:1098:5:

  command did not execute successfully, got: exit status: 1

  build script failed, must exit now
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

I am on a 2020 M1 MacBook Air running macOS 14.3 Beta (23D5033f).

Holding off for a bit to see if KhronosGroup/OpenXR-SDK-Source#197 gets fixed first.

The status icons in the README indicate that the code is licensed as both MIT and Apache, but the relevant LICENSE files don't appear to exist. Could you add them?

The new extension gives the XR runtime more freedom, and hence should be preferred.

I am currently trying to enable API layers, but I noticed that this is not exposed in OpenXR.

https://github.com/Ralith/openxrs/blob/master/openxr/src/entry.rs#L142-L143

Is there a reason for this?

I am currently tracking down some validation errors, but the debug message callback is almost printing nothing by default. I assume there might be some validation layers that would help me.

Tried to build the example and another project but always get this error.
pathcch.h is part of the win32 library but I should have all the necessary build tools for c++ installed (at least I think so the SDL crate works fine for example)
This is the error:

libopenxr_sys-9008a7c2938b17d8.rlib(filesystem_utils.obj) : error LNK2019: unresolved external symbol __imp_PathCchCanonicalize referenced in function "bool __cdecl FileSysUtilsGetCanonicalPath(class std::basic_string<char,struct std::char_traits<char>,class std::allocaferenced in function "bool __cdecl FileSysUtilsGetCanonicalPath(class std::basic_string<chartor<char> > const &,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &)" (?FileSysUtilsGetCanonicalPalocator<char> > &)" (?FileSysUtilsGetCanonicalPath@@YA_NAEBV?$basic_string@DU?$char_traits@Dth@@YA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@AEAV12@@Z)

Is there something I am missing?

The low-level bindings exist, but the higher level bindings are missing. If nobody else gets to it first, we will create these as part of the OpenXR work that Servo is doing for HoloLens.

Running the Vulkan example with:

export VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation
cargo run --example vulkan --features static >log.txt

Does not display to the HMD and instead appears to hang in SteamVR. See attached error messages from validation layers in log.txt
Note that the same trial did work on Windows on the same computer (albeit with different validation layer errors).
OpenXR runtime for both Windows and Linux trials: SteamVR beta 1.14.6
Operating system: Ubuntu Linux 20.04
Graphics card: NVidia GTX 1070
Driver version: 440.100
HMD: Original Vive

Currently when some extensions are disabled and you try to call some associated methods, for example request_display_refresh_rate, it would lead to a crash because there is one expect() call:

In such cases it seems OpenXR would return XR_ERROR_FUNCTION_UNSUPPORTED. We could also return that error code. In this way it would be simpler to just do .ok() for some calls like request_display_refresh_rate which don't require any special handling when it fails.