Update debugging advice to take into account SteamLinuxRuntime
The use and debugging info in pressure-vessel is rather out of date. I wrote most of it when we were initially getting it working by hacking games' launch arguments, before the SteamLinuxRuntime and SteamLinuxRuntime_soldier compat tools, and certainly before we had any idea that we were going to run Proton in a container.
We should write debugging advice (somewhere - maybe pressure-vessel/, maybe steam-runtime.git, maybe steamlinuxruntime.git, I don't know) that is more suited to how things work today.
We don't have to do all of this at once: indeed, it's probably better if we chip away at it over time via multiple smaller MRs.
There are two main routes that are interesting for debugging:
-
It basically works, but there is a bug, and you want to diagnose it.
- The starting point is to install the SteamLinuxRuntime compat tool, and/or Proton 5.13+ with the SteamLinuxRuntime_soldier compat tool.
- First, run your game in that environment. Life is Strange episode 1 continues to be a good game to try:
- free, so every would-be contributor can try it
- single-player, so you don't have to worry about whether your debugging triggers anti-cheat mechanisms
- Linux-native, so you can compare Linux-native with Proton
- not too big
- not too demanding (works on Intel HD graphics, albeit with a low framerate)
- works in Proton
- From there, you can move on to:
- the test-UI (we need to check how much of it still works in Proton and how much of it has to be disabled because it would break the Launcher)
- getting a shell in the container:
PRESSURE_VESSEL_SHELL=instead
- using or not using the host graphics stack (as below)
- unpacking the corresponding SDK container to use instead of the Platform container
- using a custom build of the container to try out new tricks
- using a custom build of pressure-vessel instead of the one included
-
It doesn't work because your OS is too unlike our assumptions, so you can't even get a shell.
- The starting point is still to install one of the compat tools.
- From here, there's a lot of guesswork involved - this is unexplored territory, and a certain amount of psychic debugging is necessary.
- Some tricks that could be useful include:
- running pressure-vessel-wrap with something like
./run -- xterm
to take Steam and the game out of the equation, and just have the container and runtime - disabling the graphics stack from the host and using a pure soldier environment (which will result in using older graphics drivers and perhaps software GL)
- running without a runtime (if it hasn't regressed like it did recently), using your host OS for
/usr
, so that you just have the container boundary - most of what's in the current documentation, really
- running pressure-vessel-wrap with something like
Also useful to mention:
- Diagnostic tools: steam-runtime-system-info, steam-runtime-input-monitor
- Injecting commands into a Proton container with pressure-vessel-launch
- Getting debug symbols into gdb, so you can attach gdb on the host to a process in the container
/cc @denittis