search

ValveSoftware / steam-runtime

A runtime environment for Steam applications
Other
1.2k stars 86 forks source link

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

Open smcv opened 3 years ago

smcv commented 3 years ago

Your system information

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:

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:

smcv commented 3 years ago

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 commented 3 years ago

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

smcv commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

1player commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

It's still broken for me :(

nanonyme commented 2 years ago

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 commented 2 years ago

Sorry, now it's clear, thanks!

nanonyme commented 11 months ago

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 commented 6 months ago

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:

smcv commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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.