1874 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehlerandClaude Sonnet 5	c4e80fd455	docs(release): v0.21.0 notes should only cover its own delta ... Duplicated the entire v0.20.1 fix bundle verbatim instead of following house convention (each vX.Y.Z.md covers only what changed since the immediately preceding release file — see v0.19.1 -> v0.19.2, neither restates the other). v0.20.1 is a real, already-tagged release with its own notes file; 0.21.0 only needed to add the monitor-streaming feature, the KDE registry fix found while building it, and the CI-only winget fix, with a pointer back to v0.20.1 for the rest. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 09:08:47 +02:00
enricobuehlerandClaude Opus 5	d08893383a	chore(release): bump workspace version to 0.21.0 ... 42 commits since v0.20.0 (v0.20.1 was tagged but never announced; superseded by this release rather than repointed, since real new functionality landed after it was cut). Minor, not patch: the headline is streaming one of the machine's own physical monitors instead of always creating a virtual display — pick it from a new console card or pin it in host.env, on KWin, Mutter, sway and Hyprland, in both the Punktfunk app and Moonlight. Also folds in the full v0.20.1 fix bundle: three Windows install blockers found within hours of 0.20.0, GameStream/Moonlight compat back to opt-in on fresh installs, three gamescope Game Mode takeover faults, a laptop-panel stall misdiagnosis, and the PyroWave high-bitrate latency-creep bundle — plus a KWin 6.7 regression found while building the monitor feature (silent kscreen-doctor fallback on every session) and a winget release-verification CI fix. Wire protocol stays at 2, the embeddable C ABI at 13 and the Windows virtual-display driver protocol at 6. GET /display/monitors is a new additive endpoint; the display policy gains an optional capture_monitor field. No embedder rebuild required. Notes authored ahead of the tag per docs/releases/README.md. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> v0.21.0	2026-07-28 00:03:44 +02:00
enricobuehlerandClaude Sonnet 5	74179c4c2e	fix(ci/winget): envs: must live under with:, not as a step sibling ... 24d2f97e added envs: GITHUB_REF_NAME to fix "Verify the served catalogue" failing on every tag with `GITHUB_REF_NAME: unbound variable` — but placed it as a sibling of with:/env: on the step, which is not part of the step schema and is silently ignored by Gitea's runner. appleboy/ssh-action never received it as an input, so the step kept failing identically on v0.20.1's first tag run. docker.yml and deploy-services.yml already forward REGISTRY_TOKEN this way correctly: envs: nested inside with:. Moved to match. Confirmed by parsing the workflow and checking envs lands in the step's with: dict, not as a bare step key. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-28 00:01:45 +02:00
enricobuehlerandClaude Opus 5	8fe71be424	fix(web): applying a saved preset kept switching the streamed screen off ... `applyCustomPreset` builds a FRESH policy object instead of spreading the draft, so every field it doesn't name is dropped. `capture_monitor` was not named — so picking one of your own saved presets silently took a host that was mirroring a real monitor and put it back on a virtual display. The same omission in the Custom switch would have done it there too. Found on-glass against a running serve on .136: the PUT is whole-object, so the console is the only thing keeping the orthogonal axes alive, and these two sites were the ones building a policy from scratch rather than from what was already in force. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	a98174ebfa	feat(host): anchor-test, and libei says which output absolute input landed on ... The absolute-region ladder existed for one case a unit test can only simulate — two heads of the SAME size, where matching a libei region by the streamed mode is a coin flip — and that case had never been run against a real compositor. It was also unobservable: the log said which regions the EIS server offered, never which one a coordinate went into, so "the pointer is on the wrong monitor" could only be discovered by looking at a monitor. libei now reports the chosen region once per distinct answer, beside the existing miss warning: one covers an anchor that named nothing, this one covers an anchor that matched something, by saying which. `anchor-test` is the gate that reads it, in the shape mirror-test established: it enumerates the heads, SAYS whether the rig actually has two of the same size (a green run on a single-head box proves nothing), anchors at a named one (or `--none` for the A/B that makes the anchored run mean anything), and walks the corners. It refuses to run off libei rather than emitting a green result about a ladder that isn't there. On-glass on KWin 6.7.3 with `kwin_wayland --virtual --output-count 2` (regions 1920x1080+0+0 and +1920+0): unanchored picks +0+0, anchored at Virtual-1 picks +1920+0, anchored at Virtual-0 picks +0+0. That is open item 3 of design/per-monitor-portal-capture.md §8b, closed. Clearing the pin now logs too — setting one always did, and the streamed screen going back to virtual is the same size of change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	ea0c61fb0f	docs: streaming a real monitor, and the CLI that names one ... The console grew a "Streamed screen" card and the host grew a PUNKTFUNK_CAPTURE_MONITOR knob and a list-monitors command, and the docs knew about none of it — a control with no explanation anywhere. virtual-displays.md gets the feature section: what it is for, that the monitor is never touched, that its resolution wins and a client scales, that a bad name is a hard error rather than a different screen, and that there is no chooser dialog on any of the four backends (which is what makes it work unattended). Plus the three troubleshooting entries the shape of the feature predicts: settings that do nothing while mirroring, a console card the env var has locked, and a pin that names no head. host-cli.md documents list-monitors and mirror-test; configuration.md gets the knob, including that it outranks the console on purpose; running-as-a-service.md gets the desktop-session drop-in and states that the host needs nothing exported to find its session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	19deac75fe	feat(packaging): a desktop-login host restarts with its desktop ... The shipped unit's PartOf=punktfunk-kde-session.service covers the APPLIANCE route, where we start the compositor ourselves. A host on a machine somebody logs into has no such unit: when Plasma or GNOME restarts, the daemon keeps running while holding a Wayland socket and a portal D-Bus connection that both died with the old compositor, and it cannot recover either in-process. It fails quietly — the host still listens, still answers, and every session it then serves dies at capture. A host that mirrors a monitor idles for days between sessions, which is the shape that finds this at the worst moment. The drop-in binds the host to graphical-session.target: PartOf takes it down with the session, WantedBy brings it back with the new one. Shipped under /usr/share rather than as an active drop-in, because it is wrong for the appliance route (which may never reach that target at all, and would then leave the host permanently stopped) — the operator opts in. Closes the restart half of design/per-monitor-portal-capture.md §6. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	45f04f50fe	test(mgmt): gamescope reports no monitors, and that is not a missing explanation ... /display/monitors must never answer empty AND silent — the console reads that as "the host is broken". But gamescope is nested: it owns no physical heads by construction, so empty-and-silent is the correct answer there, not an unexplained one. Any dev box that has ever been in game mode keeps gamescope-0 sockets in its runtime dir, so detect() resolves gamescope and the test failed on the machine rather than on the code (found running the suite on .136). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	6afc05155b	feat(vdisplay/session): derive SWAYSOCK — the last session var a --user host lacked ... Session detection already hands every backend the live session's env: WAYLAND_DISPLAY from a socket scan, XDG_RUNTIME_DIR from the uid, the session bus, XDG_CURRENT_DESKTOP, and Hyprland's instance signature. sway was the exception — SWAYSOCK had to be INHERITED from the login shell, so a systemd --user host that never saw one had no sway IPC at all: no output enumeration, no capture chooser, no wlroots backend (its is_available() keys off that very variable). It is derivable, and by identity rather than guess: sway names its socket sway-ipc.<uid>.<pid>.sock, and detection already knows the compositor PID. Ladder: a valid inherited value, then the exact PID's socket, then the newest one we own (a sway re-exec can leave the name pointing at a PID we didn't see). None on river — the other wlroots desktop ships no sway IPC, and saying so is what stops apply_session_env exporting a SWAYSOCK that points at nothing. Closes the session-env half of design/per-monitor-portal-capture.md §6 for a desktop-login host: nothing has to be exported for the host to find its session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	829bcb7962	fix(gamestream): the streamed-screen pin applies to the portal source too ... PUNKTFUNK_CAPTURE_MONITOR is documented as "instead of creating a virtual display OR taking whichever head the portal hands back", and the console presents it as a host-wide setting. The compat plane's portal source did neither: it went straight to the chooser, so a Moonlight client on a pinned host silently got whatever screen the portal picked. That is the one outcome the whole feature exists to prevent — showing the wrong monitor is worse than showing none. The portal arm now mirrors the pinned head instead, through the same MirrorDisplay the virtual source reaches via vdisplay::open. It launches nothing and creates no virtual output, so it needs neither the game-lifetime machinery nor the registry (External ownership passes through it anyway). Which screen a pooled capturer is showing is now the third reuse key beside HDR-ness and cursor mode. The pin is a LIVE setting — the console can re-aim the host between two connects — so without it in the key the second connect would keep streaming the previous screen, which is the same silent-wrong-monitor failure by another route (§7.3, open item 5). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	de3ef50434	fix(native): a mirrored monitor has a fixed mode — refuse to resize it ... A physical head runs at the mode its owner set, and MirrorDisplay::create ignores the requested one on purpose. So a mid-stream Reconfigure against a mirror could only ever tear the cast down and rebuild the identical one at the identical size — a hitch that buys nothing, and an invitation to the worse reflex of reconfiguring the display someone is sitting at. reconfig_allowed grows a third gate beside gamescope and per-client-mode identity, and the session captures it at bring-up like the others: this session opened its display under whatever the pin said then, so a console change mid-session must not retroactively change the answer it gives. Linux-only, because vdisplay::open only routes to the mirror there — a pin left in a Windows host's settings streams nothing different and must not disable resize as a side effect. design/per-monitor-portal-capture.md §7.3, open item 4. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	b08226dbf1	feat(vdisplay): mirror a pinned monitor on sway and Hyprland ... P5 of design/per-monitor-portal-capture.md, and the end of a hole worth naming: the pin was accepted, persisted and offered in the console while `create` bailed on these two backends, so a sway or Hyprland host with a monitor selected failed EVERY session. Both already ship the mechanism — a managed portal-chooser config plus a per-session selection file (xdpw's `Monitor: NAME`, xdph's `[SELECTION]screen:NAME`) — so mirroring is that same chooser pointed at a physical connector instead of a headless output we created. The keepalive stops the cast and nothing else; the monitor is the compositor's. The selection write is now serialized against the handshake that reads it (SELECTION_LOCK, applied to the virtual-output paths too). That file is one per-user path: whoever writes last before the portal reads wins, and the loser does not fail — it silently captures the other session's output. `managed` is no longer grounds for refusal everywhere. It is conclusive only where the name is ours by construction (KWin's `Virtual-punktfunk`, Hyprland's `PF-N`); sway names EVERY headless output `HEADLESS-N`, its own included, so the old rule would have refused to mirror any output on a headless sway box — exactly the remote setup this feature serves. Found on-glass, and now a test. Verified on a two-output headless sway: asking for HEADLESS-1 yields 1280x720 frames and HEADLESS-2 yields 1920x1080, so the chooser really does steer per request. Hyprland is compile-only — no Hyprland box exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	d461d889c3	feat: the streamed screen is a persisted setting, pickable from the console ... P4 of design/per-monitor-portal-capture.md. The pin was an env var read once at startup, which a console picker can never write — so it becomes a field of the display policy (orthogonal to presets, like game_session), and `vdisplay::capture_monitor()` resolves env-over-policy: an appliance that pinned in its unit's host.env stays pinned there, and a console click cannot re-aim a machine whose operator already declared the answer. Read per `open` rather than cached, so a picker change takes effect on the next session instead of the next host restart. The host re-resolves the input anchor on every policy write — including clearing it when the pin is cleared, or a later virtual-display session inherits an anchor aimed at a monitor it is not showing. `with_manual_layout` carries the pin through like the other orthogonal axes: without that, saving a display ARRANGEMENT would silently swap the streamed screen back to virtual. Console: a "Streamed screen" card listing the host's real monitors beside "Virtual screen (default)", saving on selection. A disabled head is listed but not selectable (so "why isn't it here?" has an answer), and an env-pinned host renders read-only with the reason rather than offering controls that silently lose to the environment. Verified on GNOME/Mutter: pinning via the policy file alone (no env) routes sessions to the mirror and anchors input; setting the env to a different connector overrides it, exactly as documented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	358cfa4be4	feat(host): mirror-test — the on-glass gate for per-monitor capture ... Opens the display backend exactly as a session would, attaches a capturer and reports the frames a named head actually produces, with no client involved. `--monitor` names the head explicitly (it cannot go through PUNKTFUNK_CAPTURE_MONITOR: pf_host_config parses the environment once and startup already read it, so a tool setting it for itself would still see the old snapshot — hence vdisplay::open_mirror); with no argument it exercises the production routing through the pin. A frame timeout is NOT treated as failure. Compositor capture is damage-driven — the host's own capture diag logs new_fps=0 for virtual outputs on an idle desktop for exactly this reason — so the first version of this tool ended its measurement on the first idle gap and made a working mirror look like a 2-frame stall. Verified on KWin 6.7.3 (home-nobara-1), mirroring HDMI-A-1: 346 frames in 20s at 1920x1080, arriving while input was injected and pausing when the desktop went quiet, on both the CPU (BGRx/MemFd) and zero-copy (NV12 dmabuf) paths, ownership=External. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	045deaf77a	fix(vdisplay/kwin): bind the output-device REGISTRY — KWin 6.7 stopped ... advertising per-output globals Found on-glass while testing monitor enumeration: KWin 6.7.3 advertises kde_output_device_registry_v2 and NOT one kde_output_device_v2 global per output. This module only ever bound the globals, so on a current KWin it saw zero devices. That is not just an enumeration gap — it silently disabled the whole in-process output-management path, which exists precisely because kscreen-doctor wedges. The live 0.19.2 host on the test box logs "kde_output_management unavailable — kscreen-doctor fallback" on EVERY session, so every topology apply there has been going through the tool this module was written to stop using. Both models are supported now: the per-output globals older KWin sends, and the registry's `output` events. Devices from the registry arrive a round later than globals do, so the handshake takes one more barrier — skipped when nothing is still awaiting its `done`, so the classic path costs nothing. Verified on KWin 6.7.3: enumeration now reports HDMI-A-1 1920x1080@60 at +0,+0 scale 1.35 primary, matching kscreen-doctor exactly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	bf2f54a5fe	feat(vdisplay): mirror a pinned monitor on Mutter, and scope the HDR probe ... P3 of design/per-monitor-portal-capture.md. Mutter's mirror is the same private ScreenCast session the virtual path already drives, one call different — RecordMonitor instead of RecordVirtual — so it inherits what makes that path work headlessly: a direct D-Bus API that needs no interactive approval, unlike the xdg portal a background service could never answer. Deliberately not under TOPOLOGY_LOCK: that serializes operations which add or remove a monitor or apply a monitor configuration, and mirroring does neither. Nothing is created, no layout changes, and teardown is just Stop — the SIGSEGV-adjacent ordering the virtual path must observe cannot arise when no monitor is being removed. The GNOME HDR probe now honors the pin. Asking "is ANY monitor in BT.2100 mode" was fair while capture took whatever head it was handed; once the operator names one, an HDR TV on the next connector must not talk the host into offering PQ formats for the SDR panel it is actually streaming. A pin that names no live head reports SDR rather than falling back to "any" — the session is about to fail on that same missing monitor, and an over-claimed HDR offer would be a second, quieter wrong answer. ⚠️ RecordMonitor's exact signature is read from the interface, not yet confirmed against a live gnome-shell; no GNOME box was reachable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	53c772702f	feat(host): list-monitors CLI, and two bugs it caught on-glass ... An operator configuring an unattended host has to learn the connector names from somewhere, and "curl the management API before the host is configured" is not it. `punktfunk-host list-monitors` prints them with geometry and flags the pinned one. Running it under a real sway immediately caught two defects the unit tests could not: - the query used the `swaymsg` command helper, which inserts `--`, so `-t get_outputs` came back as "Unknown/invalid command '-t'". Queries now go through a `swaymsg_query` helper that cannot make that mistake. - compositors write the literal "Unknown" rather than leaving make/model empty, so the picker label read "Unknown Unknown". One `describe` helper now treats that as absent, for all four backends. Verified on a headless two-output sway: names, modes, positions, scale and the case-insensitive pin all resolve. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	93c2765db7	feat(vdisplay): mirror a pinned physical monitor on KWin ... P2 of design/per-monitor-portal-capture.md. zkde_screencast's stream_output records an output KWin already has — the connector name IS the selection, so there is no dialog, no portal and no chooser for a background service to answer. It arrives as a VirtualDisplay reporting DisplayOwnership::External, which already means "someone else's display, merely mirrored: no keep-alive, no topology, no reuse". So the rule that we must never disable, move or "restore" a monitor the user is sitting in front of holds by construction rather than by everyone remembering it — and create() ignores the client's requested mode for the same reason: a panel runs at the mode its owner set. Routing lives in vdisplay::open, the one place every session opens a display, so the pin cannot be honored on one plane and ignored on another. The host sets the libei anchor from the same pin (pf-vdisplay must not depend on pf-inject), which is what makes absolute input land on the mirrored head instead of a same-sized neighbour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	2eeee650b9	fix(inject/libei): absolute coordinates resolve by identity, not by size ... libei hands the injector one region per logical monitor with no output name attached, so picking one meant matching the streamed mode's SIZE — a coin flip the moment two heads share a mode, and it already resolved wrong on-glass once (GNOME, a dummy HDMI beside the virtual primary: the seat cursor never entered the streamed monitor, so neither cursor path could see it). The ladder is now mapping_id -> origin -> size -> first. Two outputs can share a size but never a top-left, and a mirrored head's region is not the client's size at all, so the size rung cannot find it — this is what makes per-monitor capture land its input on the monitor it is showing. An anchor that matches nothing falls back down the ladder rather than stranding input: the region set is the truth and the anchor is our belief about it. It warns once per distinct anchor, because the failure this exists to prevent is a pointer that silently lands elsewhere. P1 of design/per-monitor-portal-capture.md — mechanism and tests only. Nothing sets an anchor yet; the pin wires it in P2, and the doc comment records why it is host-level and not per-session. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	95e3314d9a	feat(vdisplay): enumerate the host's physical monitors ... P0 of per-monitor capture (design/per-monitor-portal-capture.md): nothing in the tree could answer "what heads does this host have?", which both a monitor pin and a console picker need first. One read per compositor, each beside the code that already speaks that dialect: KWin's kde_output_device_v2 (the topology session now also records geometry + scale), Mutter's DisplayConfig.GetCurrentState, swaymsg get_outputs, hyprctl monitors. Logical geometry throughout, because x/y is what identifies a head — two monitors can share a size but never an origin. PUNKTFUNK_CAPTURE_MONITOR parses here and is reported at startup, loudly including that it is not yet enforced: a knob that is read but inert has to say so, or "it didn't work" reads as a bug. GET /display/monitors always answers 200 with an explained empty list, so a compositor-less host renders as "nothing to pick", not as a broken console. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Sonnet 5	3721b6816d	chore(release): bump workspace version to 0.20.1 ... 24 commits since v0.20.0. Patch, not minor: entirely fixes and hardening on top of last release's session⇄game work, nothing new to opt into. Headline fixes: three Windows install blockers reported within hours of 0.20.0 (a false conflicting-host detection, a broken winget log-path switch, missing package-source instructions), GameStream/Moonlight compat flipped back to opt-in on fresh installs, three gamescope Game Mode takeover faults that could black out a Linux machine or strand it on a host restart, a deactivated laptop panel misdiagnosed as a blind spot instead of a named stall cause, and the PyroWave high-bitrate latency-creep bundle (clock re-sync starvation, wire bitrate overshoot, backlog buildup, ABR probe false-congestion). Wire protocol stays at 2, the embeddable C ABI at 13 and the Windows virtual-display driver protocol at 6, unchanged from 0.20.0 — no embedder rebuild required, 0.18/0.19/0.20 hosts and clients mix freely. Notes authored ahead of the tag per docs/releases/README.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> v0.20.1	2026-07-27 19:25:47 +02:00
enricobuehler	0e0d5b8b4d	chore(api): regenerate openapi.json — the stats description drifted ... `2c69cbda` rewrote StatsSample::mbps's doc comment (goodput → attempted sealed wire bytes) without regenerating the snapshot, so `openapi_document_is_complete_and_checked_in` fails on main today. Pure regeneration, no API surface change: the description and the version stamp are the only differences.	2026-07-27 19:04:20 +02:00
enricobuehler	6be865f33f	fix(host): a host that is stopped hands the box's session back first ... Until now the host had no signal handling at all: SIGTERM killed it outright. That is fine for a host that owns nothing — but a managed gamescope takeover owns the box's session, and on a mask-fragile display manager (Nobara's plasmalogin) it has STOPPED that display manager for the length of the stream. Killed there, the host leaves a box with no graphical session and nothing left to restart it: the crash-restore state lives in $XDG_RUNTIME_DIR, which logind removes along with the user manager, so not even the next host start can heal it. `systemctl --user restart punktfunk-host` mid-stream — or a package update doing it for you — was enough to strand a box until someone reached a VT. So SIGTERM and SIGINT now restore first and exit after. The restore runs on a blocking thread (it shells out) under a 20s grace, well inside systemd's TimeoutStopSec, and a host that took nothing over exits immediately. `restore_takeover_now` is the synchronous sibling of the debounced disconnect restore, and deliberately ignores the keep-alive policy the latter honors: `keep_alive=forever` pins a session for the NEXT client, which means nothing once the host that would serve them is exiting. Both paths now share one `takeover_live()` predicate instead of repeating the four-way "is anything ours" test. Checked on Linux: clippy -D warnings on punktfunk-host + pf-vdisplay, tests, rustfmt.	2026-07-27 19:04:20 +02:00
enricobuehler	f3615f83a5	fix(gamescope): the takeover no longer kills the host it is running in ... Field report, Nobara + 0.20.0: switching into Game Mode mid-stream disconnects the client and the box never lights up again. His journal has the whole mechanism, ten seconds apart: 12:34:18.9 freed Steam: stopped the display manager for this stream 12:34:29.0 systemd[1685]: Stopping punktfunk-host.service Stopping the display manager ends the user's last login session. The packaged host is a `systemd --user` unit, so logind then stops user@1000.service once UserStopDelaySec elapses — 10s by default on Nobara — and takes the host with it. The stream dies, the scheduled restore never runs, and the display manager stays down with nothing left to restart it: a black box that needs a VT to recover. Exactly the two symptoms reported, and the intermittency is just whether an active Gaming Mode session was there to trigger the takeover at all. It never showed on the repro VM because lingering was enabled there for the earlier sessionless tests (`Linger=yes` — confirmed on the VM today), which is precisely the thing that breaks the dependency: logind keeps the user manager alive with no session. Our KDE/GNOME/Arch setup guides already ask for it; his box, following the KDE route, did not have it. So the takeover now ensures lingering BEFORE it touches the display manager: `loginctl enable-linger` directly (allow_active in logind's own policy — verified working unprivileged on Nobara), else the packaged helper gains a `linger` verb that enables it for PKEXEC_UID alone, never a caller-named user. If neither works the takeover is refused with an actionable error and managed degrades to attach — mirroring the box's own session is strictly better than a screen that needs a VT. Hosts that cannot be reached this way (root, a system unit) skip the check: the cgroup test is a pure `cgroup_under_user_manager` with a unit test, matched against the real shapes on a Nobara box (`user@1000.service/app.slice/...` vs a `session-N.scope`). Also documents the requirement in the gamescope guide's Nobara section. Checked on Linux: clippy -D warnings, 78 tests, rustfmt; helper verified with `sh -n`, and the linger enable/disable round-trip run live on the Nobara VM.	2026-07-27 19:04:20 +02:00
enricobuehler	eae1837a3a	fix(gamescope): a managed takeover never waits on a dialog nobody can see, nor acts on a months-old sentinel ... Two ways the Nobara DM-stop takeover could end a session and leave the box dark, both found while triaging a 0.20.0 field report (managed round-trip: "my client disconnects and my monitor doesn't turn back on", intermittent). 0.20.0 is the first release where that box runs the takeover for real — before it, no package shipped the polkit privilege, so managed always degraded to attach and never touched the display manager. Privileged verbs are non-interactive now. `try_stop_display_manager` and `restore_display_manager` try a plain system-bus `systemctl` first, and without `--no-ask-password` that asks polkit for INTERACTIVE authorization. On a box where the host runs inside the user's graphical session, polkit hands that to the session's agent: a password dialog on the box's own screen, which during a takeover is off or mid-switch. Nobody sees it, nobody answers it, and the call blocks on the stream's own thread — the capture-loss rebuild, or the restore worker — while the rebuild budget burns. The takeover then lands after the session it was for already ended. With the flag it fails immediately ("interactive authentication required"), which is what both callers are already written for: the packaged pkexec helper (allow_any, no agent needed) takes it from there. A sentinel with no baseline is not a request. `session_select_requested` read "no baseline recorded" as "the sentinel appeared during the session" — but `~/.config/steamos-session-select` is a permanent file, so every box whose user has ever switched sessions has one. The baseline was recorded only after a SUCCESSFUL launch, leaving a real window: takeover succeeds, launch fails, the client retries inside the 5s restore debounce (which the retry cancels), and the honor gate fires on a months-old write — pushing the box to the desktop the user never asked for, plus a 120s grace refusing to relaunch game mode. Now the baseline is taken at takeover too (setting STOPPED_DM is what arms the gate), and "never baselined" reads as no request. `SESSION_SELECT_BASELINE` carries both states explicitly, and the decision is a pure `sentinel_advanced` with a unit test for all six cases. Checked on Linux: cargo check --all-targets, clippy -D warnings, 77 tests, rustfmt.	2026-07-27 19:04:20 +02:00
enricobuehlerandClaude Fable 5	ba89b9fcd0	feat(tools): display-disturb learns the bench moves the field sessions needed ... Three upgrades from the on-glass rounds on .173/.221: - `ddc-open` timing: the handle-ACQUISITION cost per monitor is reported even when it yields no physical handles — the poller's first contact with a virtual display, exactly what the DDC-fail-fast driver work changes; the old code silently skipped handle-less monitors, which on a streaming host in exclusive topology is every monitor there is. - Monitors are labeled by GDI device name (\\.\DISPLAYn) so a virtual display and a panel are tellable apart in the correlation log. - `extend` mode: one SDC_TOPOLOGY_EXTEND poke — re-activates every attachable display, i.e. the exact 'non-managed display re-activated' event the exclusive watchdog evicts. One shot, not a loop: trigger a reassert round, observe the recovery. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 17:52:31 +02:00
enricobuehlerandClaude Fable 5	622817954a	fix(capture/win-display): a deactivated laptop panel is a named stall suspect, not a blind spot ... Field A/B (reporter, Legion 5 Pro hybrid, 2026-07-27): the ~2 s capture-stall metronome IS the exclusive isolate's own doing — deactivating the laptop panel leaves a dark-but-connected eDP head whose driver-level servicing disturbs the capture path (~1.7-2.8 s period); `topology: primary` (panel stays active) stopped it outright (16.3 stalls/min → 0). Our own .221 logged the identical signature the day before. The detector then steered AWAY from the cause: connected_inactive filtered to EXTERNAL physicals only, so the one display that mattered — on a hybrid laptop, the default config — reported as `none`. - TargetInventory: new `internal_panel` class bit (eDP/LVDS/embedded). - connected_inactive_externals → connected_inactive_physicals: internal panels join the suspect list (virtual/indirect stay excluded); a nameless panel renders as "laptop panel". - The below-OS METRONOMIC warn names the dark-panel case and its actual cures (`topology: primary`, `pnp_disable_monitors`) — the old text's "unplug it" prescriptions are impossible for an internal panel. - ddc_power_off: a zero-ack sweep now says at INFO that the axis did nothing (internal panels have no DDC/CI) instead of silently no-op'ing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 17:04:08 +02:00
enricobuehlerandClaude Fable 5	ab58fd2f0e	feat(vdisplay/driver): DDC/CI against the virtual monitor fails fast ... In exclusive topology the virtual display is the ONLY monitor on the desktop, so monitor-control software (the Twinkle Tray / PowerToys PowerDisplay / Monitorian class) aims its entire DDC traffic — brightness polls, capabilities-string requests — at OUR monitor. There is no bus and no sink; the only wrong answer is a slow one (a timeout-shaped failure occupies win32k's physical-monitor path, serialized per monitor, for its full duration). Register EvtIddCxMonitorI2CTransmit/Receive and answer every probe with an immediate STATUS_NOT_SUPPORTED, making the virtual monitor the cheapest thing on the "bus" to poll. (The receive DDI has no out-arg at the callback — refusing synchronously refuses the whole transaction.) EDID needs no equivalent: the OS serves descriptor queries from the blob supplied at monitor creation without calling the driver. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:37:06 +02:00
enricobuehlerandClaude Fable 5	1945052e66	fix(capture/vdisplay): descriptor-following defers while a topology reassert is in flight ... The exclusive-topology reassert's forced re-commit transiently bounces the virtual display's mode; the descriptor poller can sample that EVICTION state and recreate the ring at a mode the recovery chain is about to undo (field log 2026-07-27 10:30:44Z: hdr=true → false → recreate → recovery restores true → second recreate). New pf-win-display::topology_churn latch (deadline semantics — self-expiring, so a lost release can never wedge descriptor- following off): the watchdog holds it for interval+3s each fighting round and releases on "stable again"; poll_display_hdr consumes samples but acts on nothing while held — which also keeps the negotiated-depth pin-back from issuing a CCD write mid-eviction, where it would fight the reassert itself. The deliberate recreate_ring_in_place recovery path is unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:37:05 +02:00
enricobuehlerandClaude Fable 5	9e1a686795	feat(tools): display-disturb — deterministic display-stack disturbance generator ... The stall-immunity bench needs both stall classes on demand, without a standby TV or a monitor-tool storm: `ddc` replays the Twinkle-Tray/PowerDisplay-class DDC/CI traffic (VCP reads, optional capabilities-string requests) through the win32k I2C path; `modeset` re-commits the current mode with CDS_RESET — the Level-Two modeset entry that idles the whole adapter with nothing Win32-visible changing. Every op prints an epoch-stamped took_ms line so host.log stall reports correlate line-for-line, and the op duration itself measures the driver's service time per disturbance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:24:20 +02:00
enricobuehlerandClaude Fable 5	19d6f79d2d	feat(vdisplay/driver): the frame pump survives MMCSS refusal and outranks GPU contention ... Two stall-immunity hardenings for the swap-chain drain thread (branch-2 of the disturbance-immunity program — failures in OUR delivery leg, as opposed to adapter-wide display servicing, which no priority survives): - MMCSS registration fails under the restricted WUDFHost token on some boxes; the drain thread then ran UNPRIORITIZED — the whole display's frame pump at normal priority, starvable by DDC/HPD-servicing DPC pressure into multi-hundred-ms delivery holes. Fall back to TIME_CRITICAL. - IddCxSetRealtimeGPUPriority (IddCx 1.9) raises the processing device above every regular application's GPU priority. Slot availability comes from raising the exported IddMinimumVersionRequired 4 → 10, which was overdue independently: the drain loop already calls ReleaseAndAcquireBuffer2 (1.10) unconditionally, so binding a pre-1.10 framework would dispatch past the populated IddFunctions table — with 10 an old framework fails the bind cleanly instead. The product floor is already Win11 22H2 (installer MinVersion=10.0.22621, whose framework is 1.10), so no supported system changes behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:24:10 +02:00
enricobuehlerandClaude Fable 5	94f0207cbd	feat(windows/client): logs persist — %LOCALAPPDATA%\punktfunk\logs\client.log ... The shell is a windows_subsystem binary and spawns punktfunk-session with CREATE_NO_WINDOW + inherited stderr: a normal GUI/MSIX launch has no console, so every log line — the shell's and the session's whole receive/decode/present forensic trail — evaporated exactly when a user hit something worth reporting. The 2026-07 PyroWave latency-sawtooth report had to be triaged from host logs alone; the deciding evidence (clock re-sync vs backlog-flush lines) lives client-side. - New logfile module: %LOCALAPPDATA%\punktfunk\logs\client.log, the host's rotation convention (10 MB cap -> .old at next start, one generation), best-effort (no dir -> plain stderr, never a startup failure). - The tracing subscriber tees to stderr AND the file (ANSI off — the file is what users send); startup logs the path. - The spawned session's stderr is piped through the same tee, line-buffered — dev-terminal runs keep their interleaved output, GUI runs finally keep anything at all. - The --console path and the punktfunk-console.exe MSIX shim forward the same way (a couch launch has no console either). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	2c69cbdab9	docs(host/stats): say what the stats actually measure — three field-triage traps ... Three lines that each sent the 2026-07 PyroWave field triage down a wrong path, made honest: - The 'client accepts streamed AUs … will stream per-slice' log fires before the encoder exists and regardless of backend support (only Linux direct-NVENC implements chunked polling) — it now states the client capability only. - StatsSample::mbps was documented as 'transmit goodput'; it is attempted sealed wire bytes at seal time — AU bytes + shard framing + FEC parity (+ PyroWave window padding), not reduced by socket send drops. - The per-stage split's 'encode' stage is the poll() duration, which is ~0 by construction for synchronous backends (PyroWave encodes inside submit → its time shows as 'submit') — documented at the split's definition so 'encode 0.00' stops reading as an instrumentation hole. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	d8d8c6c43d	fix(core/abr): the capacity probe's own overload no longer reads as session congestion ... The startup speed-test probe deliberately overloads the link (2 Gb/s for 800 ms) to measure capacity. The report tick is suppressed while it runs and the window anchors are rebased when it ends — but two residues leak past the rebase: probe frames still pending in the reassembler age out as frames_dropped for another ~120 ms (the loss-window fuse), and the burst can latch flush_in_window (a jump-to-live it caused itself). Either one reads as a SEVERE window: the controller backs off ×0.7 and — worse — slow start ends at the first congestion signal, permanently. That is precisely the 2026-07 field report's Automatic session: 20→14 Mb/s exactly one report tick after the probe, then a purely additive +6 %/4.5 s crawl that took the whole 4.5-minute match to reach 308 Mb/s on a link the probe had just measured at ~1.2 Gb/s. Slow start (doubling per clean window to the probed ceiling, 'seconds instead of minutes') never got to run. The first post-probe report window is now discarded outright: no LossReport (probe residue would also spike the host's adaptive FEC), the standing-latency detector closes it as not-loss-free (its clean-run just resets), and the ABR is fed nothing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	b8b8ac336c	feat(core/client): all-intra streams drain the frame channel to the newest AU ... The pre-decode FrameChannel is strictly FIFO because H.26x reference chains forbid mid-stream drops — falling behind is only recoverable via the coarse jump-to-live thresholds (depth ≥6 sustained, or 400 ms behind the capture clock) at the cost of a keyframe round-trip. PyroWave has no reference chains: every AU decodes independently, so a slow consumer can skip straight to the newest queued AU with zero recovery cost. The pump now flags the channel all-intra for PyroWave sessions and pop() drains to the newest, which caps any standing pre-decode queue at ~1 frame structurally — the 2026-07 field report's 780M client could otherwise ratchet a real multi-frame backlog (and with it the OSD latency) between those coarse thresholds. Skips are counted separately from losses (they were delivered, just superseded) and surfaced at debug on the report tick — the OSD 'lost' line keeps meaning wire loss. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	6d1baa0add	fix(pf-encode/pyrowave): the bitrate pin holds on the WIRE, not the raw bitstream ... A datagram-aligned PyroWave session inflates the codec bitstream ×1.2–1.3 on its way to the wire — greedy packing of few-hundred-byte atomic block packets into 1408 B windows zero-pads most window tails, plus the 4-byte prefixes and FRAG chains. The 2026-07 field report's 1440p60 10-bit "Automatic" pin of 407 Mb/s put a measured 550 Mb/s on a 1 GbE link; nothing enforced the pin past the rate controller. New shared WireBudget (pyrowave_wire.rs, both backends): tracks the real per-frame AU/bitstream ratio as a ×1024 fixed-point EMA (prior ×1.25, weight 1/8, clamped ×1.0–×2.0) and deflates the budget handed to pyrowave's rate control by it, so the windowed AU lands on the configured rate. Sealed-datagram framing (+4.5%) and FEC parity stay uncompensated — H.26x sessions carry those on top of the configured bitrate too, and the pin must mean the same thing for every codec. Dense (non-chunked) sessions are untouched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehlerandClaude Fable 5	53640b8754	fix(core/clock): re-sync survives loaded links — floor baseline, spaced rounds, bounded staleness ... The mid-stream clock re-sync starved on high-bitrate LAN sessions (2026-07 PyroWave-sawtooth field report, RX 9070 XT -> 780M @ 550 Mb/s): every batch was judged against the CONNECT-TIME RTT, measured before the video data plane existed, with a 2 ms floor — mid-stream control RTTs on a loaded GbE link sit above that almost permanently, so batches were rejected for minutes while the wall clocks drifted apart and the OSD e2e figure ramped 19->150 ms before snapping back on a lucky batch. Three changes: - Rounds are spaced 7 ms apart (stamped at send time, so the spacing never lands in the RTT). An 8-round batch used to complete inside ONE ~6 ms video burst — all rounds sampled the same congestion state; spacing walks them across the frame cycle so the min-RTT round finds a quiet gap. - ResyncGuard replaces the static baseline: the guard band follows the best RTT the session has evidenced (connect RTT, then min over every completed batch — rejected ones included). - Rejection streaks are bounded: after 3 consecutive rejections the best (min-RTT) batch of the streak is applied anyway. Its queueing bias is at most ~half its RTT; unbounded wall-clock drift costs more per minute. Rejections now log at warn with the streak and floor — the starvation signature is grep-able in exactly the logs users send. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 12:51:11 +02:00
enricobuehler	94b7a834cb	fix(installer/windows): GameStream is opt-in, not on by default ... A user found this in their log and had never been offered a choice: WARN GameStream/Moonlight compat ENABLED (--gamestream): its pairing runs over plain HTTP and its legacy control encryption can reuse GCM nonces (security-review #5/#9) — an on-path LAN attacker could MITM pairing or recover input. Enable only on a TRUSTED network. They were right. The `gamestream` task carried no `Flags: unchecked`, so it was pre-ticked; and since a silent install takes the wizard's own task defaults (1839d756), a winget install turned it on with no checkbox ever shown. The host warns that this plane is a security downgrade on every single start, so having the installer enable it by default cannot be squared with our own advice — least of all on the path where nobody sees a wizard. Now unchecked, matching `allowpublicfw`, the other task with a security consequence. A default install therefore lands `PUNKTFUNK_HOST_CMD=serve`, the native-only host; Punktfunk's own clients are unaffected, since the native punktfunk/1 plane is always on. Unattended opt-in is `/MERGETASKS=gamestream`. Scope, deliberately: this changes FRESH installs only. `GamestreamParam` already omits the flag entirely unless `FreshHostInstall`, so no existing host has its choice touched by an upgrade, and anyone relying on Moonlight today keeps it. `DEFAULT_HOST_CMD` (the service's fallback when host.env carries no PUNKTFUNK_HOST_CMD line at all) is deliberately NOT flipped here: the installer always writes the line explicitly, so it does not affect a normal install, and inverting it would silently disable Moonlight for anyone whose host.env lost that line — a runtime regression that belongs in its own change, if at all. Docs corrected everywhere they stated the old default, since three of them now told users the opposite of what ships: the winget Agreement shown BEFORE install (it said "enabled by default" and gave the opt-OUT override), the Windows packaging README, and host.env.example. The `--override` example in the installer manifest is inverted with it (`/MERGETASKS=gamestream` to add, `!` to remove). Verified: [Tasks] + [Code] compile with ISCC 6.7.1 on the windows-amd64 runner (all optional features defined), and the winget catalogue rebuilds and passes 29/29 with the edited manifests.	2026-07-27 12:26:47 +02:00
enricobuehler	4114dfeff7	fix(winget): the Log switch used |LOGPATH|, which winget never substitutes ... Second field report on 0.20.0's winget path, and independent of the conflict abort in 37781a61: an INTERACTIVE install through UniGetUI dies before the wizard with Inno's "Error creating log file: The filename, directory name, or volume label syntax is incorrect." `<LOGPATH>` is winget's own token and the only spelling it replaces — the schema this manifest declares says so verbatim ("<LOGPATH> token can be included in the switch value so that winget will replace the token with user provided path"). We shipped `|LOGPATH|`, which is not a token, so winget passed the literal string to Inno; `|` is not legal in a Windows filename, and Inno refuses before doing anything else. Worse than the conflict abort in two ways: it is not confined to silent installs — it fires in EVERY mode for any caller that requests a log — and UniGetUI requests one by default, so a GUI user cannot install at all. Confirmed against the live source, which is serving the broken switch to everyone right now: curl -s https://winget.punktfunk.unom.io/packageManifests/unom.PunktfunkHost → "Log": "/LOG=\"|LOGPATH|\"" Guarded by the suite that exists for exactly this class of defect (a wrong response shape does not fail loudly — winget just says "no package found"). The new check accepts an absent Log switch, requires <LOGPATH> when present, and rejects any |TOKEN| spelling. Mutation-verified: restoring |LOGPATH| fails the check naming the offending value, and the corrected manifest passes 29/29. ⚠ Fixing the template does NOT fix the live catalogue: it is derived from the manifest trio attached to each release, so the corrected switch only reaches users when a release carries it.	2026-07-27 10:28:59 +02:00
enricobuehler	37781a610f	fix(installer/windows): only a host that will actually RUN is a conflict ... Field report within hours of 0.20.0 (HitFrostbite): `winget install unom.PunktfunkHost` fails with "Installer failed with exit code: 1", 0x8A150006, after the hash verifies and the install starts. That is Setup aborting on purpose. `StreamHostPresent` counted a conflicting host as present if its SCM service key existed at ANY start type, OR if a bare Program Files\<Name> directory existed — so a disabled service, or a folder left behind by an uninstall, read as a live conflict. 3d893013 then made the warning a SuppressibleMsgBox defaulting to IDNO so unattended installs could not hang on it; under winget's /VERYSILENT /SUPPRESSMSGBOXES that default aborts InitializeSetup, and Inno exits "failed to initialize" = code 1. Net effect: anyone with Sunshine on disk — the exact audience most likely to migrate — could not install via winget at all, with no visible reason. The other candidate for exit 1 is excluded rather than assumed: the manifest declares MinimumOSVersion 10.0.22621.0 matching the script's MinVersion, so winget refuses an unsupported OS BEFORE downloading, and the report shows the hash verified and the install starting. The conflict check is also the only `Result := False` in InitializeSetup. Detection now keys on the service's `Start` value (0 boot / 1 system / 2 automatic / 3 manual / 4 disabled), counting only 0-2 — a host that comes up on its own is the only kind that can take the GameStream ports or load a second virtual-display driver. Directories no longer count at all: they were the noisiest signal and the one that survives an uninstall. This makes the installer agree with the tray, which dropped its always-on warning over a merely-INSTALLED Sunshine in this same release (3e782852) for exactly the same reason. The message now says "installed and set to start automatically" and offers disabling the service as a remedy, both of which are what is actually detected. A conflicting host running as a plain user process is deliberately not detected: pure Pascal cannot enumerate processes, it is a runtime rather than install-time condition, and the host already reports it via the `punktfunk::detect` startup warning, `detect-conflicts`, and /api/v1/local/summary. Verified by compiling the [Code] section with ISCC 6.7.1 on the windows-amd64 runner (WithWeb defined, as CI does). That caught two defects in my own first draft that review would not have: a continuation line STARTING with #13#10, which ISPP reads as a preprocessor directive ("Unknown preprocessor directive", compile aborted), and `{commonpf}` written inside a `{ }` comment, which closes it early since Inno comments do not nest. Both are noted at the sites so they are not reintroduced.	2026-07-27 09:00:34 +02:00
enricobuehler	ec9aa415f6	chore(web): override brace-expansion to 5.0.8 — clears GHSA-mh99-v99m-4gvg ... bun-audit has been red since the advisory published, so it was already failing before v0.20.0 was cut (same failure on 0323158a). High-severity DoS: unbounded expansion length causing an OOM crash. All three paths are dev tooling — orval→typedoc→minimatch, @storybook/react-vite→glob→minimatch, and nitro-v2-vite-plugin→nitropack→archiver→archiver-utils→glob→minimatch — so nothing shipped to a user was exposed, but the leg gates every lockfile change. Done as an `overrides` entry, joining the eight already there for exactly this purpose. `bun update brace-expansion` is NOT the fix and was reverted: for a package that is only transitive it adds a spurious DIRECT dependency, and it does not even resolve the advisory — it hoists 5.0.8 for the new direct dep and leaves `minimatch/brace-expansion` pinned at the vulnerable 5.0.7. The advisory's affected range is `<= 5.0.7` across ALL majors with 5.0.8 the only patched version, so the two nested 2.1.2 copies had to move too — a major bump for consumers declaring ^2.0.1/^2.0.2. Checked rather than assumed: 5.0.8 is dual ESM/CJS with a real `require` branch in its exports map (2.1.2 was plain CJS), so those consumers still resolve. Proven by building: the nitro build is itself one of the forced consumers. Verified: `bun audit` reports no vulnerabilities, both nested entries are gone from the lock, and the full CI web sequence is green — `bun install --frozen-lockfile --ignore-scripts`, `bun run build`, `bun run lint`.	2026-07-27 07:32:08 +02:00
enricobuehler	24d2f97eae	fix(ci/winget): forward GITHUB_REF_NAME into the remote shell ... The catalogue-verify step has failed on every stable tag since it landed, v0.20.0 included: `bash: line 6: GITHUB_REF_NAME: unbound variable`, twice, then exit 1. `env:` populates the RUNNER's environment. appleboy/ssh-action executes its `script` on the REMOTE host over SSH, which inherits none of it — the action has a separate `envs:` input naming the variables to forward. Without it the `set -u` at the top of the script turns the first expansion into a fatal, and the two `curl`s either side report only the collateral: `Failed writing body` is curl losing its pipe when the `grep` it was feeding died. The failure is maximally misleading, because everything it guards ALREADY WORKED: the catalogue is built, tested and shipped in the preceding steps, and only the proof-of-serving fails. Confirmed by hand against the live source during the v0.20.0 release — it serves unom.PunktfunkHost 0.20.0 correctly. The pattern was already right everywhere else: both "Pull and start docs" steps (deploy-services.yml, docker.yml) pair `env:` with `envs:`. A sweep of the other three ssh-action steps found no further instance — the remaining two pass no variables at all.	2026-07-27 07:31:55 +02:00
enricobuehler	c9b8f666cd	docs(release): winget needs its source added first — say so ... Reported within an hour of the announcement: `winget install unom.PunktfunkHost` answers "no package found". That is correct behaviour, not a broken package — Punktfunk is served from its own REST source, and winget only searches sources it has been told about. The notes said "after adding Punktfunk's package source once" without ever giving the command, so there was no way to act on it. Both commands are now spelled out, the `winget source add` one flagged as needing an Administrator terminal (it does), and the failure mode is stated explicitly so someone who hits it recognises it rather than filing it as a bug. The lead-in is untouched, so the Discord embed for v0.20.0 stays accurate and this needs no re-announcement — the release body is re-synced from this file.	2026-07-27 07:31:37 +02:00
enricobuehler	35b6c835fd	docs: on a gamescope session the display outranks the end-game setting ... On-glass on .41: with `game_on_session_end: keep` — "leave it running, nothing is ever closed" — a deliberate stop ended the game, and a drop ended it ~14 s later. Both times the LEASE did the right thing (no `ending the launched game` line); the game died because the virtual display was torn down, and a nested launch runs inside that gamescope. So on a dedicated gamescope session the game's lifetime IS the display's, and keep-alive decides it — not this setting: * a deliberate stop skips the linger by design, so the game goes at once, * a drop lingers the keep-alive window, then takes the game with it, * only keep-alive Forever actually keeps it — and `always` still ends it at the reconnect window, which is the documented precedence and was verified (a `forever`-pinned display released at grace expiry, 60.006 s). That makes the console's promise untrue on the most common Linux setup, so the card now says so for every option rather than only warning about `always`, and the docs get the three cases as a table. Worded so a non-gamescope host reads it and moves on — a desktop-session launch is an ordinary process and none of it applies. Not changing behavior here: making `keep` pin the display would pit it against "a stop must not leave a ghost display", and which wins is a product call rather than something to decide silently mid-test. web: codegen + tsc + biome clean, en/de complete. docs-site: build + tsc clean.	2026-07-27 01:43:40 +02:00
enricobuehler	39a9f09f04	fix(mgmt/web): the running-game cover slot says "game" when there is no art ... Rendered the Dashboard stories headlessly and looked at them, which is how this turned up: with no cover the slot was an empty grey rectangle, reading as something that failed to load rather than something absent. Plenty of rows will never have art — an operator-typed command has no catalog entry behind it, a custom entry may carry none, and nothing does until `/library` has loaded. The slot keeps its fixed size so rows stay aligned when only some titles have covers; it just holds a gamepad glyph instead of nothing.	2026-07-27 00:47:05 +02:00
enricobuehlerandClaude Opus 5	f57fc85d34	chore(release): bump workspace version to 0.20.0 ... 117 commits since v0.19.2. Minor rather than patch: the headline is the session⇄game lifetime binding on both planes and both platforms — the stream ends when the game does, and optionally the reverse — plus library metadata, winget packaging for the Windows host, a 64-bit ARM Linux client, headless `--pair` enrolment, DRM card selection for the compositor-less presenter, and the ABR/latency de-escalation work, which changes runtime behaviour on every session. Wire protocol stays at 2, the embeddable C ABI at 13 and the Windows virtual-display driver protocol at 6, so 0.18/0.19/0.20 hosts and clients mix freely and no embedder rebuild is required. The new GameMeta library fields are optional and flat on the wire. Notes authored ahead of the tag per docs/releases/README.md, so the release is born with a body. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> v0.20.0	2026-07-27 00:33:45 +02:00
enricobuehlerandClaude Fable 5	0323158a3e	fix(vdisplay/gamescope): a fresh dedicated launch streams from the first second ... A freshly spawned headless gamescope never delivered a single PipeWire buffer when a game was launched: gamescope only composites (and only on a composite pushes a capture buffer) when a client paints, and a nested Steam bootstrap paints nothing until its UI's first frame — far longer than the 10 s first-frame budget. The native plane's retry ladder then killed the half-booted Steam on every attempt and started from zero; the GameStream plane died on its single wait. Reused live displays worked, which pointed away from the real cause (root-caused on .41 with a raw pw_stream probe: `sleep infinity` nested → 0 buffers ever, `vkcube` nested → 60/s immediately). Every bare spawn now backgrounds the host's own splash client (`gamescope-splash`, hidden subcommand) beside the nested app: a dark window with a subtle breathing bar painted at ~2.5 Hz — damage from the first second, so capture gets its first frame within the budget on both planes. In `--steam` mode gamescope composites only windows whose appid is in the root `GAMESCOPECTRL_BASELAYER_APPID` list (live-proven: even a painting vkcube gets zero composites without it), so the splash declares itself as the Steam UI (STEAM_GAME=769) and seeds the baselayer iff unset; Steam's own rewrite at game launch hands composite focus to the game with no action on our side. PUNKTFUNK_GAMESCOPE_SPLASH=0 is the escape hatch. The dedicated Steam launch is also shaped with `-gamepadui` instead of `-silent`: the nested Steam is Big Picture — the identity gamescope's `--steam` integration is built around — so the boot shows the gamepad UI instead of the desktop client window flashing through the stream, and gamescope's focus rules (game outranks the Steam UI appid) cover what `-silent` was working around. On-glass on .41 (Bazzite, RTX 5070 Ti, gamescope c31743d): cold connect + Balatro launch delivers frames on the first attempt on both a cold and a torn-down-then-fresh spawn; Big Picture boot → game handover confirmed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 00:28:59 +02:00
enricobuehler	980b399ea8	test(session/gamelease): the live-process test waits out the shim window ... Its child is `sh` running a script that `exec`s a binary outside the install dir, so neither the image path nor the command line carries the directory — the host's own child is the only signal there is. Which is exactly the case the shim window now gates: a live child that might still turn out to be a launcher is not called the game until that window passes. So "running" legitimately arrives up to SHIM_WINDOW later than it used to, and the assertion at 1.5 s was asserting the old behavior. Waiting it out is the point now, not an accident of timing. The delay is the deliberate cost of the fix: until the window passes there is no way to tell "the child IS the game" from "the child is about to hand off". It shows as a few seconds of `launching` in the console, and only for a title whose store gave us signals. .25: the ignored live test passes (Child -> Running -> terminate via the SIGTERM->SIGKILL group ladder -> Exited, session-end action correctly NOT fired), full suite 305 passed.	2026-07-26 22:33:42 +02:00
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	0c261de636	ci(plugin-kit): quote the step name that contains a colon ... `- name: Repair the file: dependency (…)` is not valid YAML — the unquoted `file: ` reads as a second mapping key — so the workflow has been unparseable since it was added, which is why re-pushing the tag never triggered a run and a manual dispatch 500'd. I had put that down to a Gitea tag quirk; it was this. The failure is invisible from the repo side: nothing validates workflow YAML on push, and an unparseable workflow simply never runs.	2026-07-26 20:45:58 +02:00