flatpak: MangoHud stopped working with Proton after Steam updated onto freedesktop 23.08

[tim77]

Your system information

• Steam Runtime Version: Steam Linux Runtime 3.0. (sniper)
• Distribution: Fedora 38
• Link to your full system information: Steam Runtime Diagnostics
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton 8.0-3
• What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

  #Name   Version     Runtime Runtime_Version Comment
  depot   0.20230808.56699            # Overall version number
  pressure-vessel 0.20230804.0    scout       # pressure-vessel-bin.tar.gz
  scripts 0.20230804.0            # from steam-runtime-tools
  sniper  0.20230808.56699    sniper  0.20230808.56699    # sniper_platform_0.20230808.56699/

  Please describe your issue in as much detail as possible:

• slr-app2320-t20230908T181954.log
• Proton log: steam-2320.log

Steps for reproducing this issue:

1. Install latest MangoHud: flatpak install runtime/org.freedesktop.Platform.VulkanLayer.MangoHud/x86_64/23.08.
2. Run any game in Steam via current, stable Proton.
3. MangoHud doesn't work.

But running the same game via community Proton (com.valvesoftware.Steam.CompatibilityTool.Proton) — MangoHud works.

"Quake II Remastered" used as game for testing/debugging purposes. Game run natively Vulkan.

Previously users confirmed issue here: https://github.com/flathub/org.freedesktop.Platform.VulkanLayer.MangoHud/issues/31

[smcv]

It seems that in the sniper container as run by the diagnostic tool, MangoHud is getting loaded when we run the 32-bit version of the check-vulkan diagnostic tool:

      "graphics-details" : {
        "x11/vulkan" : {
          "messages" : [
            "[2023-09-08 18:07:29.992] [MANGOHUD] [info] [config.cpp:118] skipping config: '/usr/libexec/steam-runtime-tools-0/MangoHud.conf' [ not found ]",
            "[2023-09-08 18:07:29.993] [MANGOHUD] [info] [config.cpp:118] skipping config: '/home/tim/.var/app/com.valvesoftware.Steam/config/MangoHud/i386-linux-gnu-check-vulkan.conf' [ not found ]",
            "[2023-09-08 18:07:29.993] [MANGOHUD] [info] [config.cpp:123] parsing config: '/home/tim/.var/app/com.valvesoftware.Steam/config/MangoHud/MangoHud.conf'",
            "sh: 1: glxinfo: not found",
            "[2023-09-08 18:07:30.091] [MANGOHUD] [info] [overlay.cpp:808] Uploading is disabled (permit_upload = 0)",
            "[2023-09-08 18:07:30.202] [MANGOHUD] [error] [battery.cpp:29] No battery found",
            "[2023-09-08 18:07:30.449] [MANGOHUD] [info] [overlay.cpp:808] Uploading is disabled (permit_upload = 0)"
          ],

but when we run the corresponding 64-bit version, there are no similar messages, suggesting that for whatever reason, this is only working for 32-bit programs.

I'm unsure why that would be, because it seems you do have manifest files for both appearing inside the container:

      {
        "json_path" : "/usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d/04-i386-linux-gnu.json",
        "name" : "VK_LAYER_MANGOHUD_overlay",
        "description" : "Vulkan Hud Overlay",
        "type" : "GLOBAL",
        "api_version" : "1.3.0",
        "implementation_version" : "1",
        "library_path" : "/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/vulkan_imp_layer/04/libMangoHud.so",
        "issues" : []
      },
      {
        "json_path" : "/usr/lib/pressure-vessel/overrides/share/vulkan/implicit_layer.d/05-x86_64-linux-gnu.json",
        "name" : "VK_LAYER_MANGOHUD_overlay",
        "description" : "Vulkan Hud Overlay",
        "type" : "GLOBAL",
        "api_version" : "1.3.0",
        "implementation_version" : "1",
        "library_path" : "/usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/05/libMangoHud.so",
        "issues" : []
      },

[smcv]

The good news is that I can reproduce this behaviour with one of my usual Proton test apps (the demo version of Ghostrunner), including the surprising behaviour that MangoHud loads successfully for /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/i386-linux-gnu-check-vulkan but not for /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/x86_64-linux-gnu-check-vulkan or the game itself.

The bad news is that I can't yet see why this is the case: as far as I can see, both word-sizes ought to work equally well (if anything, maybe 32-bit should be a bit worse than 64-bit, since there's some weirdness going on with broken symlinks). I'll try to dig further into this next week.

[rowbawts]

Someone found this so it seems to already be a known issue https://github.com/flightlessmango/MangoHud/issues/1084

[smcv]

Looking at that issue report, my best guess is that the way the freedesktop.org SDK is structured (with separate search paths patched into the 32- and 64-bit libvulkan) is accidentally working around the MangoHud bug; but the Steam Linux Runtime containers can't easily take advantage of that accidental workaround because SLR needs to work everywhere (not just in Flatpak), so we have to assume an unpatched libvulkan, with the same search path for every architecture.

[tim77]

This fixed now for org.freedesktop.Platform.VulkanLayer.MangoHud//23.08 via downstream patch. Can we close this and save Steam devs time or there is still something should be done on steam-runtime side?

[smcv]

Can we close this and save Steam devs time or there is still something should be done on steam-runtime side?

This is a subtle enough issue that I'd prefer to understand it fully before closing it, in case there is something we can do in the container runtime to make this more robust - even if MangoHud has now fixed this, other Vulkan layers might have a similar problem. I've set up a test system where I intentionally haven't updated the MangoHud extension so that I can reproduce this. (Note to self: Arch Linux on AMD.)

I also saw some other weird behaviours with the 23.08 runtime (broken symlinks inside the container) which I'd prefer to understand before I close this.

[smcv]

This is a subtle enough issue that I'd prefer to understand it fully before closing it, in case there is something we can do in the container runtime to make this more robust - even if MangoHud has now fixed this, other Vulkan layers might have a similar problem.

The next betas of the soldier and sniper runtimes will contain pressure-vessel 0.20230919.0, which avoids this problem even when intentionally using the unfixed version of MangoHud.

I also saw some other weird behaviours with the 23.08 runtime (broken symlinks inside the container) which I'd prefer to understand before I close this.

Those are also fixed in pressure-vessel 0.20230919.0.

[smcv]

Fixed in yesterday's Steam Linux Runtime beta updates:

• Steam Linux Runtime 2.0 (soldier) depot 0.20230921.60881 (Steampipe build ID 12249901)
• Steam Linux Runtime 3.0 (sniper) depot 0.20230919.60634 (Steampipe build ID 12249908)

See SteamLinuxRuntime_*/VERSIONS.txt to check the version you have.

Normally I'd leave the bug open until the betas are promoted to stable, but because the MangoHud bug was fixed with a patch, I don't think this is actually going to be reproducible for any Flatpak users who are keeping their system up to date, even when using older SLR.

However, it would be great if some people who are regularly running Proton and/or Steam Linux Runtime on Flatpak could switch to the beta branches of the Steam client and whichever of the three Steam Linux Runtime tools you have installed (SLR 1.0 (scout), SLR 2.0 (soldier) and SLR 3.0 (sniper)). If you find new regressions, please report them as issues (in this project for SLR, or over in https://github.com/ValveSoftware/steam-for-linux/ for the Steam client) and then switch to the stable (non-beta) branch as a workaround. For the Steam client, if a regression makes it completely unusable, you can switch to the stable branch by deleting the file ~/.var/app/com.valvesoftware.Steam/.local/share/Steam/package/beta.

Switching to the beta branch of one of the SLR tools is the same as switching to the beta of a game, except that instead of looking for the game in your Steam library, you'd look for the "Steam Linux Runtime" compatibility tools.

[smcv]

@kisak-valve, I think we can close this now.