MangoHud is not shown when ticked in "GAME MENU", but works as "mangohud %command%"

[FLAGEL]

System Information

[1] Flatpak: com.valvesoftware.Steam 1.0.0.78 [2] Flatpak: com.valvesoftware.Steam.Utility.steamtinkerlaunch 14.0.20231209-1, GE-Proton8-25 [3] Flatpak: org.freedesktop.Platform.VulkanLayer.MangoHud 0.7.0 [4] Host: Arch Linux host 6.6.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 21 Dec 2023 19:01:01 +0000 x86_64 GNU/Linux [5] Host packages: flatpak 1:1.15.6-1, mangohud 0.7.0-2

Issue Description

It seems that MangoHud is not shown for some games when ticked under "GAME MENU". In this specific case Worms Armageddon. I am using a clean install and no setting has been changed except setting GE-Proton8-25 as "Proton version". MangoHud does show when using mangohud %command% as a Steam launch option (then unticked under "GAME MENU") - see attached screenshot.

Logs

Relevant steamtinkerlaunch.log is attached. but I assume the key line is: Thu Jan 4 11:55:45 PM EET 2024 SKIP - prepareLaunch - USEMANGOHUD is enabled, but mangohud binary '/home/user/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Worms Armageddon/none' not found - disabling USEMANGOHUD

Mangohud bin is found here:

[📦 com.valvesoftware.Steam ~]$ find / -iname '*mangohud*'
/usr/lib/extensions/vulkan/MangoHud
/usr/lib/extensions/vulkan/MangoHud/bin/mangohud

Edit: I can now see that "MangoHud binary" under "GAME MENU" only shows "(None)".

Attachments

steamtinkerlaunch.log

[sonic2kk]

Edit: I can now see that "MangoHud binary" under "GAME MENU" only shows "(None)".

That's probably the issue, you need to select the MangoHud binary so that SteamTinkerLaunch can find and use it. You cannot use MangoHud when SteamTinkerLaunch cannot find it of course, and it's telling you it cannot find it :-) As you noted:

Thu Jan 4 11:55:45 PM EET 2024 SKIP - prepareLaunch - USEMANGOHUD is enabled, but mangohud binary '/home/user/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Worms Armageddon/none' not found - disabling USEMANGOHUD

In some cases STL cannot find the binary or doesn't have permission to read the directory that MangoHud is in. That's why it gives you the option to select it or to manually change the binary if you ever wanted to (such as using a non-flatpak version, if that's possible at all).

Select the binary on the main menu or edit in the config file, and your issue should be resolved. If necessary, you can manually edit the permissions of the STL Flatpak if it doesn't have permission to access the folder where MangoHud is installed to.

This is not a bug, this is user-error, so closing.

[FLAGEL]

Thanks for the pointers! :-) After going down the rabbit hole it has become clear that this is a STL-specific $PATH bug. TLDR: Jump to "The core issue" below.

In the "GAME MENU" > "MangoHud binary" drop-down list there is no other choice but "(None)". Manually changing the game-specific config makes MangoHud work:

[user@host steamtinkerlaunch]$ grep -i mahu default_template.conf 
MAHUBIN=""
[user@host steamtinkerlaunch]$ grep -i mahu gamecfgs/id/217200.conf 
#MAHUBIN="/home/user/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Worms Armageddon/none"
MAHUBIN="/usr/lib/extensions/vulkan/MangoHud/bin/mangohud"

Which makes sense as the mangohud binary is available and accessible:

[📦 com.valvesoftware.Steam Worms Armageddon]$ ls -la /usr/lib/extensions/vulkan/MangoHud/bin/mangohud
-rwxr-xr-x 2 nfsnobody nfsnobody 887 Jan  1  1970 /usr/lib/extensions/vulkan/MangoHud/bin/mangohud

From the OP's screenshot, Steam is clearly able to locate the mangohud binary, even when command -v mangohud returns empty. By overriding the default Flatpak $PATH from PATH=/app/bin:/app/utils/bin:/usr/bin to PATH=/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/ we make command work as intended:

[📦 com.valvesoftware.Steam steamapps]$ command -v mangohud
/usr/lib/extensions/vulkan/MangoHud/bin/mangohud

Using steamtinkerlaunch code line 3134 (if [ -z "$MAHUBIN" ] ; then MAHUBIN="$(command -v "$MAHU")"; fi) as a reference, the below should work (but it does not):

[user@host ~]$ flatpak run --branch=stable --arch=x86_64 --command=/bin/bash --file-forwarding com.valvesoftware.Steam
[📦 com.valvesoftware.Steam ~]$ grep -i mahubin /home/user/.var/app/com.valvesoftware.Steam/.config/steamtinkerlaunch/default_template.conf
MAHUBIN=""
[📦 com.valvesoftware.Steam ~]$ grep -i mahubin /home/user/.var/app/com.valvesoftware.Steam/.config/steamtinkerlaunch/gamecfgs/id/217200.conf
MAHUBIN=""
[📦 com.valvesoftware.Steam ~]$ echo $PATH
/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/
[📦 com.valvesoftware.Steam ~]$ command -v mangohud
/usr/lib/extensions/vulkan/MangoHud/bin/mangohud
[📦 com.valvesoftware.Steam ~]$ steam &
[1] 5
[📦 com.valvesoftware.Steam ~]$ INFO:root:https://github.com/flathub/com.valvesoftware.Steam/wiki
INFO:root:Will set XDG dirs prefix to /home/user/.var/app/com.valvesoftware.Steam
DEBUG:root:Checking input devices permissions
INFO:root:Overriding TZ to Europe/Tallinn
DEBUG:root:Addding /usr/lib/extensions/vulkan/MangoHud/bin to PATH
DEBUG:root:Addding /usr/lib/extensions/vulkan/gamescope/bin to PATH

The core issue: Steam Flatpak adjusts its $PATH (see two last lines above) when initializing. Reading the log it is clear that STL does its own $PATH tinkering in function emptyVars- which is where the core issue lays:

Sat Jan  6 18:00:10 EET 2024 INFO - emptyVars - Emptied some original variables as they slowdown several system calls when started from steam
Sat Jan  6 18:00:10 EET 2024 INFO - emptyVars - Set $PATH to '/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/:/usr/lib/extensions/vulkan/MangoHud/bin:/usr/lib/extensions/vulkan/gamescope/bin::/app/utils/bin/'
[...]
Sat Jan  6 06:00:30 PM EET 2024 SKIP - prepareLaunch - USEMANGOHUD is enabled, but mangohud binary '' not found - disabling USEMANGOHUD

The issues is likely the :: above that negates a new $PATH from taking effect:

[📦 com.valvesoftware.Steam steamapps]$ echo $PATH
/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/
[📦 com.valvesoftware.Steam steamapps]$ export $PATH=/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/:/usr/lib/extensions/vulkan/MangoHud/bin:/usr/lib/extensions/vulkan/gamescope/bin::/app/utils/bin/
bash: export: `/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/=/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/:/usr/lib/extensions/vulkan/MangoHud/bin:/usr/lib/extensions/vulkan/gamescope/bin::/app/utils/bin/': not a valid identifier
[📦 com.valvesoftware.Steam steamapps]$ echo $PATH
/app/bin:/app/utils/bin:/usr/bin:/usr/lib/extensions/vulkan/MangoHud/bin/

[sonic2kk]

Thanks for the investigation work!

SteamTinkerLaunch doesn't have a drop-down for selecting the path, it's a file selection box, just to clarify.

From the OP's screenshot, Steam is clearly able to locate the mangohud binary,

That's not quite what's happening. Steam isn't locating it, the environment is. SteamTinkerLaunch doesn't append mangohud, it finds and appends the exact path. It isn't quite right to say Steam is finding it, Steam is just running the command as-is.

The logic in the STL check you called out seems right. The path you showed looks invalid, the :: means there is a blank path section. Indeed that would probably mean a new path cannot be set using this.

I don't think STL can do anything about this, this seems like some kind of Steam Flatpak-specific issue. I don't use or maintain the Flatpak portion of STL so I can't say for sure.

In the meantime, selecting a binary manually should work, either from the UI or by editing the config file as you described.

cc @HanPrower in case you have anything to add here.

[FLAGEL]

SteamTinkerLaunch doesn't have a drop-down for selecting the path, it's a file selection box, just to clarify.

Understood. File selection did not seem to work for me - hence the manual config edit. Which could make sense if $PATH is broken.

Steam isn't locating it, the environment is. SteamTinkerLaunch doesn't append mangohud, it finds and appends the exact path. It isn't quite right to say Steam is finding it, Steam is just running the command as-is.

You are of course right, poor description on my part.

I don't think STL can do anything about this, this seems like some kind of Steam Flatpak-specific issue. I don't use or maintain the Flatpak portion of STL so I can't say for sure.

I think the Flatpak environment brings forth the bug, but I suspect the bug is caused by line 24417 to 24419 in STL:

FPPATH="/app/utils/bin/"
if [ -d "$FPPATH" ]; then
PATH="$STLPATH:$FPPATH"

The above indicates that an extra : is injected without checking if the last character of $STLPATH already is a :, leading to :: in select cases. I could unfortunately not verify this as STL in a Flatpak is writeread-only (typo).

I have in the past tried (and failed) to build a script of similar size - so I know what a pain it can be. Thank you for your efforts and time!

[sonic2kk]

I think the Flatpak environment brings forth the bug, but I suspect the bug is caused by line 24417 to 24419 in STL:

Oh! This is a great catch, I wonder if PATH="${STLPATH%:}:$FPPATH" would suffice (uses parameter expansion to remove a trailing colon if present). I believe it should work:

PATH="/home/gaben/games:/run/media/gaben/BigDrive/Games:"
# Prints "/home/gaben/games:/run/media/gaben/BigDrive/Games" -- Removes trailing colon
echo "${PATH%:}"

PATH="/home/gaben/games:/run/media/gaben/BigDrive/Games"
# Prints "/home/gaben/games:/run/media/gaben/BigDrive/Games" -- Same as above, still preserves all colons that are not trailing even if there is no trailing colon
echo "${PATH}"

I don't have a Flatpak environment set up to test, but if it's easy to edit the STL script in Flatpak, you could edit I think Line 24419 to be the following:

PATH="${STLPATH%:}:$FPPATH"

If this works, since this check should be specific to Flatpak it should be safe to commit this change without affecting any other aspects of STL. If it does work, you are free to submit a PR for it yourself too since you helped in diagnosing the issue!

Small edit: If I understood correctly, the trailing space is in STLPATH I also just saw this:

I could unfortunately not verify this as STL in a Flatpak is write-only.

Sorry I missed this, is it possible to change the write permissions? If I recall correctly, other Flatpaks can be edited (I think I recall being able to edit the Python code for the ProtonUp-Qt Flatpak for some debugging). Just double-checked and that project can be edited, so I'm not sure why STL couldn't be.

---

I have in the past tried (and failed) to build a script of similar size - so I know what a pain it can be. Thank you for your efforts and time!

No problem :-) Thank you for helping to find the issue! STL Flatpak doesn't get too many bug reports so I appreciate the time you took.

Re-opening because I jumped the gun a little and incorrectly put this down to user-error.

[sonic2kk]

If the STL Flatpak cannot be edited you could open an issue over at flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch requesting that it be editable (if a user is able to find the script they are probably adept enough to know what they're doing when tinkering with it).

[sonic2kk]

The change required here should be straightforward but it would need verification that it works as expected and doesn't break any existing functionality. The Flatpak work here was done a very long time ago and no one has reported issues yet, so I would like to be cautious that this change won't regress anything that relied on this (seemingly faulty) logic.

I think I'll open an issue on the Flatpak repo summarising the findings here and linking back here, and perhaps get the Flatpak maintainer's opinion. If deemed acceptable we'll get the fix merged in here. STL Flatpak will likely be updated to include it relatively soon afterwards since this change is directly related to it :-)

---

EDIT: Corresponding SteamTinkerLaunch Flatpak issue: https://github.com/flathub/com.valvesoftware.Steam.Utility.steamtinkerlaunch/issues/137

[sonic2kk]

I will push the change to the path generation, and once the Flatpak is updated to use the newer code, you can re-test and see if it resolves the problem :slightly_smiling_face:

[sonic2kk]

Change was pushed in v14.0.20230110-1 (07edefb). Once the Flatpak has been updated to this version, you can re-test and see if it fixes the problem.

For what it's worth, the Flatpak maintainer couldn't reproduce the problem, and we suspect this may be an edge-case. As you noted it may be to do with however Steam Flatpak has set the PATH in your Flatpak environment.

[sonic2kk]

The Flatpak has been updated, please re-test when you can 🙂