Having a Xvfb server running at DISPLAY=:99 prevents games from starting

[yshui]

Your system information

• Steam Runtime Version:
• Distribution (e.g. Ubuntu 18.04):
• Link to your full system information (Help -> System Information) in a Gist:
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton 5.13+
• If you are using Steam Linux Runtime, or Proton 5.13 or newer: What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt?

  #Name   Version         Runtime Runtime_Version Comment
  depot   0.20220804.66                   # Overall version number
  pressure-vessel 0.20220803.0
  scripts v0.20220803.0-0-gbca628e                        # Entry point scripts, etc.
  soldier 0.20220803.0    soldier 0.20220803.0    # soldier_platform_0.20220803.0/
  

Please describe your issue in as much detail as possible:

I happen to have a Xvfb running with DISPLAY=:99, and I noticed none of the games that use Proton would start. I had to stop Xvfb for things to work again.

I noticed game launched via Proton has their DISPLAY set to 99.0

Steps for reproducing this issue:

1. Start xvfb, e.g. xvfb-run -n 99 xclock
2. Start a game in steam

Other info

I think pressure-vessel sets DISPLAY to 99.0, I don't know why. But maybe it should check if 99 is already being used?

[RyuzakiKK]

The system responsible to set up a container environment for Proton is Pressure Vessel, and its logic was mostly adapted from Flatpak.

As you realized, Flatpak tries to use the socket :99 and it fails if it was already in use by something else. This issue was tracked upstream in https://github.com/flatpak/flatpak/issues/3357

[smcv]

More specifically, the problem seems to be that if there's an abstract socket @/tmp/.X11-unix/X99 on the host system, libX11 inside the container will prefer to connect to that, whereas what we want it to do is connect to the /tmp/.X11-unix/X99 socket inside the container.

[yshui]

Hmm, since steam provides its own runtime, maybe we can patch libX11 (and I think libxcb too), to have it not connect to the abstract socket?

[yshui]

I think we just need to remove this line: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/blob/master/configure.ac#L148

[smcv]

Sorry, that workaround can work for Flatpak but not for the Steam container runtime. Because your graphics drivers depend on libX11/libxcb (in practice libGLX.so.0 does), we have to borrow the host OS's libX11/libxcb (which we don't control) whenever they are newer than the container's (which in practice they are).

[smcv]

https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/merge_requests/484

[smcv]

If you want to try out a proposed solution to this and you're comfortable with using prerelease software, you can replace SteamLinuxRuntime_soldier/pressure-vessel with the result of unpacking this: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/99708/artifacts/raw/_build/production/pressure-vessel-bin.tar.gz

Use Steam's "Verify Files" feature to go back to the official version.

[yshui]

@smcv I can confirm it works :tada:

Out of curiosity, may I ask why is this not done originally? Feels like preserving the display number would be the straightforward choice, and using a alternative number feels like it's trying to mitigate some kind of security risk. Is this just happenstances?

[smcv]

Out of curiosity, may I ask why is this not done originally?

The container setup code is borrowed from Flatpak, which is known to work on lots of systems, and this particular part of it hadn't been causing problems until now.

For the code from Flatpak, we'll diverge if there's a reason why we need to, but we don't diverge if it isn't necessary (even if Flatpak's reasons for a particular design choice don't actually apply to us), to minimize the time/effort required to synchronize bug fixes to and from Flatpak.

I don't know specifically why Flatpak was using :99. The relevant code has been there since the first ever commit to xdg-app (the original name for what's now Flatpak). If it was intended as a security mitigation, then that reason isn't applicable to the Steam container runtime, which isn't designed to be a security boundary (unlike Flatpak).

[smcv]

Today's SteamLinuxRuntime_soldier and SteamLinuxRuntime_sniper betas contain the same solution to this as the prerelease described in https://github.com/ValveSoftware/steam-runtime/issues/524#issuecomment-1209638215. This change will land in the stable versions of soldier and sniper in a future update, when it has had more testing. Please use "verify files" to remove the prerelease, then see https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#using-a-beta-or-an-older-version if you are interested in trying the beta.

You can identify a version with this fix by seeing pressure-vessel 0.20220823.0 or later in VERSIONS.txt.

For Flatpak users, Flatpak 1.14.0 includes a similar change.

[smcv]

This change will land in the stable versions of soldier and sniper in a future update, when it has had more testing

This happened a few days ago.

[kisak-valve]

Thanks, closing as fixed.