pressure-vessel fails to link in gbm backends from the host (regression since mesa-24.3.0)

[hoshinolina]

Pressure-vessel links in libgbm from the host:

.local/share/umu/steamrt3/var/tmp-M308I3/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libgbm.so.1 -> /run/host/lib64/libgbm.so.1.0.0

But it does not link in the /usr/lib/gbm directory. This means that when an application tries to use libgbm from within the container, it fails with:

MESA-LOADER: failed to open dri: /usr/lib64/gbm/dri_gbm.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/gbm/, suffix _gbm)

By analogy, dri uses a similar mechanism and pressure-vessel does handle it correctly:

.local/share/umu/steamrt3/var/tmp-LRY2I3/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/dri/radeonsi_dri.so -> /run/host/usr/lib64/dri/libdril_dri.so

This is a regression since this mesa commit (released in mesa-24.3.0), which split off gbm into backends similar to how dri already worked.

A simple workaround is to set GBM_BACKENDS_PATH=/run/host/usr/lib64/gbm, which makes things work.

The pressure-vessel code that handles dri drivers is here. A similar codepath is needed for gbm.

Your system information

• Steam Runtime Version: sniper_platform_3.0.20251216.191774
• Distribution (e.g. Ubuntu 18.04): Fedora 42
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton-GE
• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

#Name   Version         Runtime Runtime_Version Comment
depot   3.0.20251216.191774                     # Overall version number
pressure-vessel 0.20251210.0    scout           # pressure-vessel-bin.tar.gz
scripts 0.20251210.0                    # from steam-runtime-tools
sniper  3.0.20251216.191774     sniper  3.0.20251216.191774     # sniper_platform_3.0.20251216.191774/

[smcv]

Is there an example of a hardware/OS/game combination where this concretely causes a problem, preferably with either a native Linux title or an official/supported version of Proton?

The pressure-vessel code that handles dri drivers is here. A similar codepath is needed for gbm.

This seems likely to be a correct diagnosis, but it isn't clear from your report what practical impact this has.

[hoshinolina]

It impacts something I'm working on. In terms of Steam apps this tool applies to, VTube Studio and Warudo are some, but there are probably others. As far as hardware, this happens on at least Radeon and I presume anything using Mesa drivers at the very least. OSes, probably ~everything but confirmed on Fedora and Debian-based distros. As for Proton versions, aside for the tool itself being an installable extension for Proton itself, the base version just needs to be 10 or newer.

As far as potential audience, I would say this tool would benefit and will probably wind up being used by the majority of VTube Studio users on Linux, if you want to put some stats on this (I'm fixing what is a major regression from Windows for VTubing on Linux). Obviously we're not there yet since I just pre-released this yesterday, but it would be nice to fix this bug before ending up with all the users using hacks to work around it ^^ (and people are certainly interested!)

I sent an email to wine-devel about this extension, and changes in proton would also help make it easier to integrate. I planned to start off as a third-party installable without having to bother Valve/Proton about this from day one, but I didn't expect a bug in pressure-vessel (which everyone uses precompiled through steam runtime, even outside of the "supported" Steam/Proton use cases) to affect me...

[kisak-valve]

I've seen libgbm log messages for a fairly long time without a functional impact to to the feedback coming in along with it appearing in the log. I think that @smcv's comment is asking for help identifying a test case where libgbm is required for a game to run as intended instead of a scenario where a non-fatal warning appears in the logs.

[smcv]

A simple workaround is to set GBM_BACKENDS_PATH=/run/host/usr/lib64/gbm, which makes things work.

Beware that if pressure-vessel learns to handle GBM modules in a similar way to how it currently handles DRI modules, this workaround will change from "makes it work" to "makes it not work".

[hoshinolina]

I think that @smcv's comment is asking for help identifying a test case where libgbm is required for a game to run as intended instead of a scenario where a non-fatal warning appears in the logs.

libgbm is required for libfunnel, which is a dependency of the tool I linked above. Without it, it does not work (and therefore users will be unable to use that tool to support PipeWire streaming from Steam apps using Spout2, like the ones I mentioned).

I'd provide the libfunnel demo apps as a native linux test case you can use, but there's another catch: steamrt3 is currently shipping an ancient libpipewire, which is also not going to work. I currently work around this by doing some positively horrendous things to link in libpipewire and all the required modules and plugins statically... I was thinking of asking for a backport, but with steamrt4 coming up, I figured it'd be easier to wait and see and use the static hack for now, and ask for a minor backport if needed for steamrt4 (for some relatively recent libpipewire fixes for proper Nvidia/explicit sync support) and drop the static hack once Proton moves over to it, rather than asking for a much larger version bump for steamrt3. Of course, libgbm backends are not something I can reasonably ship statically like I can libpipewire, so that's a bigger issue. (edit: just checked, steamrt4 has an ABI-compatible new enough libpipewire so it will work with the libfunnel test apps, though it's missing recent fixes/minor bug-related-feature addons that would be nice to have eventually, but not mandatory).

There's another conversation to be had about how to ship/integrate things like the spout2 support going forward (the current solution dumping it into an existing Proton install ad-hoc, small wine/proton core changes + simple install into WINEPREFIX only, one-line proton launcher change + WINEDLLPATH requirement, even something distributed on steam itself?, or outright merging the whole thing into proton/wine are all possibilities), but I wanted to file this bug first since this gbm issue is a problem no matter what.

A simple workaround is to set GBM_BACKENDS_PATH=/run/host/usr/lib64/gbm, which makes things work.

Beware that if pressure-vessel learns to handle GBM modules in a similar way to how it currently handles DRI modules, this workaround will change from "makes it work" to "makes it not work".

Right, that's why I'm not a fan of such hacks...

[hoshinolina]

Since steamrt4 does have a reasonable libpipewire, here's a practical repro of the issue:

(dependencies to build: meson, ninja, libgbm-dev, libdrm-dev, libvulkan-dev, libpipewire-dev, glslang, libwayland-dev, wayland-protocols)

git clone https://github.com/hoshinolina/libfunnel/
cd libfunnel
meson setup build -Degl=false
ninja -C build
<path to steamrt4>/run build/funnel-test-vk

MESA-LOADER: failed to open dri: /usr/lib64/gbm/dri_gbm.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/gbm, suffix _gbm)
funnel-test-vk: ../test-vk.c:867: main: Assertion `ret == 0' failed.

The outcome with the spout2pw setup and Proton is the same, just under a bunch more layers of complexity/wrapping.

As far as native Linux apps go, I plan to develop a Godot component for libfunnel and am in talks with related app developers to integrate support, and several have expressed interest. It's not particularly relevant for most "games" in the gaming sense, but any app likely to want to provide a dedicated video output feed for YouTube/Twitch streaming (usually without the UI and possibly with alpha with transparency) or for video mixing/productions is likely to end up using libfunnel like this, and any such apps distributed via Steam will run into the issue. This is a whole ecosystem on Windows (Spout2) and macOS (Syphon) that is essentially unfilled on Linux today due to PipeWire video being too hard to use and poorly documented, and that is what I'm hoping to fix with libfunnel.