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.