OpenXR runtimes not enabled by default in pressure vessel

[xytovl]

PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES has been available since the 20250616 release, when using WiVRn we instruct users to add that to games launch commands.

When installing WiVRn through the AUR package, the variable is set at system level. The Gentoo ebuild does the same.
So far we have not had any report of issues when doing so.

Are there plans to enable this feature by default? This would reduce friction when using FOSS OpenXR runtimes.

[smcv]

For completeness: OpenXR layers aren't "captured" by default, either.

Are there plans to enable this feature by default?

The cost/risk of enabling "capture" of more driver stacks by default is that the more driver stacks we pull in, the more risk there is of one of them having a dependency that breaks the ABI presented to games - either by having an incompatible behaviour change without a SONAME bump, or by breaking our ability to identify which version is newer, or by having a "family" of related libraries that need to be upgraded-or-not as a unit.

(For example #825 is an example of the Nvidia graphics drivers' dependencies having unintended consequences, and the Nvidia drivers generally have very conservative dependencies, probably more so than OpenXR stacks.)

Runtimes (and layers) can mitigate this risk by trying to keep their library dependencies minimal, do as little work as is feasible to do (for example only the performance-critical parts) in-process in the game, and do as much of the work as possible by communicating with a system-wide service on the host instead.

I think capturing all OpenXR runtimes (and, especially, layers) by default would be quite risky, especially if they start to be sufficiently widely-adopted that distros install them by default. One possible route forward would be to have a mechanism to allowlist runtimes (and layers) that are believed to be well-behaved and not have problematic dependencies, and "capture" those by default.

[xytovl]

For runtimes only, I don't know if there's anything else than SteamVR and Monado (+ derived).

WiVRn (derived from Monado):

readelf -d /usr/lib/wivrn/libopenxr_wivrn.so | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libvulkan.so.1]
 0x00000001 (NEEDED)                     Shared library: [libGLX.so.0]
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

SteamVR:

readelf -d $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libGL.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libEGL.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libuuid.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Pressure vessel already has some knowledge of Monado and WiVRn: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/pressure-vessel/wrap-openxr.c?ref_type=heads#L37-42

An allowlist could be a solution, currently, both Monado and WiVRn identify themselves with "name": "Monado" in the manifest.

[smcv]

An allowlist could be a solution, currently, both Monado and WiVRn identify themselves with "name": "Monado" in the manifest.

This seems bad: Wivrn should identify itself as itself, particularly if it's functionally different (which it does seem to be: you'll see that in pv_wrap_add_openxr_args(), pressure-vessel has to look for a different IPC socket for it).

@xytovl, if you're involved with Wivrn upstream, please could you give it a different name? It doesn't necessarily need to be committed or in releases, but the upstream developers should agree on "if we had a unique name, this is what it would be".

I wouldn't want to add an allowlist of known-well-behaved runtimes without including Wivrn in it under its own name!

readelf -d /usr/lib/wivrn/libopenxr_wivrn.so | grep NEEDED

Great, this looks non-problematic.

readelf -d $HOME/.local/share/Steam/steamapps/common/SteamVR/bin/linux64/vrclient.so | grep NEEDED

Also this (the dependency on libuuid.so.1 is a bit strange but should hopefully be harmless).

For completeness:

$ objdump -T -x /usr/lib/x86_64-linux-gnu/libopenxr_monado.s
…
  NEEDED               libGLX.so.0
  NEEDED               libvulkan.so.1
  NEEDED               libcjson.so.1
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libgcc_s.so.1
  NEEDED               libc.so.6

all of that looks fine with the possible exception of libcjson.so.1... but as it happens, we don't seem to ship libcjson in any runtimes, so it shouldn't be able to conflict.

[xytovl]

I will open a merge request in Monado so that downstream projects can easily customize the "name" field.
Note that the xr library referenced in the WiVRn manifest is build from unmodified Monado code, with only build configuration options: socket name, path and version identifier.

For libcjson, this is a build option in https://gitlab.freedesktop.org/monado/monado/-/blob/c9ae292ca624fe32f2f095dfd2591d412fc03425/CMakeLists.txt#L262

[xytovl]

I have made the changes to set the name in WiVRn/WiVRn@8c8bd6b
Starting from next release, the manifest for WiVRn will look like this:

{
    "file_format_version": "1.0.0",
    "runtime": {
        "name": "WiVRn",
        "library_path": "../../../lib64/wivrn/libopenxr_wivrn.so",
        "MND_libmonado_path": "../../../lib64/wivrn/libmonado_wivrn.so"
    }
}

[xytovl]

I have just released WiVRn 26.9, it now has "name": "WiVRn" as described in previous message. The set of needed libraries is unchanged.