Flatpak with non-default FLATPAK_GL_DRIVERS not compatible with Steam container runtime

[smcv]

Your system information

• Steam Runtime Version: soldier 0.20211027.0, scout 0.20211013.0
• Distribution: Flatpak (freedesktop.org 21.08 runtime); I tested on an Ubuntu 21.10 host, but the host OS shouldn't matter
• Link to your full system information: not provided here, I am a Steam Runtime developer and have already done initial diagnosis for this issue
• Have you checked for system updates?: no
• What compatibility tool are you using?: Steam Linux Runtime (Proton 5.13+ believed to be affected too)
• What versions are listed in SteamLinuxRuntime/VERSIONS.txt? depot 0.20210818.35, scripts 0.20210818.0-0
• What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt? depot 0.20211028.32, pressure-vessel 0.20211027.0, scripts 0.20210917.0-0, soldier 0.20211027.0

Please describe your issue in as much detail as possible:

When we use the Steam container runtime from a Flatpak app, instead of creating its own container environment (which is not allowed inside a Flatpak sandbox), pressure-vessel-wrap will ask flatpak-portal to run a new Flatpak sandbox where:

• /usr is mostly Steam Runtime 2 'soldier'
• /app is mostly empty
• /run/parent/app is populated from the same Flatpak runtime and extensions as Steam's /app
• /run/parent/usr is populated from the same Flatpak runtime and extensions as Steam's /usr
• /usr/lib/pressure-vessel/overrides is populated with symlinks into /run/parent

pressure-vessel-wrap sets up /usr/lib/pressure-vessel/overrides based on the assumption that Steam's /usr will be the same as the new sandbox's /run/parent/usr.

However, if we ran Steam with the FLATPAK_GL_DRIVERS environment variable set, we'll find that Steam's /usr uses the graphics stack specified with FLATPAK_GL_DRIVERS (the value people typically want is mesa-git), whereas the new sandbox's /run/parent/usr has the default graphics stack (typically default on Mesa-based systems). The result is that pressure-vessel's assumption is wrong and /usr/lib/pressure-vessel/overrides contains broken symlinks, leading to games that fail to launch because their required graphics drivers are missing.

This could be argued to be either a Flatpak bug or a pressure-vessel bug, but I don't know yet whether it will be possible to solve it in practice without changing both components.

Steps for reproducing this issue:

1. Run on hardware that uses Mesa graphics drivers: I used an AMD discrete GPU, but an AMD or Intel integrated GPU should behave the same
2. Have Flatpak 1.12.2 or later (this is a prerequisite for the Steam container runtime working in the Flatpak app at all)
3. Install com.valvesoftware.Steam from Flathub
4. Find out the runtime version: flatpak info -m com.valvesoftware.Steam | grep runtime= (currently 21.08)
5. flatpak --user install org.freedesktop.Platform.GL.mesa-git//21.08 (replace runtime version as required)
6. flatpak --user install org.freedesktop.Platform.GL32.mesa-git//21.08 (replace runtime version as required)
7. FLATPAK_GL_DRIVERS=mesa-git PRESSURE_VESSEL_SHELL=instead flatpak run com.valvesoftware.Steam
8. Configure a game's compatibility properties to force it to run in Steam Linux Runtime (I used DOTA 2, any native Linux game will do)
9. Try to launch that game; instead of the real game, PRESSURE_VESSEL_SHELL=instead gives you an xterm
10. In the xterm, inspect /usr/lib/pressure-vessel/overrides/lib/* and notice they contain broken symlinks to graphics drivers and graphics-driver-related libraries, pointing to paths that contain /mesa-git/
11. Still in the xterm, inspect /run/parent/usr/lib/*/GL and notice they contain the default graphics stack instead of mesa-git
12. Still in the xterm, run "$@" which is set up to run the actual game
13. The game will usually crash or otherwise fail

Workarounds

Any one of:

• Use Steam from a native OS-level package instead of via Flatpak
• Don't use FLATPAK_GL_DRIVERS to force a non-default GL stack
• Run native Linux games with no special compatibility tool, and run Windows games with Proton 5.0 or older (which doesn't use the container runtime) or with Flathub's unofficial "community" builds of Proton (ditto)

[smcv]

The more I think about this, the more I think it's a Flatpak bug and shouldn't require pressure-vessel changes.

If Flatpak had a way for pressure-vessel to add "... and use the mesa-git GL driver please" to its requests to create a new subsandbox, then it would have to consider things like whether it was an info leak for the app to be able to use that feature to enumerate all the GL drivers on the system, and whether the app could perform a path-traversal attack to read other content by claiming to be using a GL driver like ../../../../../../../../../.ssh.

It seems a lot simpler if Flatpak could store the GL driver override (if any) in the /.flatpak-info of each app sandbox, and when an app asks for a new subsandbox, always use the same override (if any) as the app that is asking for it. That would give the GL driver override the same behaviour as other app properties, like permissions.

[nanonyme]

Well, it does store information about mounted GL extensions already in /.flatpak-info including exact commits.

[smcv]

Well, it does store information about mounted GL extensions already in /.flatpak-info including exact commits.

I'm looking into whether we can make flatpak-portal ask flatpak run to use that information when setting up the subsandbox.

It's not particularly straightforward so far. There's already a way to override flatpak run's choice of commit for /app and /usr (which actually end up at /run/parent/app and /run/parent/usr when using pressure-vessel), and flatpak-portal already uses it (unless you use flatpak-spawn --latest-version or the D-Bus equivalent, which pressure-vessel deliberately doesn't do).

However, the way extensions are mounted is rather more complicated than /app and /usr, so it isn't immediately obvious how to match the information from /.flatpak-info to the extension-point that it was for.

[nanonyme]

Hmm, I thought about this more. So what about app extensions? GL32 is actually (similar to compat32) mounted as app extension which means that mount point for said things must exist under /app. Do they exist with pressure-vessel?

[smcv]

pressure-vessel asks Flatpak to use an empty /app, which is implemented as a tmpfs, so it should be possible to create mount points.

[adedomin]

I was able to work around this problem in the meantime by setting the FLATPAK_GL_DRIVERS for my user scope and restarting the flatpak portal service. This is on Fedora, so adjust as necessary.

systemctl --user set-environment FLATPAK_GL_DRIVERS=your_driver_here
systemctl --user restart flatpak-portal.service
FLATPAK_GL_DRIVERS=your_driver_here flatpak run com.valvesoftware.Steam

One could systemctl --user edit flatpak-portal.service as well for a more permanent half-solution. Hopefully this helps anyone running into this issue.

[nanonyme]

Seems worth documenting that workaround to https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/wikis/mesa-git

[1player]

Not sure if it's related, just tried mesa-git with flatpak Steam and it's failing to launch with src/steamUI/Main.cpp (387) : Assertion Failed: Error: glXChooseVisual failed

Is this the same issue, shall I open another, or shall I open one on the mesa-git-extension repo?

[kisak-valve]

Hello @1player, I'm not very familiar with flatpak packaging, but can you check if the container environment is using both org.freedesktop.Platform.GL.mesa-git and org.freedesktop.Platform.GL32.mesa-git? The most likely scenario is that you're not giving Steam a sane 32 bit OpenGL render path.

[1player]

Hello @1player, I'm not very familiar with flatpak packaging, but can you check if the container environment is using both org.freedesktop.Platform.GL.mesa-git and org.freedesktop.Platform.GL32.mesa-git? The most likely scenario is that you're not giving Steam a sane 32 bit OpenGL render path.

That was it, I forgot to RTFM and install the 32-bit version. Sorry for the noise.

[Mershl]

At the beginning of August Proton Experimental and Proton-GE started to rely on mesa 22. As runtime 22.08 (planned to arrive next week) will be the first runtime to ship with mesa 22, users of the affected Proton builds started seeing breakage over the last weeks.

The mesa-git extension (an alternate non-default flatpak gl driver) can serve as a workaround in these situations as well as take a bit of pressure of the runtime developers. @smcv If you don't mind, what are your current thoughts on https://github.com/ValveSoftware/steam-runtime/issues/474?

[smcv]

My current thoughts are that I never have enough time to write all the code that I want to write, so please don't expect me to implement complicated features on any particular timescale.

[nanonyme]

I'm still confused why Proton was updated without a gate checking user machine had new enough Mesa. This most likely affected more things than just flatpak.

[1player]

The Steam flatpak beta using 22.08 is already available, and when I asked @nanonyme if we would need the mesa-git thing again in the future, they told me it was just because Mesa 22 deprecated some hardware so freedesktop couldn't upgrade to it in a minor release. Please correct me if I'm wrong.

So will this issue still be relevant after freedesktop 22.08 releases?

[smcv]

So will this issue still be relevant after freedesktop 22.08 releases?

This is a general issue involving general Flatpak functionality. It will no longer be immediately interesting for current Proton versions after the fdo runtime 22.08 releases, but it will still be a valid issue, and I still hope to solve it eventually - but it is not straightforward, and my queue of things that I want to solve eventually is growing all the time.

[nanonyme]

It is in the sense you might still get better performance and be able to work with Mesa upstream to squish bugs if mesa-git-extension works. The extension is meant to be a development and testing tool that works ahead of runtime Mesa (which follows stable releases)

[Beryesa]

It's still broken for me :(

[nanonyme]

In case it wasn't clear: this is expected to be broken until https://github.com/flatpak/flatpak/issues/4539 is fixed. There is no point commenting it happens for you too.

[Beryesa]

Sorry, now it's clear, thanks!

[nanonyme]

There is now a new feature in flatpak that may help. It is not landing into 1.14 as part of https://github.com/flatpak/flatpak/pull/5593 as @smcv said the change is too big for a stable branch. However, latest flatpak development release 1.15.6 should contain the change and as far as I've understood could be used for testing.

[Mershl]

Did a re-test on latest Flatpak 1.15.8 and mesa-git-extension//23.08 and the issue is no longer reproduciable.

FLATPAK_GL_DRIVERS=mesa-git flatpak run com.valvesoftware.Steam is compatible with:

• first post-containerized Proton (6.3-8 tested) -> this was not working before
• official Proton latest (8.0.5 tested) -> this was not working before
• Proton Experimental (9.0-20240503b tested) -> this was not working before
• Steam Linux Runtime -> this was not working before

[smcv]

flatpak/flatpak#5278 was a 95% solution to this, and is included in Flatpak 1.15.x (and will be in the 1.16 stable branch, whenever that happens). It can fail in the rare situation that you have updated org.freedesktop.Platform.GL.mesa-git while Steam is running, but will usually work.

Resolving flatpak/flatpak#4539 would be the 100% solution, but is not straightforward. If anyone wants to work on solving that issue, please follow up there.

[nanonyme]

I think that 95% solution is perfectly acceptable from mesa-git-extension point of view unless someone we have someone volunteering. Of course some other use case might have stricter requirements.

[smcv]

first post-containerized Proton (6.3-8 tested)

FYI, Proton 5.13 was the first containerized Proton (and 5.0 was the last non-containerized one). But all containerized versions of Proton are "the same shape", so testing 5.13 is not important: if one works, usually all of them will.