Wait Requester and CrushGuess Requester Doesn't Show Up

[hftsai256]

System Information

• SteamTinkerLaunch version: v11.12.20221030-3
• Distribution: SteamOS on Steam Deck
• Installation Method: Manual installed from script available in Release section

Issue Description

This is a follow-up issue occurred after #642 was resolved by removing running environments under $HOME/.config/steamtinkerlaunch. The wait requester window no longer shows up when launching win32 games through Steam Compatibility Tool.

CrashGuess Requester was also invoked by looking into the launch log, but not shown as well.

Following measures have been taken so far:

• Purged $HOME/stl folder and reinstall everything (probably?).
• Checked $HOME/.local/share/Steam/compatibilitytools.d/SteamTinkerLaunch/ but nothing looks weird to me:

(deck@steamdeck SteamTinkerLaunch)$ cat toolmanifest.vdf 
"manifest"
{
  "commandline" "/steamtinkerlaunch run"
  "commandline_waitforexitandrun" "/steamtinkerlaunch waitforexitandrun"
}

• Disable and re-enable Wait Requester with command steamtinkerlaunch wr e|s|u
• Tested with and without external monitors (xrandr information attached in Logs section below)

Is there a way to invoke Wait Requester through command line?

Thank you for digging into this with me again. Much appreciated.

Logs

377160.log
xrandr_info.txt

[sonic2kk]

Hi, thanks for opening an issue.

I had a look at your logs and it does indeed look like the Wait Requester isn't properly running. It doesn't look like it's getting to the Yad stage where it shows the actual UI. I suspect something is going wrong, maybe in the new Steam Deck compatibility information code.

The wait requester window no longer shows up when launching win32 games through Steam Compatibility Tool.

Does this only affect 32bit games? I thought Fallout 4 was 64bit (the "Creation Engine" and all that), but maybe the launcher is 32bit. Does this not affect any other games you have tested then, only 32bit games?

Purged $HOME/stl folder and reinstall everything (probably?)

Before removing you would need to run steamtinkerlaunch compat del to remove the compat tool symlink in Steam's compatibilitytools.d, then remove $HOME/.config/steamtinkerlaunch, then finally remove the $HOME/stl folder. But this is not really a solution, and I would prefer if you worked with me to try and resolve the problem before jumping into deleting things for now :-)

Is there a way to invoke Wait Requester through command line?

I don't believe so. The Wait Requester is intended for launching games through Steam.

---

There's nothing in your logs that suggests the Wait Requester is timing out. It seems like it's dying before it gets to that point.

I'm going to do some investigation around how I implemented the Steam Deck compatibility logic, I have a feeling that might be causing the problem here (though my games that I've tested work fine - Cookie Clicker, Persona 4 Golden, Persona 5 Royal, Sonic Mania, Sonic Origins, Vampire Survivors, Sonic Adventure 2 which is probably 32bit).

[sonic2kk]

I just tested with two games in Desktop Mode that I hadn't used with SteamTinkerLaunch before on Steam Deck (Geometry Wars: Retro Evolved and Doki Doki Literature Club Plus!) using the latest 20221030-3 build. I had no issues with those games...

I have Fallout 4 but can't spare the space or the time required to download and test it right now, but I don't think this is specific to Fallout 4. Or I would sure hope it isn't.

Can you test other games with SteamTinkerLaunch and see if they have the same behaviour? Test one in Desktop Mode like you're currently doing, and the same game or a different game in Game Mode. Just to see if it's specific to Fallout 4.

If only Fallout 4 is having this issue, you can try going to $HOME/.config/steamtinkerlaunch/gamecfgs/id/377160.conf and deleting that file. Maybe it's expecting something that it can't find for some reason.

Also, out of curiosity, does the SteamTinkerLaunch Tray Icon show up for you in the bottom panel?

[sonic2kk]

Pushed a couple of commits that should add additional logging so we can see what's going on here. Please run again and attach a log with the latest version (20221030-6 or higher if you're reading this after further updates). This isn't a fix, this is just more logging so I can get a better idea of what's going wrong.

If you want, you can try removing your 337160.conf file in the path described to see if maybe there's a misconfigured config file causing problems. But I'm not too sure on that.

[sonic2kk]

CrashGuess Requester was also invoked by looking into the launch log, but not shown as well.

This part of your initial issue totally escaped me, but I feel like the two might be related. We can investigate that as well, but one at a time :-)

[hftsai256]

Thanks @sonic2kk. That's a lot to digest. As you mentioned yad, I tried to open up the Wiki page via command line and then something went wrong:

/home/deck/.local/bin/steamtinkerlaunch: line 662: 18315 Trace/breakpoint trap   (core dumped) "$YAD" --window-icon="$STLICON" --title="$TITLE" --on-top --center "$WINDECO" --html --uri="$WIKURL" "$GEOM" > /dev/null 2> /dev/null

Core dumped? Does that mean yad is crashing? I can run yad directly through command line and can see a window pops out.

The problem, as you expected, is quite general and is not limited to 32 bit applications (I've heard somewhere referring windows application as win32 and obviously this is not the case: apologize to the confusion). Tray icon doesn't show up, but messages are popping out from the bottom right corner.

This is also not limited to Steam games. Manually added non-Steam games suffer from the same syndrome as well.

Please check the following logs captured with v11.12.20221030-9
Log: 2264235019 (Non-Steam Game - HoloCure)
Log: 1462040 (Final Fantasy VII Remake Reintergrade)
Log: 377160 (Fallout 4)

[sonic2kk]

Oh wow that's really strange, yeah it seems like Yad is crashing, or maybe STL is crashing?

I haven't had a chance to dig through the logs you posted yet (much appreciated by the way!) but something that jumped out to me right away is the location that STL is being ran from. Why is it being ran from ~/.local/bin/steamtinkerlaunch? It should be getting launched from ~/stl/prefix/steamtinkerlaunch or the symlink at Steam's compatibilitytools.d directory. SteamTinkerLaunch expects to be ran from the prefix it installed itself to. Maybe it can't find the Yad AppImage and is segfaulting?

The problem, as you expected, is quite general and is not limited to 32 bit applications (I've heard somewhere referring windows application as win32 and obviously this is not the case: apologize to the confusion). Tray icon doesn't show up, but messages are popping out from the bottom right corner.

Ah, maybe they are called win32. I've only used Windows as a daily OS for 18 months and that was almost 5 years ago, I am very unfamiliar with Windows terminology :-) You could very well be right so no worries!

This is also not limited to Steam games. Manually added non-Steam games suffer from the same syndrome as well.

Good to know, but thanks to your efforts I am fairly sure this is a Yad problem, and it might be to do with the location that STL is running from.

As a side-note, I've tested HoloCure with SteamTinkerLaunch on my Linux Desktop and it works fine. So this shouldn't be specific to HoloCure, just the Yad problem.

[sonic2kk]

Ah I was being silly. Opening the wiki isn't going to work on Steam Deck as noted on the wiki the Yad AppImage does not come with WebKit support and so it cannot render web pages. That's probably causing the segfaulting.

Although this is weird:

I can run yad directly through command line and can see a window pops out

The Steam Deck does not come with Yad. How are you using Yad?

Anyway, just checked your logs - Really strange, there is no initial logging message for STL detecting that you are running on a Steam Deck. It seems like the steamdedeckt function isn't running.

The logs also suggest that SteamTinkerLaunch is indeed running from /home/deck/stl/prefix/steamtinkerlaunch on your Deck.

Not totally sure what the problem is here just yet but I will keep looking :-)

[sonic2kk]

This is purely speculation since you can run Yad and the location of your script but, did you perhaps install SteamTinkerLaunch in a different way than simply executing the downloaded SteamTinkerLaunch script? Did you by any chance disable the read-only filesystem and try to install with sudo make install, plus installing other dependencies like Yad by hand as well? I could see this potentially causing some issues.

No offense or anything intended and I could be way off, I am just curious as to more specifically how you installed SteamTinkerLaunch since there appear to be some non-standard behaviours here.

[hftsai256]

I was running yad straight from where the binary resides ($HOME/stl/deps/usr/bin/yad).

Seems like an environment issue then. I had a quick glance on the source and probably I can tee a messaging log with set -x and try launching a game from command line. Let see what I can get.

I did unlocked the filesystem in order to install new ibus tables, but those were erased out after upgrading a new system image. However there are a bunch of redundancies on my flatpak packages, so I'm about to erase my deck back to factory settings.

[hftsai256]

Extra note: I forgot I symlinked yad and other dependencies from $HOME/stl/deps/usr/bin to $HOME/.local/bin when I was capturing logs above, so you may see this particular path here and there, but steamtinkerlaunch seems to figure out the actual script path quite well.

stl_377160_xtee.log (start from symbolic link)
stl_root_377160_xtee.log (start from binary root)

[sonic2kk]

I was running yad straight from where the binary resides ($HOME/stl/deps/usr/bin/yad).

Ah, thanks for the explanation! It's no problem or anything, I just wanted to rule out the possibility of a non-standard installation being the culprit here.

Seems like an environment issue then. I had a quick glance on the source and probably I can tee a messaging log with set -x and try launching a game from command line. Let see what I can get.

I see you attached a log in your next message with this! I haven't had a chance to take a look yet (rough evening...) but it could be an environment issue. I'm not too sure what could be going wrong. I guess if the log you attached didn't have anything useful, you could try deleting the AppImage and forcing STL to redownload it (or you're free to download it from the stl-tweaks repository manually if you wish).

Also there's absolutely no requirement here, you seem fairly handy with Bash, so just like you seem to have done earlier please feel free to look around the code and if you find something that could be causing the issue you can point it out :-) But no requirement or pressure here, I'm just letting you know if you want to do that I want to create a welcoming environment for that kind of initiative.

And thanks for the heads up about the symlinks - That's probably fine, I'll definitely take a look at your logs ASAP and see if I can trace through there it might be crashing

[hftsai256]

I think I found something valuable by catting the yad launching command starting from https://github.com/sonic2kk/steamtinkerlaunch/blob/master/steamtinkerlaunch#L8744, which becomes:

"" --f1-action="bash -c OpenWiki" --image "/home/deck/.config/steamtinkerlaunch/games/header/377160.jpg" --image-on-top --window-icon="/home/deck/stl/prefix/misc/steamtinkerlaunch.svg" --form --center --on-top "--decorated" --title="SteamTinkerLaunch-OpenSettings" --text="<span font_size='larger' font_weight='bold'>Fallout 4 (377160) - Open settings?</span>" --field="<span font=\"italic\"><b>ProtonDB Rating Trend:</b> platinum</span>":LBL --field="<span font=\"italic\"><b>Steam Deck Compatibility:</b> Playable</span>":LBL --field="<span font=\"italic\"><b>Last Played on:</b> 31.10.2022 for 07 secs</span>":LBL --field="<span font=\"italic\">(6 editable config files found)</span>":LBL --field="<span font=\"italic\">(Editable possible game config files found)</span>":LBL --button="MAIN MENU":0 --button="CANCEL":1 --timeout="2" --timeout-indicator=top "--geometry=1280x800+0+0"

If I replace the first empty double-quote pair to the actual path to yad, I can now get Wait Requester showing up on my screen. For some reason the variable $YAD was not properly expanded.

[hftsai256]

Now here are some measures I've taken:

1. Assign yad path through command line:

./steamtinkerlaunch yad $HOME/stl/deps/usr/bin/yad
ln: failed to create symbolic link '/home/deck/.config/steamtinkerlaunch/downloads/yadappimage/yad': No such file or directory

2. Using AppImage:

./steamtinkerlaunch yad ai
Downloading '/home/deck/.config/steamtinkerlaunch/downloads/yadappimage/Yad-8418e37-x86_64.AppImage'
Checking 'sha512sum' of the file '/home/deck/.config/steamtinkerlaunch/downloads/yadappimage/Yad-8418e37-x86_64.AppImage'
The 'sha512sum' checksum of 'Yad-8418e37-x86_64.AppImage' is correct: 'cb9080421f99f02c1b4364fe0ab7e1b7c135985bcfea57df9e609f176e352c2222e01086b8b5910a3bf24a541ac812357038104f2019697e1104b54dda55465b'

It does place an AppImage in place, but $YAD still expands to empty string.

3. Symlink yad binary under $PATH. No dice.

4. Edit global.conf and set YAD=$HOME/stl/deps/usr/bin/yad at line 8. This solution works, but hacky and doesn't actually resolve the reason that $YAD is not properly set.

[sonic2kk]

For some reason the variable $YAD was not properly expanded.

Nice debugging! I wonder if this is related to the following:

Edit global.conf and set YAD=$HOME/stl/deps/usr/bin/yad at line 8.

Was this variable blank? SteamTinkerLaunch is supposed to set it to the exact path you gave (on desktops this might be /usr/bin/yad for example). So I'm wondering was yours blank? That would explain why the wait requester wasn't showing and why your tinkering was able to fix the expansion!

I just checked on my Steam Deck and the path is correctly set to the yad symlink in the deps dir you gave. If the path to Yad was not correctly set in the global conf that would explain the crashing, but if that is the case I am not too sure why it would not be getting set correctly and I'll need to investigate that! :-)

Thanks a ton for all your efforts here too, this may be a very valuable hint!

[hftsai256]

Yes that field was left blank. Is there a way to completely blow away those dependencies and let it regenerate? I'd like to see if that field would populates properly from a clean install.

[sonic2kk]

Yes that field was left blank.

How strange, but thank you for testing! I should've thought of this initially but I appreciate the initiative you took here. The problem for the Wait Requester (and probably also the crash guesser) is that STL didn't store $YAD, so when it was trying to call it, it was failing.

Is there a way to completely blow away those dependencies and let it regenerate? I'd like to see if that field would populates properly from a clean install.

If you want to do a clean STL install, you can remove the $HOME/stl folder, optionally the /dev/shm/steamtinkerlaunch folder (just some temp files there really) and remove $HOME/.config/steamtinkerlaunch. However you may be able to just rename the global.conf folder and STL will re-generate that the next time you launch it, and should correctly generate the Yad field.

On my Steam Deck, PC, and laptop, the global.conf location for Yad is set correctly. If Yad does not correctly get set for you on a clean install/with renaming the global.conf, I will try on my Steam Deck and see if I can replicate the problem.

Thanks!

[hftsai256]

A complete reinstall can properly set the variable YAD in global.conf.

I could reproduce the issue reliably now. The key is to remove only $HOME/.config/steamtinkerlaunch while keeping $HOME/stl intact. The YAD field in global.conf is then left blank after environment configurations are auto-generated.

[sonic2kk]

Thanks for the insight! I pushed a commit now that attempts to fix this - Please retest if you get a chance and see if this fixes your issue (forgot to bump version, oops...)

Also sorry that the issue closed - GitHub saw the commit message and closed it automatically. This fix shouldn't break anything and should hopefully resolve your issue - Basically now we call updateConfigEntry when we set Yad on Steam Deck always after the download. There may need to be a better check somewhere else but I haven't dug into it much for now. My guess is that STL isn't calling this function on existing installs, and I'll need to look more into how to resolve that if this does not (probably just a general call in steamdedeckt, but I'll look into that if the current commit doesn't fix the problem for you).

Thanks for all the testing!

[hftsai256]

Took a shot on version v11.12.20221102-1. The regenerated global.conf still has YAD="".

Which function does it call when it is re-populating fields in global.conf ?

[sonic2kk]

Which function does it call when it is re-populating fields in global.conf ?

Good question, I'm not too sure but on Steam Deck this is set separately. We have a separate function for updating values in the global.conf with updateConfigEntry where we pass it YAD as the field to update. For example at https://github.com/sonic2kk/steamtinkerlaunch/blob/master/steamtinkerlaunch#L14184 (feel free to just go to this line 14184 in a text editor as it might take a while to load on GitHub).

Looking at the code it seems like there are a couple of calls before we call that function that don't seem to exist before setting the Yad config entry path, mainly a touch "$FUPDATE". I'll push up a change that adds this in a bit (testing some stuff for another issue atm, don't want to disturb that).

I remember that touch call was important though, so hoping that fixes it.

[sonic2kk]

Pushed up that change which may or may not fix the issue. Please retest when you have a moment :-)

[hftsai256]

I took a deeper look into the commit. The two touches added on line 14184 & 14192 aren't hit because function setYadBin is not invoked. We may add some logic around line 20481 and call setYadBin before setting up AppImage solution.

[sonic2kk]

Ah, good catch! I wonder if a line like this in the [ -f "$( command -v "yad" )" ] block would suffice:

touch "$FUPDATE"
updateConfigEntry "YAD" "$( command -v "yad" )" "$STLDEFGLOBALCFG"

A call to setYadBin might be overkill, and this would just ensure that the YAD variable is set in the config. Entirely untested though :-) You could test yourself if you really wanted by adding that in on the yad check under Line 20479, though you would have to run STL offline to stop it from auto-updating on Steam Deck (probably gonna add a flag for this at the very least soon, at least internally).

My concern with adding this would be any potential breakage with existing STL Steam Deck installs. I don't foresee this causing any problem. At worst it'll just redundantly overwrite the YAD value in the config file with the same value, and the value probably isn't being set because STL assumes it's already set in the config file on Deck and that this won't ever disappear - which is incorrect. And on a normal config file generation this isn't an issue because it pulls yad from command -v yad, and we expect users on a normal install to have Yad installs on their system and if not, they can add it later via an STL command. That command probably works on Steam Deck, too, but we'd want to handle this automatically for users on Steam Deck since we also automatically handle Yad too.

If this does work, you're welcome to get a PR up for it if you wish :-) Or if you have another idea for a solution too. Otherwise I'll test and release this over the weekend hopefully. Just working on a couple of other things currently (ProtonUp-Qt improvements, HMM support, Vortex stuff) so additional contributors would be welcome!

[sonic2kk]

Just pushed an experimental commit that should address this. Please test :-)

[sonic2kk]

Closing now, feel free to re-open if the problem persists :-)