3 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	d5857abd91	fix(session/gamelease): a launcher handing off is not the game exiting ... On glass (.41), launching any Steam title over the compat plane ended the session ~7 s later, before the game had started: launched app command=steam steam://rungameid/2379780 pid=12699 watching the launched game kind="child" the launched game is running kind="child" procs=0 <- 3 ms in, zero game procs the launched game exited -> session ended Linux launches are `Child` leases: the host spawns the launcher itself. The watcher counts "my child is alive" as the game running, so the lease left the waiting phase on its FIRST poll — and the shim reclassification lives in that phase, so it never got to run. When `steam` handed off and exited, that read as the game exiting. The design always called for the shim window ("never fires B from a shim exit") and the code implements it; the lease had simply moved past where it applies. So when the store gave us signals to recognize the real game by, a bare live child no longer counts as the game until that window has passed. With no signals the child is all we have and still counts immediately — custom commands are unchanged. Windows could not reproduce this: it holds no child, so its leases are always `Matched`, and the whole .173 pass was structurally blind to it. Both planes on Linux were affected — which is most of the audience for this feature. Also fixes the live-process fixture, which was CI-red for an unrelated reason: it copied `/bin/sleep` to a file named `game`, and modern coreutils (uutils on Ubuntu 25.10+, busybox elsewhere) is a MULTI-CALL binary dispatching on argv[0] — under any other name it exits instantly, leaving nothing in /proc and looking exactly like a broken matcher. Verified by A/B: the same test fails identically on a tree predating these changes. .25 (Ubuntu 26.04): 305 passed, 0 failed.	2026-07-26 21:24:12 +02:00
enricobuehler	110eabf281	feat(library/providers): let a provider say how to recognize its games ... A plugin's titles launch through the provider's own client, which hands off and exits — so the host had nothing left to watch, and both lifetime behaviors went quiet for exactly the entries a provider contributes. A `ProviderEntry` (and a manual custom entry) may now carry an optional `detect` hint: install dir, exe, or process name. It is deliberately a subset of what the host tracks internally. A Steam appid or a launcher's environment marker are things the host discovers for itself and would be meaningless — or dangerous — to take on someone's word; where a title is installed is something only the provider knows. The host's own findings win where both exist, so a stale export can never redirect the matcher, and a blank field is treated as absent rather than as "match everything" — an empty install dir would otherwise prefix-match every process on the box, and this feature can end processes. `process_name` is the weakest of the three and the only one typed by hand, so it is matched case-insensitively against the image's file name and nothing else: `retroarch` finds RetroArch, not a helper whose name merely starts the same way, and not a script that happens to live in a `retroarch/` directory. The never-adopt-a-pre-existing-process rule still bounds it. Also: the tray summary gains the running-game row (with the closing-in countdown for a game whose client is gone — visible at the machine without opening the console), the SDK mirrors the `game.*` events, and its generated client catches up with the endpoints Phase 1 added. Gates on .21: check + clippy --all-targets clean, 299 tests, fmt CI-parity, openapi regenerated (GameEntry still carries no `detect` outbound); SDK tsc + 54 tests green.	2026-07-26 18:28:13 +02:00
enricobuehlerandClaude Fable 5	ed4e3d3ab6	feat(session): end-game/end-session lifetime on Windows ... Phase 2. The lease, the settings, the events and the status surface were already platform-neutral; what Windows lacked was a way to see processes and a way to ask one to close. `procscan` splits per-OS behind one contract. The Windows matcher is a Toolhelp snapshot plus each process's full image path (`QueryFullProcessImageNameW`), with creation times from `GetProcessTimes` enforcing the two rules the module exists for: never adopt a process that predates the launch, never trust a bare pid. Both matter more here than on Linux — the host is SYSTEM, so it can see and signal everything, and Windows recycles pids briskly. Path matching is case-insensitive and separator-aware, and normalizes the `\\?\` prefix `canonicalize` adds, without which a store-derived path would never compare equal to a live image path. There is no reaper argv and no readable environment on Windows, so a spec carrying only a Steam appid or an env marker matches nothing rather than falling through to an empty predicate. Steam's appid instead feeds a **veto**: its per-app `Running` flag in the user's hive can't be trusted to say a game IS running (Steam sets it around updates too, and leaves it stale after a crash), but it is exactly right for refusing to declare one gone. If the matcher can't see a game whose exe sits outside its manifest's install dir, ending the session would be a false positive the player feels immediately; honoring the veto only ever leaves a stream up. Termination asks before it insists, which on Windows needs a detail that fails silently if missed: `EnumWindows` only sees the calling thread's desktop, and the host's is session 0, which holds none of the user's windows. So the terminating thread binds to the input desktop first (the pattern `pf-inject`'s `sendinput.rs` uses), posts `WM_CLOSE` to the game's visible top-level windows, waits, and only then calls `TerminateProcess` on freshly re-verified pids. Without the desktop bind the polite pass finds nothing and every game dies unsaved. Job Objects, planned as WP2.3, are deferred with the reasoning in the design doc: every Windows launch either hands off through a launcher or the shell — where a job would wrap a shim that exits immediately — or is a direct exe whose path we already know, and wiring one in would touch the `CreateProcessAsUserW` token path the UAC and secure-desktop work depends on. Also: the watcher's steady-state poll now re-verifies known pids and only re-scans the whole table once they all vanish (which still catches a game that re-execs). On Windows a full scan is an `OpenProcess` per process on the box, so this is the difference between a negligible and a noticeable poll. Gates: Linux .21 check/clippy/fmt/293 tests green; Windows .133 check + clippy --all-targets clean, and the 4 procscan tests pass — including the live one that finds the test process in the real process table and rejects a wrong creation time. On-glass Windows (Steam/Epic/GOG/Xbox titles, the unsaved-progress check) still owed; it needs a box with games on it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 18:28:13 +02:00