2468 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	55bc664eca	docs(pf-bitstream): the two upstream cros-codecs bugs are now reported ... PROVENANCE deviations #6 and #7 carried 'report upstream' — done: - chromeos/cros-codecs#99: h264 PictureData display_resolution double-counts the left/top crop and underflow-panics on parser-valid crop offsets (answers their open #81). - chromeos/cros-codecs#100: h265 parse_slice_header index-OOB panic when num_long_term_sps + num_long_term_pics > 16 — a hostile-input panic on the LTR path (an instance of their #78). Both reports offer the downstream patch for the AOSP tree.	2026-08-06 00:44:18 +02:00
enricobuehler	a34f4051fc	feat(pf-vkdecode): the CPU half of HEVC decode — StdVideo H265 conversion + slot map ... M3 WP-2, first half. params_h265.rs: VPS/SPS/PPS -> StdVideoH265* with owned pointer-backing (the params.rs contract), scaling lists incl. the 32x32 two-matrix quirk and +8 DC convention, short-term RPS re-encoded from the parser's RESOLVED DeltaPoc arrays back into delta_poc_sX_minus1 syntax under monotonicity checks, fallback_vps_from_sps for streams whose VPS NALU was lost. pic_h265.rs: plan_to_vk_h265 — h265 AuPlan -> StdVideoDecodeH265PictureInfo + per-reference infos; the binding set is the union of the three current RPS sets with the Std index arrays indexing into refs (0xFF unused; the GPU half must lay pReferenceSlots out in refs order); NumDeltaPocsOfRefRpsIdx from the predicted-from candidate; transactional SlotMap lifecycle identical to pic.rs. SlotMap reused unmodified — HEVC's ceiling equals H.264's 16+1. Envelope fails closed: Main/Main10/MainStill/RExt only, 4:2:0-8/10 + 4:4:4 only (separate_colour_plane_flag rejected — ChromaArrayType 0 in disguise), SCC palette predictors out, >64 ST RPS sets / >16 per side / >32 LT SPS candidates out, checked narrowing on every narrower Std field. No panics on untrusted input. Review round 9 (adversarial): RPS re-encode math, Std field-by-field conformance, transactionality and slot ceiling verified clean; 6 findings fixed pre-commit. Headline (BLOCKING): long_term_ref_pics_ present_flag=1 with num=0 left pLongTermRefPicsSps NULL — the header demands a valid pointer whenever the flag is set, and flag=1/num=0 is exactly the punktfunk LTR/RFI recovery stream shape; the all-zero backing now rides whenever the flag is set. Also: the slice_offsets doc in BOTH pic modules claimed submit-as-planned while decoder.rs packs slices-only and rebases (non-VCL NALUs in the decode range hang VCN firmware) — reworded so the HEVC GPU half cannot implement the hang; a concealment-produced ST/LT duplicate now ORs the long-term flag across occurrences; NumDeltaPocs clamps became a typed error; dead UnmappableLevelIdc variant dropped. Deferred to the GPU half: HEVC caps/profile chain, session parameters (VPS leg in the ledger), P010/4:4:4 pool selection, recording, and the pReferenceSlots-in-refs-order contract consumption. Gates: fmt clean; mac pf-vkdecode 80 + pf-bitstream 69 green, clippy clean; container clippy -D warnings zero (pf-client-core, pf-presenter, pf-vkdecode) + tests green (69/121/80).	2026-08-06 00:41:23 +02:00
enricobuehler	370b0ab494	feat(client): native Vulkan decode joins the automatic ladder, above FFmpeg-Vulkan ... Closes M2. The 2026-08-05 ladder decision: WP-D shut with bit-exact parity vs libavcodec (250/250 AUs on RADV, AMD-proprietary and NVIDIA) and a 92-minute clean soak, and the program's goal is dropping FFmpeg from the client — so on H.264 sessions where caps pass, auto now tries pf-vkdecode FIRST, exactly where the ladder would reach FFmpeg-Vulkan. No bake period. native_vulkan_gate widens from by-name-only to the auto family (auto/""/hardware); the vendor-first rungs are untouched (Linux Intel/unknown still VAAPI-first, Windows Intel/unknown still D3D11VA-first — NVIDIA and ALL AMD go native first). A native INIT failure or caps refusal logs and falls through to FFmpeg-Vulkan, so admission can't cost a session its decoder at start; runtime error streaks ride the existing demotion machinery unchanged (past FFmpeg-Vulkan to VAAPI/D3D11VA/software — a native→FFmpeg-Vulkan runtime rung is deliberately absent, FFmpeg is on its way out). PUNKTFUNK_DECODER=native-vulkan stays as the explicit pin; vulkan keeps naming the FFmpeg backend specifically. A native_tried guard keeps a failed pin init from re-attempting construction in auto. Review round 8 (adversarial): no blocking code defect — no demote bounce-back (Decoder::new is session-start-only; demotion mutates in place), no double attempt, no cfg imbalance. 5 findings fixed: two doc overclaims ("nothing regresses" now scoped to init; the ladder enumerations no longer claim desktop-AMD Linux is VAAPI-first — prefer_vulkan_first is vendor-wide), stale opt-in claims in Cargo.toml, stale user-facing ladder text (console-ui row, trust.rs decoder field, session README incl. the env-knob list), and the gate test now pins the H264 codec-op bit to the literal 0x1 so a typo'd constant can't make native silently never engage. Gates: fmt clean; container clippy -D warnings zero for pf-client-core + pf-presenter + pf-vkdecode; container tests green (pf-client-core lib + pf-vkdecode + pf-bitstream); pf-console-ui check clean; mac pf-vkdecode/pf-bitstream/cros-codecs 167 tests green. On-glass sanity CLOSED 2026-08-05 ~22:10 UTC on .173 (4090, coincide mode), decoder=auto and NO env var: the ladder picked native on its own ("pf-vkdecode auto rung" log line), 525/526 stats windows on native-vulkan over ~8m46s / 31550 frames, fps 0/59.4/61 with 6 windows <55 incl. startup zeros, bad-signature grep over the whole log EMPTY, zero TDR events, host service Running after teardown.	2026-08-06 00:12:35 +02:00
enricobuehler	cf5db2d485	feat(pf-bitstream): H.265 DecodePlan layer — M3's AU-to-hardware contract ... H265Planner mirrors the H.264 layer's contract exactly: plan_au -> AuPlan { picture, slices with ref lists by stable PicId, DpbUpdate, warnings }, same concealment posture (warnings never abort, in-place reference substitution preserving ref_idx positions, outputs survive failed AUs, flush gates on AwaitingIdr, any IRAP resumes). Ported logic: RPS 8.3.2 (short-term AND long-term incl. PocLsbLt/MSB-cycle - the hosts' RFI recovery rides long-term refs), ref lists 8.3.3/8.3.4, DPB C.5.2.2/C.5.2.3 via the vendored dpb; POC 8.3.1 from the vendored PictureData. Written fresh: the plan surface, AU walk, envelope gates (multilayer, interlaced, SCC self-reference, DPB>16, conf-window overflow - checked at EVERY activation, not just parse), HEVC recovery-point SEI (prefix NALU 39, se(v) recovery_poc_cnt), VUI colour with E.3.1 inference, and a test-only HEVC bitstream synthesizer (upstream has none). Upstream deviations worth naming (all in-code with spec anchors): the empty-RPS inter slice cannot infinite-loop (upstream bug); RASL behind a joined CRA refuses BEFORE any state change (PlanError::RaslSkipped - the WP-2 wiring must map it to skip, not reanchor; module docs carry the contract note); MaxPicOrderCntLsb reads from the ACTIVATING SPS (upstream latches at parse - a latent multi-SPS bug); C.5.2.2's exemption is picture 0 of the BITSTREAM (EobNut), never first-after-EOS. Vendored parser gained PROVENANCE deviation 7 (report upstream): hostile slice headers with num_long_term_sps+num_long_term_pics > 16 indexed out of bounds of SliceHeader's [_;16] arrays - a production panic on exactly the long-term-reference path, now a parse error. Port review round 7: 10 findings (3 blocking: the vendor panic, an EOS-boundary output interleave, an envelope bypass through PPS-only SPS rebind reaching wrapping crop arithmetic) - 9 fixed with a regression test each, 1 documented as the WP-2 contract note. Known follow-up: the h264 AU-tail truncation detector shares h265's dead-arm shape (its arm also cuts reserved NALU types, so the fix is not identical - deferred). Tests: 29 h265 planner + 2 HEVC SEI + full test-25fps.h265/bear/bbb clip walks with real invariants (every stored id output exactly once, ascending POC per IRAP period). Gates: fmt clean; clippy -D warnings zero (mac + pf-lxcheck2 incl. pf-client-core/pf-presenter); tests 45+69 mac, 69+121+53 container.	2026-08-05 23:29:45 +02:00
enricobuehler	dc0766b2f3	fix(client): the native rung now follows the stream's colour and reports true decode latency ... The round-4 residuals, closed after the WP-D hardware verdict: - VUI colour plumbing (the one silent-wrong): the picture's ACTIVE SPS's colour signalling (H.273 code points + range, with E.2.1's 'unspecified' inference where the VUI is silent — the vendored parser's defaults ARE the inferred values, verified) rides PicturePlan -> DecodedVkFrame -> NativeVkFrame per frame, never latched: the Windows host switches an HDR desktop to PQ/BT.2020 IN-BAND while the Welcome still says SDR. Before this, the native path would have painted PQ washed out, silently. - Native decode-latency stat: the deliberately-deferred NativeVk arm of the pump's sampled once-per-stats-window decode measurement now feeds - the frame's (semaphore, semaphore_value) is the decode-done signal, resolved through the shipped ledger before a bounded, pure-measurement vkWaitSemaphores (VkH264Decoder::wait_decoded). - The renegotiation-teardown window is settled as NO HOLE: rebuild_state now documents the full safety argument (graveyarded pools stay intact under presenter holds, tokens route strictly by generation, session objects die only post-drain with the generation gate INSIDE read_status), and the two backend comments that wrongly claimed stale pools were 'gone' are fixed. - VK_KHR_unified_image_layouts stays deferred (fleet drivers lack it). Adversarial review round 6: 3 minor findings (2 doc fixes applied; the SPS-replaced-without-PPS-resend divergence stays a documented envelope assumption - hosts re-send both at every keyframe, and a hardening PlanWarning could cost real frames on a false positive). Gates: fmt clean; clippy -D warnings zero (mac + pf-lxcheck2 container, incl. pf-client-core/pf-presenter); tests 45+30+53 mac, 30+121+53 container.	2026-08-05 22:22:03 +02:00
enricobuehler	e6d6498a49	test(pf-vkdecode): frame-hash parity vs libavcodec — bit-exact on the whole fleet ... WP-D parity A/B. gpu_parity (ignored) decodes the conformance vector, reads every frame back through the presenter's exact contract (wait, layout round-trip, signal-back, release), crops at the copy so pitch can never leak, and compares SHA-256s in display order against goldens from ffmpeg software decode — cross-checked bit-identical between ffmpeg 8.0.1 (linux) and 8.1.1 (macOS), so the reference is the spec, not one build. PF_VKD_TEST_READBACK=1 is the one test-only hook (ORs TRANSFER_SRC into pool usage; production pools stay zero-copy-tight). Fleet verdict: 250/250 frames bit-identical to libavcodec on RADV (Mesa 26.0.3, distinct), AMD proprietary Windows (25.10.30.02, distinct) and NVIDIA Windows (610.88, coincide) — H.264 decode is exactly specified, and the native path meets the spec on every driver and both DPB arrangements.	2026-08-05 20:23:18 +02:00
enricobuehler	ca92dab6fd	fix(pf-vkdecode): prefer DEVICE_LOCAL, never require it — NVIDIA runs; both DPB modes hardware-green ... Session-memory and image allocation now honor each binding's memoryTypeBits with DEVICE_LOCAL preferred, not required: NVIDIA 610.88 legally places a video-session binding in host-visible-only memory and the hard requirement refused the whole device. The bitstream ring keeps its hard HOST_VISIBLE|COHERENT need. Smoke test gains PF_VKD_SMOKE_VENDOR device pinning + attribution and a final-state print (DPB mode now observed, not inferred). On-glass matrix after this fix (.173, vendor-pinned): NVIDIA 4090 PASSES in COINCIDE mode — the first end-to-end run of the RESULT_STATUS query path, ~44 per-frame driver verdicts on the recording pattern that hangs RADV's VCN — and Adrenalin re-passes in distinct mode unchanged. With RADV's distinct pass, both DPB arrangements and three of four desktop drivers are now hardware-validated; Intel remains a clean caps refusal (no SAMPLED on decode outputs — its rung stays D3D11VA). Gates: fmt clean, clippy -D warnings zero, 45+27+53 green both platforms.	2026-08-05 20:03:25 +02:00
enricobuehler	6331ae7fd9	fix(pf-vkdecode): zero-copy pool model + the two faults the first hardware run found ... WP-D leg 1 (.25 RADV, distinct mode) root causes, both real: 1. Output starvation: the fixed 4-deep ring lost to a stream that keeps max_dpb_frames+1 = 8 pictures pending. Zero-copy fix (user requirement, no copies): one picture pool of required_slots + HOLD_HEADROOM(8) images decoupled from DPB slots — a re-activated slot binds a fresh free image, so a delivered picture is never a decode target; the WP-B pin layer became dead and is deleted. Per-image timeline semaphores carry the AVVkFrame contract: decode signals value+1, the presenter waits and signals back, later decodes wait the image's latest value — layout traffic ordered against reference reads with no copy anywhere. 2. RESULT_STATUS queries HANG RADV's VCN firmware (ring timeout, DEVICE_LOST): queryResultStatusSupport=false on the decode family. Queries are now caps-gated; without them poll/wait degrade to timeline-completion verdicts (FFmpeg parity — and the likely reason upstream never wired nb_queries). The Ally-X-class detection runs where drivers advertise the query; .173 probes NVIDIA/Windows-AMD. Also: slice-only bitstream feeding (the field-proven consumer shape), graveyarded pool retirement keyed by release tokens + generation, decode-current-AU-before-status attribution, take_ready drained, H264-bit gating, teardown short-circuit on disconnected channel. On-glass: 48 AUs green on .25 holding 4 frames like the real client. Gates: fmt clean, container clippy -D warnings zero, 27+121+52 green both platforms.	2026-08-05 19:12:20 +02:00
enricobuehler	d0659d2b61	feat(client): wire the native Vulkan decoder in behind PUNKTFUNK_DECODER=native-vulkan ... M2 WP-C. video_vk_native.rs adapts the presenter's VulkanDecodeDevice to pf-vkdecode (queue lock shared only when the families actually collide — the one case the 2026-07-09 DEVICE_LOST race proved matters), and the presenter consumes DecodedImage::NativeVk on its own device: no handle import, no AVVkFrame co-authoring — wait the timeline, barrier to sampled, existing crop-aware CSC, barrier back, release after the fence. Frame lifetime is a token: presented, retired, displaced or dropped mid-demotion, the guard's drop sends it exactly once; the backend releases the decoder slot only after the status query resolves, so a recycled slot can never report a false Failed. Driver-reported decode failures and plan warnings ride the existing streak/reanchor machinery — the Ally X corruption class is now a visible error, not a silent frame. Opt-in only until WP-D's on-glass parity verdict; H.264 sessions only; failures demote to the existing ladder. Known WP-D items recorded in code: coincide-mode cross-queue reference overlap, renegotiation teardown window, VUI colour plumbing. Gates: fmt clean; container clippy -D warnings zero for pf-client-core + pf-presenter + pf-vkdecode; 121+53+27 tests green.	2026-08-05 17:57:12 +02:00
enricobuehler	540c0d3027	feat(pf-vkdecode): the GPU half — session, DPB pools, decode recording, status queries ... M2 WP-B. VkVideoSessionKHR lifecycle with drain-before-destroy on parameters recreation, DPB pools in both coincide and distinct modes (caps-derived, usage/flags validated against the driver's format properties), an aligned bitstream ring, vkCmdDecodeVideoKHR recording with one-shot RESET re-armed on failed submits, timeline-semaphore completion, and the per-op RESULT_STATUS query ring — the signal FFmpeg's hwaccel never reads and the reason this program exists. Frame lifetime is two-phase by construction: release_frame pins a delivered frame's slot against reuse, closing the coincide-mode overwrite the adversarial review round proved (a full DPB handed a just-returned frame's image back as the same call's decode target). Nine review findings fixed pre-commit; a counterfactual test pins the collision. Generation-stamped frames, memory-type misses as errors, granularity-aligned extents, level gate. AuPlan now carries its activated SPS/PPS (Rc) so backends never re-parse. GPU smoke test (ignored) decodes 48 AUs past DPB-full with releases — the fleet runs it in WP-D. Gates: fmt clean, clippy -D warnings zero, 45+27+53 tests green on macOS and the linux/amd64 container.	2026-08-05 16:44:44 +02:00
enricobuehler	d24f7fc6ac	feat(pf-vkdecode): the CPU half of native Vulkan decode — StdVideo conversion + slot map ... M2 WP-A (design/client-native-decode.md §3.2). AuPlan -> StdVideo parameter sets (owned pointer backings), per-AU decode info with slice start-code offsets, and a PicId->slot map that never evicts on its own. Deliberate rejections over silent claims: FMO, separate colour planes, DPBs deeper than 16 frames (unbounded VUI ue(v)) all fail closed. pf-bitstream API grew what the review proved necessary: RefPic carries the true top/bottom field order counts (a single poc fabricated BottomFieldOrderCnt whenever the PPS signals pic-order deltas), the >16-frame DPB envelope gate, and an MMCO5 rebase warning. Adversarial review round two: 8 findings fixed pre-commit, including transactional slot mutation (an error path could permanently desync the map) and count/pointer coherence on type-1 POC offsets. Gates: fmt clean, clippy -D warnings zero, 45+26+21 tests green on macOS and the linux/amd64 container.	2026-08-05 15:03:39 +02:00
enricobuehler	0a359525a7	feat(pf-bitstream): H.264 DecodePlan layer — the AU-to-hardware contract ... Adapted from cros-codecs decoder/stateless/h264.rs (POC 8.2.1, ref lists 8.2.4 incl. modification, sliding-window + MMCO/LTR marking 8.2.5, frame_num-gap handling 8.2.5.2), minus the fd-coupled backend trait. H264Planner::plan_au maps one wire AU to picture params, per-slice byte ranges + ref lists keyed by stable PicIds, and a DPB update; recovery- point SEI parsing is new code (upstream reads no SEI payloads). Concealment posture, deliberately different from upstream's aborts: frame_num gaps, failed RPLM/MMCO and mis-split AUs degrade to warnings the session turns into recovery asks, gap placeholders substitute in-place so ref_idx mapping never shifts, and DPB outputs queued during a failed AU survive to the next plan. An adversarial review round fixed 11 findings before this commit; one was an upstream cros-codecs bug our conformance-window test exposed (display_resolution double-subtracts the crop offset and underflow- panics — PROVENANCE deviation #6, worth reporting upstream). Gates: fmt clean, clippy -D warnings zero, 45+24 tests green on macOS and the linux/amd64 container.	2026-08-05 13:13:00 +02:00
enricobuehler	896bb47235	refactor(pf-bitstream): the parser layer is now compiler-enforced unsafe-free ... #![forbid(unsafe_code)] on both crates. Upstream's codec module was one production unsafe away: build_ref_pic_lists turned DPB borrows into indices via pointer offset_from — same pointer-identity mapping now expressed as position(ptr::eq) over the <=16-entry DPB (PROVENANCE #5). Three test-only mem::zeroed() asserts became Default::default(), an identical value for the all-integer PredWeightTable. Honest coverage note: build_ref_pic_lists has no callers inside the vendored subset (its consumer was the non-vendored stateless layer), so the rewrite is equivalence-by-construction until the DecodePlan layer exercises it against goldens.	2026-08-05 11:25:41 +02:00
enricobuehler	b5e54aea6e	feat(client): vendor the cros-codecs parser layer + pf-bitstream skeleton ... M1 of design/client-native-decode.md. The vendored snapshot (AOSP mirror main @ 5ff6d693ffae, BSD-3, PROVENANCE.md) is the codec module only — H.264/H.265/AV1/VP9 parsers, DPBs and their test vectors, which now run as 45 conformance tests in our CI. pf-bitstream sits where upstream's Linux-only decoder::stateless half would and starts with vendor-pinning smoke tests: a re-sync that shifts parser behavior trips in-tree, not in a decode session.	2026-08-05 11:19:51 +02:00
enricobuehler	119ec0dd83	feat(client): PUNKTFUNK_DUMP_VIDEO captures the exact decoder input ... Fixture-corpus enabler for the native-decode program (M0, design/client-native-decode.md): every AU exactly as the pump hands it to decode_frame — the raw concatenation plus a sidecar .idx carrying the AU boundaries and wire flags a byte stream cannot. Best-effort by design: any I/O error disables the capture, never the stream.	2026-08-05 11:02:37 +02:00
enricobuehler	110ac9b663	Merge pull request 'fix(stall): T2 amplification kill — resume-edge pacing + ABR starved-window guard' (#53) from worktree-stall-ride-through into main	2026-08-05 06:35:30 +00:00
enricobuehler	1d6f4760f3	Merge branch 'main' into worktree-stall-ride-through	2026-08-05 06:22:41 +00:00
enricobuehler	9dfbc2f895	Merge pull request 'fix(client-core): pad-audio references the WASAPI module by its mounted name' (#57) from fix/pad-audio-wasapi-module-path into main	2026-08-05 06:22:31 +00:00
enricobuehler	56adb47026	fix(client-core): pad-audio references the WASAPI module by its mounted name ... The Windows build of pf-client-core has been red on main since the pad-audio merge (#23): pad_audio.rs calls `crate::audio_wasapi::device_by_id`, but lib.rs mounts audio_wasapi.rs AS `crate::audio` via the #[path] per-OS swap — the `audio_wasapi` module name never exists. Windows-gated call site, so every Linux leg stayed green while both `windows / build` targets failed E0433. One-line rename to the mounted path (+ the comment that pointed readers at the phantom name). Verification is the PR's own windows leg — the crate builds on no other platform this path compiles on.	2026-08-05 08:15:02 +02:00
enricobuehler	52a9d02355	Merge pull request 'fix(deps): close the undici, fast-uri, postcss and brace-expansion advisories' (#55) from worktree-audit-undici into main ... Reviewed-on: #55	2026-08-05 05:51:06 +00:00
enricobuehler	e5ca213339	fix(core/abr): a starved window is never a decode-knee sample ... Stall program T2 (amplification kill), the phantom-latch half. A deciding window that delivered under a quarter of the target rate (a host-side capture stall, an outage, a mid-window pause) carries starvation-shaped distress — a jump-to-live flush, a keyframe-ask burst — that the decode-cap latch read as decoder evidence: under a periodic capture stall (the RDNA4 standby-sink field cases, one stall every ~5 s) every edge offers another 'backoff' at the SAME rate, and one pair latches a phantom decoder knee at whatever rate the display driver happened to interrupt. The session then fights the cap's re-probe ladder (+12.5% per 16-128 clean windows) for minutes on a decoder that was never the problem. Starved windows still back off (real damage deserves the safe response) but take the same 'not a knee sample either way' arm as a draining backoff: they neither latch a decode cap nor erase the reference a genuine choke set, so a real knee's pair still finds itself around the interruption. The ¼ bar sits deliberately far under the ×¾ utilization bar climbs require. Gates: 44 abr tests green (2 new: the stall-cycle no-latch scenario and the reference-preservation scenario), full core lib suite 346 green (--features quic), fmt + clippy clean.	2026-08-05 00:28:25 +02:00
enricobuehler	e5416646f9	fix(host/send): a stall-resume frame paces at the proven rate instead of blasting ... Stall program T2 (amplification kill), the resume-burst half. The native pace budget was min(0.9 × time-to-deadline, overflow at ~3× stream rate) — for steady-state frames the rate term is smaller and decides, but for an OVERSIZED frame (a capture-stall resume carrying seconds of scene delta, a cold IDR) the deadline term clamped a multi-interval overflow into the remainder of ONE: an instantaneous many-×-stream-rate blast that overruns the socket tx-buffer and loses the very frame that would have ended the freeze. Field fingerprint across three RDNA4 standby-sink cases: WSAENOBUFS(10055) + loss_ppm spikes at stall edges, then a recovery-IDR round trip per retry while the client shows 'current bitrate 0.1'. The budget is now the overflow's wire time at the pace rate itself (send_pacing::native_budget, pure + unit-tested), bounded by an absolute 100 ms ceiling so a pathological frame can't park the send thread; the deadline stays a target, never a license to blast. Steady-state frames produce byte-identical schedules (the rate term already decided); PUNKTFUNK_PACE_FACTOR=0 keeps the legacy deadline-only spread; the GameStream plane's Moonlight-pinned schedule is untouched. Gates: host clippy --all-targets -D warnings + 9 send_pacing tests green (linux/amd64 container), fmt clean.	2026-08-05 00:28:13 +02:00
enricobuehler	b79d90b463	fix(deps): close the undici, fast-uri, postcss and brace-expansion advisories ... audit.yml's three blocking bun-audit legs (web, sdk, plugin-kit) were all red on main. Ten findings in sdk and plugin-kit, eight in web; every one of them a transitive dependency, none reachable by bumping a direct dep. web already carried the right mechanism — an `overrides` block whose `undici` and `fast-uri` pins had simply gone stale — so it needed four bumps, not a new idea: undici 7.28.0 -> ^7.29.0 and fast-uri 3.1.4 -> ^3.1.5 for the reported advisories, plus postcss ^8.5.10 -> ^8.5.25 and brace-expansion ^5.0.8 -> ^5.0.9 for two more that were published after the failing run and would have gone red on the next audit anyway. All four stay inside their current major. sdk and plugin-kit were harder and the fix deserves an explanation. Their single finding is undici 8.7.0/8.8.0 pulled in by @effect/platform-node, a devDependency pinned at 4.0.0-beta.98. That dependency already declares `undici: ^8.7.0`, which permits the fixed 8.10.0 — the vulnerable version survives purely as a stale lockfile resolution. Nothing bumps it in place: `bun update` only walks direct dependencies, `bun install --force` preserves a resolution that still satisfies its range, and every platform-node release through beta.103 declares the same `^8.7.0`, so moving the dep changes nothing. Bun rejects the scoped form outright ("Bun currently does not support nested resolutions"), so a flat `overrides` entry is the only mechanism available, and it necessarily also moves sdk's top-level undici from 7.x to 8.x. That is safe here, and was verified rather than assumed. The only source use is sdk/src/config.ts, which does `new Agent({ connect: { ca } })` behind a dynamic import and a try/catch with a documented plain-fetch fallback; `Agent` and its `connect` option are unchanged between undici 7 and 8. sdk typechecks and its 72 tests pass against 8.10.0; plugin-kit typechecks and its 20 tests pass. Both trees now dedupe to a single undici 8.10.0. Consumers are deliberately untouched: `overrides` apply only at the root of the tree that declares them and are not honored when the package is installed as a dependency, so sdk's published `optionalDependencies: { undici: "^7.0.0" }` is left alone — a consumer resolves the latest 7.x, which is the fixed 7.29.0. The override governs this repo's own tree, which is exactly what audit.yml checks. Worth knowing: sdk's dev tree therefore exercises undici 8 while consumers get 7. One trap found on the way. Running `bun install` over plugin-kit's existing lockfile emitted a lockfile with two byte-identical `@punktfunk/host` entries — its `file:../sdk` dependency crossed with the new override — and bun then refuses its own output with "Error loading lockfile: InvalidPackageKey". That reads as a tooling error rather than a finding, so it would have taken the audit gate down while looking like something else entirely. Regenerating the lockfile from scratch produces a valid single entry; all three lockfiles are checked for duplicate keys. Also worth recording, because it nearly shipped: deleting the pinned nested entry from a lockfile makes `bun audit` report "No vulnerabilities found" while the vulnerable copy is still installed on disk. bun audit reads the lockfile, not node_modules. That is a vacuous green, not a fix, and was rejected. Verified: `bun audit` clean in all three trees; web builds and typechecks (its typecheck needs the build first, which generates routeTree.gen); sdk 72/72 and plugin-kit 20/20 tests pass.	2026-08-05 00:22:25 +02:00
enricobuehler	8983ec04b9	Merge pull request 'feat(pad-audio): DualSense voice-coil haptics + speaker, host to client' (#23) from feat/android-pad-audio into main	2026-08-04 21:56:37 +00:00
enricobuehler	d27e62f7c9	fix(pad-audio): close the twelve findings the sweep left open on this branch ... Everything the 2026-08-03 haptics sweep filed against the pad-audio branch (P2 + P3). Four of them are the difference between a feature that works and one that fails silently. **B6 — nothing ever un-muted the coils.** Every rumble report asserts `HAPTICS_SELECT`, which is SDL's "disable audio haptics" bit: the firmware mutes the very voice coils the 0xD1 stream drives. No code anywhere cleared it again, so ONE rumble left tier-A haptics silent for the rest of that pad's life — no error, nothing in a log, and the host happily streaming into a muted actuator. `DsDevice.ds5AudioHapticsReport` is the documented undo (flag0 with both bits clear); written EP0-direct when the stream starts and again after a rumble stop while a stream is live, because the stop report re-mutes on its way past. **B10 — the desktop mix could reach a controller's coils.** Pad endpoints were filtered out inside `plan()` only. The watchdog, Follow mode and the parked default all go through `judge_default`, which classifies by NAME — and a pad endpoint is deliberately stamped "DualSense Wireless Controller" so games treat it as the pad's speaker. No name rule could ever catch one. It now refuses them by identity. **B27 — an out-of-range pad aliased onto a real slot.** The 0xCD plane's pad is the only u16 index and every consumer narrowed it with `as u8` on an assumption nothing enforced, so wire pad 256 steered pad 0's speaker volumes. Rejected at the decoder, which makes the narrowings lossless by construction. An existing test had pinned the bug in place, asserting that wire pad 513 round-trips; corrected, plus a test for the 256→0 alias specifically. **B7 — caps that arrived late were never announced.** The renderer commits the tier-A trade only once its sink opens, which is well past the arrival burst's two 100 ms ticks, and `set_pad_audio_caps` only stored an atomic. The client believed it had pad audio while the host emitted nothing. The input task now compares the live registry against what the last arrival actually carried and re-arms the burst itself — no new plumbing, and no extra traffic when nothing changed. The rest: `needs_aeb_kick` is finally ACTED on (R4) — a stored-but-not-served endpoint is declined rather than opened, because `AUTOCONVERTPCM` makes it succeed and mis-route; a failed provisioning no longer latches `PROVISIONED` for the process lifetime (R5), and `host_cap` retries, so a host that started while the audio stack was busy recovers at the next connect instead of the next reboot; the loopback init timeout reaps its thread instead of detaching one per ~2 s reopen (R6); kind-change restarts are bounded (R3) since the trigger is a client-sent arrival; the devtest uses the endpoint's real channel mask (B11) instead of letting wasapi derive 0x0F against the endpoint's 0x33; the render loop asks `is_session_ended()` rather than spinning at nice -16 (R12); short writes are counted and reported instead of dropping the tail in silence (R13); and a frame addressed to another pad is dropped before it can seed the gap tracker from a foreign sequence space (R14). Verified: punktfunk-host clippy -D warnings **0 on a real Windows box**; Linux/amd64 clippy 0 with **589 tests** (pf-client-core 114, pf-inject 101, punktfunk-client-android 20, punktfunk-core 345+1+8); Android :kit: tests + :app: compile green; fmt clean. Six punktfunk-host tests fail on that Windows box. FIVE fail identically on a tree with no pad-audio code at all (QUIC `Rejected(SetupFailed)` — the box's network environment); the sixth passes 3/3 in isolation and only failed under the parallel run, on a locally-bound ephemeral port. Neither is this change. Still owed: on-glass. This is a hardware feature and none of it has been on a real DualSense since the merge.	2026-08-04 23:55:47 +02:00
enricobuehler	0a72959ef7	Merge main into feat/android-pad-audio ... 86 commits of main, including the whole M1-M12 haptics sweep. Twelve conflicting files; three of them were more than textual. **The capability bits collided.** Both branches allocated the SAME wire bits for DIFFERENT features: `client_caps 0x04` and `host_caps 0x20` are redundant desktop audio on main and pad audio here. Merged naively, a peer would negotiate one and get the other. Pad audio moves to the next free bits — `CLIENT_CAP_PAD_AUDIO = 0x08`, `HOST_CAP_PAD_AUDIO = 0x40` — and the `abi.rs` mirrors move with them (their compile-time equality assertions caught the mismatch, which is exactly what they are for). **Both branches also claimed ABI v15.** Main's shipped (the rumble-policy floor), so the pad-audio surface becomes **v16**. **`native/input.rs` would have reintroduced a fixed bug.** This branch resets `rumble_seq[idx]` on pad removal; M1 established that the client's reorder gate is per-connection with no reset path, so restarting the host counter strands every later envelope until it climbs back. Took main's seq-preserving `clear_pad_feedback` and kept only the branch's `pad_streams.stop(idx)`. The rest: `wiring_plan::plan` now delegates to main's `plan_with_formats`, so the pad-endpoint filter moved into that body and the predicate behind it is factored out as `is_pad_render` (also what B10 needs); `Ds5Feedback::AUDIO` derives from main's `REPORT_ID_LEN` like its siblings; `AudioCtl` joins the explicitly-listed unhandled variants so the guard-false case is covered rather than swept up by a `_`; `include/punktfunk_core.h` regenerated rather than hand-merged.	2026-08-04 23:27:06 +02:00
enricobuehler	2d223274fc	Merge pull request 'refactor(haptics): one copy of each thing every rumble path was transcribing' (#51) from worktree-haptics-m12-dry into main	2026-08-04 21:11:49 +00:00
enricobuehler	92f617a989	Merge remote-tracking branch 'origin/main' into worktree-haptics-m12-dry ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/GamepadFeedback.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:11:22 +02:00
enricobuehler	2f071a9a93	Merge pull request 'fix(clients/settings): controller settings that can't do anything no longer look live' (#50) from worktree-haptics-m11-settings into main	2026-08-04 21:08:15 +00:00
enricobuehler	62d35bc4b6	Merge pull request 'fix(core/wire): a truncated trigger datagram stops cancelling the effect it should carry' (#45) from worktree-haptics-m10-wire into main	2026-08-04 21:07:54 +00:00
enricobuehler	5d06ef26ac	Merge pull request 'fix(feedback): the pad stops keeping a game's trigger effect after the stream ends' (#44) from worktree-haptics-m9-richfb into main	2026-08-04 21:07:35 +00:00
enricobuehler	fcf4076eb7	Merge remote-tracking branch 'origin/main' into worktree-haptics-m9-richfb ... # Conflicts: # clients/android/kit/src/main/kotlin/io/unom/punktfunk/kit/DsCapture.kt # crates/pf-client-core/src/gamepad.rs	2026-08-04 23:07:18 +02:00
enricobuehler	53eb592c43	Merge pull request 'fix(host/pads): a centred stick reads centred, and a delayed effect waits its turn' (#43) from worktree-haptics-m8-proto into main	2026-08-04 21:03:33 +00:00
enricobuehler	956d8dd8ef	Merge pull request 'fix(host/windows): two virtual pads stop tearing each other's reports' (#39) from worktree-haptics-m7-windows into main	2026-08-04 21:03:13 +00:00
enricobuehler	b2e716ad5f	Merge pull request 'fix(client/desktop): the Deck keeps its trackpad, and a pad stops buzzing at exit' (#38) from worktree-haptics-m6-presenter into main	2026-08-04 21:02:36 +00:00
enricobuehler	ec288d64d3	Merge pull request 'fix(client/android): rumble survives a vibrator fault, and an unplug stops leaking' (#35) from worktree-haptics-m5-android into main	2026-08-04 21:02:15 +00:00
enricobuehler	68353a5d57	Merge pull request 'fix(client/apple): two DualSenses stop fighting over one device, and a failed stop stops lying' (#32) from worktree-haptics-m4-apple into main	2026-08-04 21:01:51 +00:00
enricobuehler	ffd5a33598	Merge pull request 'fix(core/rumble): the Deck's keepalive stops being swallowed by its own renewals' (#30) from worktree-haptics-m3-rumble-engine into main	2026-08-04 21:01:32 +00:00
enricobuehler	4af8b02be1	Merge pull request 'fix(host): a leftover Sunshine folder is not a conflict, and a crashed host gives the screen back' (#52) from worktree-conflict-detect-and-isolate-recovery into main ... Reviewed-on: #52	2026-08-04 21:00:56 +00:00
enricobuehler	42a0dd52be	refactor(haptics): one copy of each thing every rumble path was transcribing ... Twelve findings from the sweep's DRY/docs/dead-code tail. Most are small; three found real defects hiding behind the duplication. **The UHID event ABI existed five times.** Every UHID gamepad backend — DualSense, DualShock 4, Switch Pro, Steam Controller, Steam Controller 2 — carried its own verbatim copy of the kernel's constants plus its own `put_cstr`, and they had already drifted: `switch_pro` was missing the SET_REPORT pair entirely, and `steam_controller` read a FIXED 16-byte SET_REPORT window instead of the event's own `size`. That last one is a bug in both directions — a longer report was truncated, and a shorter one had the parser reading whatever the reused event buffer still held past the payload, i.e. acting on rumble values the game never wrote. Now one `uhid_abi` module owns the numbers plus the two accessors that are easy to get subtly wrong, with tests on exactly that. **A dead force-feedback id fallback.** ff-core's `input_ff_upload` picks a free effect slot and writes it into the effect BEFORE uinput forwards the request, so the `id == -1` branch could never run — and allocating from a local counter would have been the wrong answer anyway, since the kernel owns that id space. Removed, with a `debug_assert` where it stood. **Apple's HID path silently dropped weak rumble.** `hidByte` took the top byte with no non-zero floor, so every amplitude below 0x0100 rendered as exactly nothing. Android has always floored it at 1; this was the odd one out. That converter also existed twice byte-identically inside one Gradle module — now one `wireAmplitudeToByte`. Also: the DS5 output-report layout gets named offsets (`dualsense_proto::out_report`) documenting all three transport bases — USB 0, SDL payload −1, Bluetooth +2 — since the differing bases are transport-forced, not drift. `pf-client-core` cannot import them (it and `pf-inject` do not depend on each other, and a DualSense layout has no business in `punktfunk-core`, their only shared crate), so its copy now DERIVES its offsets by explicit subtraction and a test pins the relationship. `PUNKTFUNK_HID_EFFECT_MAX` sizes the struct it describes instead of a second literal 11 — the header now emits `uint8_t effect[PUNKTFUNK_HID_EFFECT_MAX]`. The rumble policy engine's `min_pulse_ms` and `keepalive_ms` docs stop naming cases nothing implements: no in-tree caller sets `min_pulse_ms`, and the macOS DualSense-over-BT keepalive the doc cited CANNOT be served by the quirk, because that renderer skips writes whose levels are unchanged and would swallow the engine's re-emit — it keeps its own keepalive instead. `TrackpadHaptic` is marked as staged scaffolding (the tag is on a shipped wire; removing the variant would not reclaim it). Three ×257-vs-`<<8` doc comments corrected — the scaling itself is fine, both round-trip to 255. `backstop_ms.max(160)` deleted as unreachable (the engine floors at 500). New tests for `Ds5Feedback` and for the Android rumble JNI packing on BOTH sides, with `MAX_PADS <= 16` now a compile-time assertion rather than a comment. Closes S1-S9, S11, T2, T3 (design/haptics-sweep-2026-08-03.md M12). S11's second half is NOT a defect and was left alone: `clients/session/src/main.rs` calls `set_forwarding` unconditionally on every params-build (its own comment explains why — browse mode reuses one service across launches), so `Ctl::Forwarding` routinely arrives unchanged and that early-out is what stops a redundant `sync_open` + Valve-HIDAPI cycle each launch. Verified: pf-inject clippy -D warnings 0 / 91 tests; pf-client-core + punktfunk-core clippy 0 / 437 tests (amd64 container); punktfunk-client-android 7 tests; Android :kit: 6 tests; Apple swift build + 189 tests / 0 failures; cargo fmt --all --check clean. Each new test probed by reverting its fix — the fixed SET_REPORT window fails 3, a broken pack shift fails 3, dropping the amplitude floor fails 1, and a wrong DS5 offset either fails the pin or refuses to compile.	2026-08-04 22:52:38 +02:00
enricobuehler	b31495bea5	fix(host): a leftover Sunshine folder is not a conflict, and a crashed host gives the screen back ... Three things a field report (Discord, upgrade from 0.1x) turned up, all on the Windows host. 1. "It thinks I have Sunshine/Apollo running." It didn't — they were uninstalled. Both uninstallers leave their config/log directory in Program Files behind, and `detect.rs` counted a bare directory, or a service registered at ANY start type (including `disabled`), as a live conflict. The installer's own probe was narrowed to "service start type <= 2" after exactly this cried wolf on a `winget install`, and the tray dropped its always-on warning for the same reason in 3e782852 — the runtime probe never got the same treatment, so the one surface the user actually looks at kept shouting. `Evidence::is_active` now draws the line (running, or set to start on its own) and only active detections reach the startup warning, the `detect-conflicts` exit code, and `/local/summary`. Dormant findings still print in the full report, under a heading that says they need no action — that report is where "why does it think I have Apollo?" gets answered. 2. The console's conflicts card hardcoded "Another game-streaming server is **running** on this machine" regardless of what was found, so a dormant leftover was announced as a running server. It now says "active", and each entry names the observation — `Sunshine (running)`, `Apollo (starts automatically)`. 3. "The exclusive screen never times out going back to re-enabling the display." `isolate_displays_ccd` deactivates the operator's panels and hands the pre-isolate topology to the caller, which restores it at teardown — but that snapshot is PROCESS MEMORY, and Windows deliberately never saves the isolated topology to the CCD database. So a host that crashed, was killed, or was stopped mid-session left the desk dark with nothing in the product to undo it. There was one startup recovery leg already, but only for the EXPERIMENTAL `pnp_disable_monitors` axis, which is off by default — the default Exclusive path had none. `isolate_journal` now marks what an isolate is about to switch off (before the apply, so dying mid-apply is covered), clears the mark on restore, and force-EXTENDs at host startup if a mark survived. EXTEND rather than replaying the saved blob: the blob pins the virtual display's target id, which dies with the crashed host, so a replay would mostly fail BAD_CONFIGURATION into the very same backstop `restore_displays_ccd` already keeps — and EXTEND stays correct across a reboot, where saved ids would be stale.	2026-08-04 22:34:33 +02:00
enricobuehler	9fb41affba	fix(clients/settings): a controller setting you can't use no longer looks like one you can ... Turn "Forward controllers" off and four rows below it stop meaning anything — nothing is forwarded, so there is no pad type to pick and no guide button to route. GTK desensitised them, the touch settings on both mobile clients dimmed them and the console UI refused the step; the Windows client and BOTH controller-navigable screens left them fully live, so you could sit there changing settings that did nothing. Windows: `.enabled(s.gamepad_forwarding)` on the forwarded-controller picker, pad type, guide button and hold-Select rows — the same builder the echo-cancellation row already used to follow the mic switch. Apple's gamepad settings had no way to say it: `Row` carried `adjustable` (which only hides the chevrons) and nothing else. Added `Row.enabled`, dimmed the row CONTENTS only so the glass still reads as a focusable row, and enforced the inertness centrally in `adjust(id:)` / `activate(id:)` rather than in each builder's closure. The hint bar drops "Adjust"/"Change" on a dimmed row, because advertising them was the same lie the live row told. Android's gamepad settings already had `GpRow.enabled` — documented as "dimmed + inert" — but it only faded the label: every dimmed row still stepped and still wrote its setting. The "No profiles yet" placeholder looked inert only because its own closures were empty. Made it real in one named place (`liveRow`), covering all three input paths (left/right, A, and a tap on the already-focused row), then gated the pad rows on it. Also on that screen: the DualSense / DualShock passthrough toggle, which the touch settings have carried beside its SC2 twin all along. It was missing exactly where it matters most — a TV box has no touch interface to fall back to, so there was no way to reach it at all. Apple capture, separately: with forwarding off, opening a slot still claimed EVERY element's system gesture and powered the controller's IMU. Neither reaches the host, so the first only took the user's screenshot/Home gestures away for nothing and the second drained the pad's battery streaming gyro over Bluetooth. Narrowed rather than skipped — the escape chord is read off the same slot and on tvOS is the ONLY controller way out of a stream, so the chord's own four buttons keep their claim. A test pins the alias list against the chord mask; if they drift the symptom is a session nobody can leave, with nothing logged. Closes R17, R18, R19 (design/haptics-sweep-2026-08-03.md M11). R17 as filed named Windows and "Apple"; Apple's TOUCH settings were already correct and Android's controller-navigable screen was not — both corrected here. Verified: Windows clippy -D warnings exit 0 on a real Windows box; Apple swift build clean + full suite 192 tests / 0 failures (3 new); Android :app: + :kit: green (5 new); cargo fmt --all --check clean. Each fix probed by reverting it — every probe failed the tests it should.	2026-08-04 22:25:51 +02:00
enricobuehler	ee0b179618	Merge pull request 'docs(apple/store): App Store copy for iOS, macOS and tvOS, counted against Apple's limits' (#49) from worktree-appstore-copy into main ... Reviewed-on: #49	2026-08-04 20:03:34 +00:00
enricobuehler	d7e22c3db2	Merge pull request 'fix(apple/shots): the store screenshots show the app as it actually is' (#48) from worktree-apple-store-screenshots into main ... Reviewed-on: #48	2026-08-04 20:02:37 +00:00
enricobuehler	c1231fa2e6	Merge pull request 'feat(clients/input): system buttons route around local overlays' (#47) from worktree-system-buttons-routing into main ... Reviewed-on: #47	2026-08-04 20:02:22 +00:00
enricobuehler	1db7058a5d	feat(clients/input): system buttons route around local overlays ... Pressing guide/Steam/QAM collided with the client device's own shell: iOS 26 opens its Game Overlay for the Home press (no app opt-out until iOS 27 makes it a user setting), and a Gaming-Mode client opened BOTH Steam overlays for one press — the local one covering the stream. Two cross-client tier-P settings, zero wire changes: - system_buttons (auto|forward|local): raw guide+misc1 passthrough. Auto forwards everywhere EXCEPT under gamescope, where SteamOS reacts to the same physical press no matter what. - guide_gesture (auto|on|off): hold Select ALONE ~350ms sends the HOST's guide, down until release — held on, that's the host's long-press, which opens a Gaming-Mode host's QAM for regular pads. A Select tap is delivered on release with its up TAP_PRESS (50ms) behind, because per-transition sends fold into seq'd GamepadState snapshots and a back-to-back pair can coalesce into no press at all. A Select inside a combo (the escape chord) passes through untouched. Auto arms it only where the raw press can't reach the host cleanly: gamescope, iOS/iPadOS, tvOS. The same SelectGesture rules live in pf-client-core (pure state machine + unit tests), the Apple client (mask-diff adaptation in GamepadCapture), and Android's GamepadRouter. Settings rows on every surface (GTK, WinUI, console UI, Decky, Apple x2, Android x2) with profile plumbing throughout. punktfunk-session grows a control socket ($XDG_RUNTIME_DIR[/app/$FLATPAK_ID]/punktfunk-session-ctl.sock — the one runtime path a flatpak and the host see identically): 'guide'/'qam' verbs inject synthetic taps. The Decky panel gains a Host menus section (visible while the client runs) whose buttons press the host's Steam/QAM and close the local menu so the host's shows through. iOS 27's GCControllerHomeButtonSettingsManager deep-link is a TODO (the class needs the Xcode 27 SDK to compile). Docs: input, client-settings, steam-deck. Design: punktfunk-planning design/system-buttons-routing.md. Gates: docker clippy --all-targets --locked -D warnings + tests (pf-client-core 88 incl. 6 new gesture tests, pf-console-ui 47), cargo fmt --all --check, swift build (macOS), gradle kit+app compile, decky tsc --noEmit + py_compile. clients/windows not compiled (no box).	2026-08-04 21:46:27 +02:00
enricobuehler	83a12c7413	Merge pull request 'Decky, slimmed: a thin Gaming-Mode wrapper around the client' (#46) from worktree-decky-slim-rework into main ... Reviewed-on: #46	2026-08-04 19:41:32 +00:00
enricobuehler	7b1554af4b	fix(apple/shots): fill the grid, open Settings on Display, note the iPad orientation limit ... - Six mock hosts rather than three. An iPad-13 portrait grid is three columns wide and 2752 px tall; three cards left ~60% of the capture as black. - Settings opens on Display, not General. Resolution, frame rate, bitrate, HDR and codec are what someone reads a streaming app's settings shot for. - The wake scene is the modal-over-grid variant. The gamepad-UI one is a full-screen takeover over a bare gradient — correct, but four lines of text on an empty aurora; the modal shows the same overlay over the host grid. - `requestGeometryUpdate` now reports a refusal instead of failing silently. It does not help on the simulator (an app's stdout doesn't reach the driver through `simctl launch`) but it will on macOS and on a device. - Documented that `.landscape` does not rotate on iPad: a multitasking-capable iPad app is resizable, so iPadOS ignores the request and simctl cannot rotate a simulated device. The iPad set is portrait throughout.	2026-08-04 21:34:18 +02:00
enricobuehler	8f35155c14	fix(apple/shots): the store screenshots show the app as it actually is ... Uploading the 0.24.0 set surfaced a pair screen that reads as broken, and a hero that was never the orientation it claimed. The capture harness: - Landscape scenes were captured in PORTRAIT. `IOSOrientationConfigurator` asked for the geometry update from `updateUIViewController`, where `view.window` is still nil — SwiftUI makes one update pass for a `.background` representable, before the hierarchy is in a window, so the guard fell through and nothing ever asked again. Both `.landscape` scenes (the stream hero, the trust card) shipped as portrait. Now a real UIViewController asks from `viewDidAppear` and pins `supportedInterfaceOrientations`. - The shot host applied `.ignoresSafeArea()` to the whole scene, so the hero's HUD — resolution, bitrate, the latency breakdown, the entire point of that screenshot — sat under the Dynamic Island. Only the black backing ignores it now; scenes that want full bleed already ignore it themselves. - `03-pair` was hand-composed into a ZStack rather than presented. PairSheet is a bottom sheet on iOS: its detents and the system's Liquid Glass only exist inside a real `.sheet`. Composed, the grouped Form stretched to full screen height and the capture was a strip of content over a black void, with a DISABLED "Pair & Connect" (empty PIN) and the capture simulator's own name — `pf-shot-iphone-6.9` — rendered in as the device name. - Sheets do not inherit `.environment(\.colorScheme, .dark)` across the presentation boundary; they follow the DEVICE. The pairing sheet came out light grey over the dark app. The simulator is now set to dark appearance. - Discovery browsed the live LAN mid-capture, so a bystanding machine's hostname went out on the listing and no two runs matched. `HostDiscovery` gains a `debugSet` seam (the counterpart to `HostWaker.debugSet`); the mock hosts advertise, so cards read ONLINE through the real `advertises` path and the reachability probe never touches the network. - Created simulators were named `pf-shot-<prefix>`, which the reuse regex never matches: every run created another simulator and none was reused. They are named after the device now — reusable, and not user-visible junk. Two bugs found on the way, neither screenshot-only: - HostStore/ProfileStore PERSISTED the harness's mock data. On a dev Mac that is the same App-Group suite the real app reads, so running the script could replace the tester's saved hosts with "Battlestation" & co. - GamepadHomeView drew the controller chip as a trailing `.overlay`, which reserves no width — on a portrait phone it sat on top of the centred "Select a Host". Laid out as a row with a hidden leading mirror. - The pairing sheet's field prompt said "How the host lists this Mac" on iPhone and iPad. Coverage: the listing set is six scenes in listing order, and is now the stream, the machines it found, the couch/controller mode, waking a sleeping host, the quality controls and pairing — the console and wake screens already existed in `ShotScenes.all` and were simply never captured. Mock hosts carry OS marks, Wake-on-LAN MACs and profile chips so the grid is full rather than three offline rows over an empty half-screen. `SCENES=` overrides the set for the dev scenes.	2026-08-04 21:30:18 +02:00
enricobuehler	0d407a866d	fix: a host that changed DHCP lease could no longer be streamed from the panel ... An adversarial review of this branch found a regression I introduced, plus three smaller defects. All four are fixed here, each verified on .21. **The regression.** `mergeHosts` names a host by its record's stable id, and `hosts list --json` always emits one (`KnownHosts::load` mints ids for every record). So a launch always went out as `punktfunk launch <uuid>` → `ConnectPlan::for_host` → `HostTarget::from(&KnownHost)`, which copies the address stored ON THE RECORD. Meanwhile the panel deliberately renders the LIVE advert's address. Nothing on a Deck ever writes a moved address back — `discover` and `hosts list` are both reads, and only the desktop shells' hosts pages update one. So after any DHCP move the row read "online" at the new address and every press dialled the old one: a 15 s dead connect, or — if a MAC had ever been learned — a black Steam "game" for the full 90 s wake budget. Proven with a stub session binary: `launch abc-123` emitted `--connect 10.0.0.5:9777` for a host answering at `10.0.0.99`. This worked on origin/main, which dialled `toHost(v).host` — the advert's address. The fix restores that without giving up stable ids: `hosts add <new-addr> --fp <known-fp>` now MOVES the matching record instead of filing a second one (the fingerprint is the identity — this is the same rule that makes the verb idempotent), and the panel re-points a host it can see has moved before launching it. Verified: `moved 10.0.0.5:9777 to 10.0.0.99:9777`, one record still, and `launch abc-123` then emits `--connect 10.0.0.99:9777`. **"No hosts yet" was also how a missing client looked.** `_cli_argv()` returning None becomes `client-unavailable`, which the panel dropped on the floor — so a Deck with no client installed was told its network was empty, under a button that launches the client that isn't there. It now says which of the two it is. **The browse worker never exited on a quiet LAN.** `discover_for` drops the receiver and the doc claimed that stops the thread. It does not: the worker parks in `recv()`, and the arms that ignore an event (`SearchStarted`, `ServiceFound`, `SearchStopped`, a v6-only advert) never touch the sender, so on a LAN with no Punktfunk host nothing ever wakes it. Harmless today because the only caller is a short-lived CLI process, but the function invites in-process use, where it would leak a thread and an mDNS daemon per call. Now polled with a 250 ms tick and a check at the top of the loop. Verified: ten back-to-back browses settle back to the baseline thread count. **A `pair=optional` host was recorded as paired.** Every unsaved host now goes through the trust sheet (it has no pin, so it cannot stream without one), but the sheet's only non-PIN action ran `--request-access`, which persists `paired: true` on Ready. An optional host admits anyone who pins its identity — there is no operator decision, so nothing was approved and the same box read "paired" here and "trusted" in the desktop client. Such a host now gets **Connect** instead, which pins and streams without claiming an approval, and the "approve this Deck" toast is no longer shown to someone who has nobody to ask. Also: `PF_CLIENT_BIN` was the one launch-option value never validated — a client installed under a path with a space would split Steam's tokenizer.	2026-08-04 21:26:09 +02:00