search

sonic2kk / steamtinkerlaunch

Linux wrapper tool for use with the Steam client for custom launch options and 3rd party programs
GNU General Public License v3.0
2.12k stars 71 forks source link

mangohud-git AUR doesn't work with steamtinkerlaunch #733

Closed zany130 closed 1 year ago

zany130 commented 1 year ago

System Information

Issue Description

launching STL with mangohud enabled in STL settings causes games (tried Cold Steel 4 and A Hat in Time) to crash

Running the game without STL and mangohud added to the launch commands does work however

Logs

steamtinkerlaunch.log steam-1198090.log STL-1198090.log

sonic2kk commented 1 year ago

Ah, this was probably broken as part of #732 (though in my tests yesterday it worked...)

Will investigate now, thanks!

sonic2kk commented 1 year ago

Huh, it works fine on my end (Cookie Clicker, Sonic Adventure 2).

I'm going to test A Hat in Time now, but one thing I did notice is that I am using Proton 7.0-5 and not Proton Next (or Proton 7.0-6 stable, which was released today). Could you try with a different version of Proton (e.g. an older GE release) and see if you still have the crash? Or Proton 7.0-5 if it's available.

I'm going to try A Hat in Time with Proton 7.0-5 and see if it works, and if it does I'll try updating Proton and seeing if it breaks :slightly_smiling_face:

For reference, the start commands look valid, so perhaps this isn't related to #732 after all.

Your start command: Full start command is '/usr/bin/mangohud /home/zany130/.local/share/Steam/steamapps/common/Proton Next/proton waitforexitandrun /home/zany130/.local/share/Steam/steamapps/common/The Legend of Heroes Trails of Cold Steel IV/bin/Win64/ed8_4_PC.exe -latest'

My start command: Full start command is '/usr/bin/mangohud /run/media/emma/BigSSD/Games/steamapps/common/Proton 7.0/proton waitforexitandrun /run/media/emma/500GB SSD/Games/steamapps/common/Cookie Clicker/Cookie Clicker.exe --in-process-gpu --process-start-args -disable-features=HardwareMediaKeyHandling

zany130 commented 1 year ago

I think its because of Proton 7.0-6 specifically they're maybe some change with SLR

Get the same issue on stable so don't think its a regression in STL

oh strange yeah why is it saying Proton Next and not 7.0 🤔

sonic2kk commented 1 year ago

SteamTinkerLaunch + Proton 7.0-6e is working fine for me with A Hat in Time as well: startGame - Full start command is '/usr/bin/mangohud /run/media/emma/BigSSD/Games/steamapps/common/Proton 7.0/proton waitforexitandrun /run/media/emma/BigSSD/Games/steamapps/common/HatinTime/Binaries/Win64/HatinTimeGame.exe'

Perhaps the issue is a Proton version mismatch that isn't being correctly resolved? I don't think STL can resolve mismatches between Proton Next versions, so it may be looking for a Proton version that doesn't exist! This could be an interesting catch. Based on:

Running the game without STL [...] oh strange yeah why is it saying Proton Next and not 7.0

sonic2kk commented 1 year ago

Huh, Proton Next's internal name is Proton 7.0-6e. After installing Proton Next, in a fresh ProtonCSV.txt (at /dev/shm/steamtinkerlaunch) I have two entries for Proton 7.0-6e:

However, using either entry in the Proton version dropdown seems to work fine for me, with and without MangoHUD. So I am not sure if this is really causing issues, perhaps it's just an interesting quirk. It also means that STL should already be able to handle mismatches with Proton Next versions if they don't have a special name (I assume it would have -next somewhere in the name). It should be able to resolve it like a regular Proton version mismatch, so I don't think that's the problem here...

zany130 commented 1 year ago

Deleted Proton Next, and now it shows 7.0 like it should but it is still crashing for me in A Hat in Time which is strange

here are logs for the hat in time run steam-253230.log steamtinkerlaunch.log

sonic2kk commented 1 year ago

I noticed the most recent log at least has the following line:

Fri Feb  3 07:57:29 PM EST 2023 ERROR - startGame - Could not determine pid of '/home/zany130/.local/share/Steam/steamapps/common/Proton 7.0/dist/bin/wineserver'

Could this be the same issue as #730?

Further logging:

Fri Feb  3 07:57:09 PM EST 2023 INFO - startGame - ## ORIGINAL INCOMING LAUNCH COMMAND: 'waitforexitandrun /mnt/GAMES/SteamLibrary/steamapps/common/HatinTime/Binaries/Win64/HatinTimeGame.exe'
Fri Feb  3 07:57:09 PM EST 2023 INFO - startGame - ## STL LAUNCH COMMAND: '/usr/bin/gamemoderun /usr/bin/gamescope -w 3840 -h 2160 -W 3840 -H 2160 -e -- /usr/bin/obs-gamecapture /usr/bin/mangohud /home/zany130/.local/share/Steam/ubuntu12_32/reaper SteamLaunch AppId=253230 -- /home/zany130/.local/share/Steam/steamapps/common/Proton 7.0/proton waitforexitandrun /mnt/GAMES/SteamLibrary/steamapps/common/HatinTime/Binaries/Win64/HatinTimeGame.exe'
Fri Feb  3 07:57:09 PM EST 2023 INFO - startGame - ## GAMESTART HERE ###
Fri Feb  3 07:57:09 PM EST 2023 INFO - restoreOrgVars - Restoring previously cleared Variables
Fri Feb  3 07:57:10 PM EST 2023 WAIT - getGameWindowPID - Sec 1/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:11 PM EST 2023 WAIT - getGameWindowPID - Sec 2/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:12 PM EST 2023 WAIT - getGameWindowPID - Sec 3/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:13 PM EST 2023 WAIT - getGameWindowPID - Sec 4/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:14 PM EST 2023 WAIT - getGameWindowPID - Sec 5/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:15 PM EST 2023 WAIT - getGameWindowPID - Sec 6/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:16 PM EST 2023 WAIT - getGameWindowPID - Sec 7/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:17 PM EST 2023 WAIT - getGameWindowPID - Sec 8/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:18 PM EST 2023 WAIT - getGameWindowPID - Sec 9/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:19 PM EST 2023 WAIT - getGameWindowPID - Sec 10/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:20 PM EST 2023 WAIT - getGameWindowPID - Sec 11/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:21 PM EST 2023 WAIT - getGameWindowPID - Sec 12/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:23 PM EST 2023 WAIT - getGameWindowPID - Sec 13/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:24 PM EST 2023 WAIT - getGameWindowPID - Sec 14/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:25 PM EST 2023 WAIT - getGameWindowPID - Sec 15/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:26 PM EST 2023 WAIT - getGameWindowPID - Sec 16/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:27 PM EST 2023 WAIT - getGameWindowPID - Sec 17/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:28 PM EST 2023 WAIT - getGameWindowPID - Sec 18/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:29 PM EST 2023 WAIT - getGameWindowPID - Sec 19/20 Game Window with pwd '/mnt/GAMES/SteamLibrary/steamapps/common/HatinTime' not yet in front
Fri Feb  3 07:57:29 PM EST 2023 INFO - startGame - Symlink '/home/zany130/.config/steamtinkerlaunch/logs/gamelaunch/title/HatinTime.log' already exists
Fri Feb  3 07:57:29 PM EST 2023 ERROR - startGame - Could not determine pid of '/home/zany130/.local/share/Steam/steamapps/common/Proton 7.0/dist/bin/wineserver'
Fri Feb  3 07:57:29 PM EST 2023 INFO - startGame - ## GAMESTOP after '20' seconds playtime

Note how STL waits 20 seconds to find the PID and then closes after 20 seconds of playtime. Based on this timing, and log line similar to that of the previous issue, I wonder if the wineserver PID is causing the problem here...

zany130 commented 1 year ago

steam-253230.log steamtinkerlaunch.log

Yeah looks like there where lingering wine processes. I rebooted to make sure all that gets cleared, but the game still crashes

I also tried disabling all other options other than mangohud and protonlog just to make sure something like gamescope wasn't the issue

EDIT: maybe we aren't using the same mangohud version? I have the latest git 0.6.8.r69.g87cc5c6-1

sonic2kk commented 1 year ago

The new log doesn't show any PID errors, actually it finds the PID which is a good sign :-)

The launch command still looks fine, and with various different Proton versions, everything still works fine on my system. Do your games work without MangoHud but with SteamTinkerLaunch?

Also, just out of curiosity:

EDIT:

maybe we aren't using the same mangohud version? I have the latest git 0.6.8.r69.g87cc5c6-1

I'll try the version of mangohud in the repos and a version built from latest git (mangohud-git on AUR probably) and see if I can re-create the problem. If this causes problems. Though it's strange, I wonder why MangoHud would work without STL but crashes with it...

zany130 commented 1 year ago 
which mangohud
/usr/bin/mangohud

yeah if I disable mangohud in STL settings the game launches fine same on v12 stable works fine with mangohud disabled but does not with it enabled

yeah this issue started happening after I updated my system( mangohud gamescope and STL where updated there) and i also got the updated proton on steam

will try booting a snapshot i have before the update to see if it helps...

sonic2kk commented 1 year ago

MangoHud 0.6.8-5 from AUR works fine for me.

I skipped the MangoHud-git AUR package as it was a couple of commits out-of-date from the commit your version mentions: g87cc5c6 (I guess maybe Choaitc AUR is more up-to-date :sweat_smile:). It also works fine on my system.

v12 stable works fine with mangohud disabled but does not with it enabled

This is very suspicious, v12 should definitely be working fine... This certainly sounds like some kind of MangoHud problem somewhere but I'm not sure where or how. I'm using vanilla Arch Linux on both my PC and laptop. My PC has a few pending updates, the most likely that could be causing issues is a vulkan-radeon update (iirc we both have AMD GPUs so you're using Mesa too right?). Maybe there's been a graphics driver regression?

zany130 commented 1 year ago

The chaotic aur is a prebuilt from the aur . So it's should be the same if anything the chaotic aur version can sometimes be more out to date if the builder fails to build from the aur for what ever reason

Currently I'm installing from the aur which despite showing an older version in PKGBUILD should build the latest version since it's configured to always check out the latest master

EDIT: Looks like the mangohud update is what caused this issue. I restored to before the updates and steamtinkerlaunch + mangohud worked

updated just mangohud and now steamtinkerlaunch + mangohud does not work but just mangohud in the steam launch options does not which is strange

so the mangohud update broke a hat a time and cold steel but only when ran through steamtinkerlaunch

also here are my sys specs

inxi -b
System:
  Host: Garuda-Linux Kernel: 6.1.9-273-tkg-bmq arch: x86_64 bits: 64
    Desktop: KDE Plasma v: 5.26.5 Distro: Garuda Linux
Machine:
  Type: Desktop Mobo: ASRock model: X470 Taichi serial: <superuser required>
    UEFI: American Megatrends v: P4.90 date: 05/18/2022
CPU:
  Info: 6-core AMD Ryzen 5 5600X [MT MCP] speed (MHz): avg: 4232
    min/max: 2200/4650
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M]
    driver: amdgpu v: kernel
  Display: wayland server: X.org v: 1.21.1.6 with: Xwayland v: 22.1.7
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu resolution:
    1: 2048x864 2: 1536x864 3: 1536x864
  API: OpenGL v: 4.6 Mesa 22.3.3 renderer: AMD Radeon RX 6700 XT (navi22
    LLVM 15.0.7 DRM 3.49 6.1.9-273-tkg-bmq)
Network:
  Device-1: Intel Dual Band Wireless-AC 3168NGW [Stone Peak] driver: iwlwifi
  Device-2: Intel I211 Gigabit Network driver: igb
Drives:
  Local Storage: total: 2.96 TiB used: 2.33 TiB (78.9%)
Info:
  Processes: 476 Uptime: 14m Memory: 31.27 GiB used: 12.14 GiB (38.8%)
  Shell: fish inxi: 3.3.24
sonic2kk commented 1 year ago

updated just mangohud and now steamtinkerlaunch + mangohud does not work but just mangohud in the steam launch options does not which is strange

Gosh this is really strange. The launch commands didn't change and even though STL git did have some changes, this even affects previous versions of STL. What's even stranger is that even with MangoHud built from git (manually using the build script), I don't have any issues.

I tried Cookie Clicker and A Hat in Time without STL, using Proton 7.0-6, and I tried mangohud %command% as well as /usr/bin/mangohud %command% (the latter being what STL runs) and both worked fine.

It might be a silly question but are you using the same Proton version with and without STL? Also, does this affect GE-Proton + STL + MangoHud as well?

To be completely honest I don't know why this would only work without STL... Perhaps your hunch earlier about the Steam Linux Runtime causing issues could be a clue? You could try fiddling with some of the SLR settings in STL and seeing if that changes anything.

Also, it looks like our specs are fairly similar (I have an AMD CPU + GPU, and I also use Plasma Wayland on Arch). We are also using the same Mesa version, even though I have a bugfix driver update pending for Mesa I am currently on the same version as you, 22.3.3. The only real difference I can see is that I'm using the Zen kernel instead of the TkG kernel. So I don't think there should be anything different on your system really...

This is a complete shot-in-the-dark, but perhaps newer versions of MangoHud are looking for a dependency that is only satisfied when launching through Steam, but that it can't find on your system when using SteamTinkerLaunch? I am honestly not sure at all. I haven't touched any SLR settings in STL, they are all default for me:

image

Hmm, a strange one indeed!

sonic2kk commented 1 year ago

Hmm, I just tried fiddling with the SLR settings and it made no difference on my end. MangoHud still works fine for me.

I'll test on my laptop and Steam Deck whenever I have the chance (hopefully tomorrow :slightly_smiling_face:) and see if I run into any issues.

It's so strange that this is exclusive to using newer MangoHud versions and only with SteamTinkerLaunch, and that it affects previous releases of SteamTinkerLaunch. What the heck...

zany130 commented 1 year ago

SLR doesn't work if you use the default options (reported this back when frostworx was the maintanier) You have to use the force options although that doesn't seem to be working on proton 7.0-6. You can tell because the proton log from steam has 

depot: 0.20230111.85
pressure-vessel: 0.20221215.0 scout
scripts: 0.20221215.0
soldier: 0.20230109.1 soldier 0.20230109.1

while steamtinkerlaunch proton log does not have that section in the beginning of the log.

also there is a lot of LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored on STL log but steam log does not have that

Thats why I initially thought it was SLR related

sonic2kk commented 1 year ago

I tried running with and without STL and I see the ELF errors you're talking about only when using STL.

However strangely this doesn't impact anything it seems at least on my end. So I don't think this related to SLR in the end.

(Also, nice tip about the SLR not working, I guess I'll take a look at why it may not be working with Proton 7.0-6. I have only tested with some native games and it worked before, never tried with Proton).

zany130 commented 1 year ago

seems like building mangohud manualy from source works for me. Going back to the aur version (not the chaotic) it doesn't work

but again this is only with STL without STL the aur version works fine which is strange

sonic2kk commented 1 year ago

Oh wow, I can reproduce it with the MangoHud-git AUR package but not with stable MangoHud from the AUR or MangoHud from git! Sorry for not testing that earlier, I really didn't think there would've been much point as I thought they would've been the same pretty much...

What in the heck, why on earth does this only affect SteamTinkerLaunch... Their PKGBUILD had a couple of changes recently but I'm sure what could be breaking only SteamTinkerLaunch.

Well thanks for figuring this out, and sorry for not being thorough enough in exploring the AUR package sooner :sweat_smile: I wonder if it's worth leaving a comment with the maintainer of this package, in case something is up? I tested with SuperTuxKart (OpenGL), glxgears (OpenGL) and vkCube (Vulkan) running from terminal in my home directory, and they launched just fine, so it's not like it's an issue with running outside of Steam.

I would say something is definitely up with how the git package is build specifically, as building from source and using MangoHud stable from the AUR works fine.

sonic2kk commented 1 year ago

Left a comment on the AUR package just in case the author or another user could offer any further advice on why it may be failing. Perhaps there is a simple solution on our end, or perhaps there is a super edge-case issue with however MangoHud-git is being built.

zany130 commented 1 year ago

Sorry for not testing that earlier, I really didn't think there would've been much point as I thought they would've been the same pretty much...

No worries, I thought the same, and I'm still in disbelief of this issue, but something I learned over the many many strange bugs I had over the years is never to assume anything. Even the most unlikely configuration or package version can make a difference.

Good to know its not just me and I'm not crazy or something (well don't know about that last part I am zany130 after all🤪

sonic2kk commented 1 year ago

I'll leave this issue open until there's more of a resolution upstream, in case there's some kind of variable or other option we need to export from STL to fix this. If there's no response upstream or no resolution after a while, I will just note on the wiki that there can be issues with MangoHud-git. I feel a bit bad about asking upstream because the maintainer has no association with this project really, but I can't figure out what STL would be doing that would only break this one particular package.

Even the most unlikely configuration or package version can make a difference

A certain insane mad scientist in a game I recently played once said that every possibility should be considered, perhaps I should've learned from him 😆

sonic2kk commented 1 year ago

Upstream commented saying it could be an issue with the latest changes they made, but that they can't roll them back yet because of some issues.

If you're able to you could try an older version of the AUR package (which should still build from git I'm pretty sure) and see if that fixes it. That will help us narrow down if it really is a packaging issue :-)

EDIT: Ugh, accidentally closed the issue, sorry about that... Also just updated the title to be a bit more accurate based on what we were able to investigate!

zany130 commented 1 year ago

Can you still reproduce this issue? I can't anymore, which is really strange. Just magically started working again. There haven't been any updates to either the PKGBUILD on the aur or mangohud itself, yet it is working now. Didn't do any system updates either 😖

sonic2kk commented 1 year ago

Huh, it magically works for me too. I also can't see any changes. I also verified the version I have installed is the same as the one we had from testing earlier.

I haven't done any updates to my system since last night. Absolutely nothing has changed on my end, and I haven't pushed any changes to STL either. I wonder what changed here... Maybe we are going crazy after all haha.

I'll report this back to upstream, they didn't note any changes either and in fact said they couldn't change anything yet because their PC is broken. I'll also close this issue as it appears to be resolved? I hope? Maybe? :sweat_smile: