Session: a cold-start game launch waits for the Steam interface

A game launched from the Games tab with no session running sat at
Launching: the session put steam://rungameid on the client's command
line, the client took it seconds before its interface was up, and its
launch stopped waiting for a response to ShowInterstitials that nothing
gave. The same launch from inside Steam went through. The URL is now
held back and handed over through the in-session steam-game request once
gamescope's focus is the Steam interface and four seconds have passed,
or after two minutes regardless.
This commit is contained in:
The412Banner committed 2026-10-09 04:40:09 -04:00
1 parent 272cd60b19
commit bf811040ae
2 files changed
+40

No files matched your search

+12
View File
@@ -144,6 +144,18 @@ without it and Setup says "Stores engine not built").
(`token`, `__token__`, `f_token`, `hdnts`, access/refresh/id tokens, `code=`) and Authorization /
Cookie headers are blanked outside URLs too. `StoreLogTest` covers a GOG secure link and an Epic
Akamai URL. The engine's own logcat lines (tag `EpicNative` etc.) are written on the native side.
- **A game launched from the Games tab with no session running sat at "Launching"** (device,
2026-10-09-04-steam, and 2026-10-08-05 before it). The session put `steam://rungameid/<id>` on
the client's command line; the client took it seconds before its interface was up (focus went to
769 at 04:29:07, the launch at 04:29:09) and its launch stopped at `LaunchApp waiting for user
response to ShowInterstitials` with nothing to answer - the next launch from inside Steam went
straight through. Not store-specific: the 2026-10-08 cold launch of another shortcut stopped the
same way. `droiddeck-session` now holds such a URL back and hands it over through the same
`steam-game` request an in-session launch uses, once gamescope's focused app is the interface
(769) and four seconds have passed, or after two minutes regardless. The `rc=139` at the end of
both sessions is the client crashing in its own shutdown, after "Shutdown", unrelated to the
launch. The shortcuts writer keeps a compat tool the user chose (`plan_mapping` skips an entry
that is not one it set itself), and the live add sets one only for a new shortcut.
- **Why EOS's browser flow never reached Android:** the hand-off script was never in the APK. The
build copies only `usr/local/bin/droiddeck-*`, `steam-compatibility` and `usr/bin/**` of the overlay
into the assets, so `usr/local/lib/droiddeck/browser/xdg-open` was skipped, the session staged
@@ -598,6 +598,34 @@ case $mode in
fi
done
) &
# A game the app asked to launch on a cold start is not put on the client's command line: the
# client takes it before its interface is up, its launch stops at "waiting for user response to
# ShowInterstitials" with nobody to answer, and the game page reads Launching for ever (device,
# 2026-10-09, and 2026-10-08 before it). It is handed over once the interface has focus
# (gamescope's focused app 769) and has had a moment, through the same steam-game request an
# in-session launch uses; after two minutes it goes anyway.
if [ -n "${BL_LAUNCH_DIR:-}" ] && [ -z "${BL_DESKTOP:-}" ]; then
_bl_held=
_bl_rest=()
for _bl_arg in "$@"; do
case $_bl_arg in
steam://rungameid/*) _bl_held=${_bl_arg#steam://rungameid/} ;;
*) _bl_rest+=("$_bl_arg") ;;
esac
done
if [ -n "$_bl_held" ]; then
set -- "${_bl_rest[@]}"
(
_bl_end=$((SECONDS + 120))
until [ "$(xprop -root GAMESCOPE_FOCUSED_APP 2>/dev/null | sed -n 's/.*= *//p')" = 769 ] || [ "$SECONDS" -ge "$_bl_end" ]; do
sleep 1
done
sleep 4
echo "== steam: interface up; launching the requested game $_bl_held"
printf '%s\n' "$_bl_held" > "$BL_LAUNCH_DIR/steam-game.tmp" && mv -f "$BL_LAUNCH_DIR/steam-game.tmp" "$BL_LAUNCH_DIR/steam-game"
) &
fi
fi
# Debug aid while the runtime is being brought up: an app id dropped in ~/.bl-autolaunch is
# handed to the client as a rungameid URL, so a launch can be reproduced without touching the
# screen. Removed once the runtime is stable.