`graphics-drivers-openxr-1.c` removes vendor-specific fields from the active runtime json

[jvyden]

I've noticed that vendor-specific prefixed fields seem to be trimmed from the active_runtime.json that gets mounted in the container's /etc folder when using PRESSURE_VESSEL_IMPORT_OPENXR_1_RUNTIMES=1.

Compare my local active_runtime.json configuration, in my XDG_CONFIG_HOME:

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

to the one mounted to the container at ~/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/tmp-1X9FF3/usr/lib/pressure-vessel/overrides/etc/xdg/openxr/1/active_runtime.json:

{
  "file_format_version" : "1.0.0",
  "runtime" : {
    "library_path" : "/home/jvyden/.local/share/envision/prefixes/b5c04363-bfc4-48c7-8e7f-45b3e996a57b/lib/wivrn/libopenxr_wivrn.so",
    "name" : "Monado"
  }
}

I've narrowed this behavior down to graphics-drivers-openxr-1.c where it seems to drop the original JSON in favor of SRT's own format using g_object_new. This new format is then used to override the active_runtime.json in the container by passing through srt_openxr_1_runtime_new_replace_library_path.

This mainly affects Monado/WiVRn, but also could affect SteamVR since it sets VALVE_runtime_is_steamvr to true in the runtime configuration, according to #575 (comment). I noticed this upon trying to integrate libmonado into xrizer and not being able to find where libmonado is from the runtime configuration.

---

• Steam Runtime Version: Sniper, I believe? This behavior is exhibited in Proton Experimental.
• Distribution (e.g. Ubuntu 18.04): Arch Linux
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: https://gist.github.com/jvyden/550d3d3ef3f400b06db3a42593992c82
• Have you checked for system updates?: [Yes/No] yes
• What compatibility tool are you using?: Proton Experimental
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? 0.20240806.0
• What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? 2.0.20250826.159137 0.20250820.0 0.20250820.0 2.0.20250826.159137
• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? 3.0.20250826.159138 0.20250820.0 0.20250820.0 3.0.20250826.159138

[smcv]

This is probably not fixable. We can't safely pass through vendor-specific fields in situations where we need to modify the JSON manifest to reflect in-container paths, because we don't know what they mean (because they're vendor-specific, they might even mean different things to different vendors!) and their correct values outside and inside the container could be different.

I noticed this upon trying to integrate libmonado into xrizer and not being able to find where libmonado is from the runtime configuration

In the absence of this vendor-specific field, could whichever component needs it perhaps assume that it's in the same directory as the library_path? That would be correct in your case.

[smcv]

in situations where we need to modify the JSON manifest

... and this, where the library_path given is relative to the JSON manifest's own filename, is one of those situations - we can't guarantee that the filesystem layout inside the container gives relative paths the same meaning, so we have to canonicalize it to absolute.

[jvyden]

For paths this is definitely tricky, but for other strings and especially other value types this is definitely out of spec behavior. A bool as an example from SteamVR's runtime manifest is completely harmless and probably should be included, regardless of my particular symptom of not being able to determine a file-path.

I definitely do agree that I can work around this from the loader side, but as there's no universal mechanism to load libmonado like something akin to openxr-loader, I'm worried it ends up being dependent on app developers to be aware of this behavior in Steam's container. The silver lining here is that most things that depend on libmonado happen to be Rust-based, which share a common libmonado-rs crate that bundles loading logic so in practice I don't think this is too big of a deal - just an edge case to be aware of.

Back to pressure-vessel, I believe there's definitely precedent for workarounds here, specifically it bind-mounts Monado/WiVRn's IPC sockets manually so I think a special case for MND_libmonado_path specifically if present is actually quite a reasonable approach. I also think having a heuristic for fields ending in _path that also have values that look like paths (e.g. containing /) and canonicalizing such fields would be another approach but this is less targeted.

---

TL;DR: I disagree that there's nothing that can be done here - no vendor fields at all seems unintended to my eyes. But for my specific case (and I see why this can be tricky) workarounds can be employed.