1312 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	a12f1f092c	feat(clients/audio): one de-jitter policy for all four rings, and lossless single-packet recovery ... Phase 4 + WP3.2 of design/audio-quality-and-latency.md. **The defect.** Every client ring primed *up* to a target and clamped at a ceiling, and none walked the depth back *down*. Any transient — a Wi-Fi arrival burst, a host stall, or plain host-DAC-vs-client-DAC skew of a few dozen ppm — therefore added latency permanently, until an underrun happened to re-prime. Android, with no shed at all, converged on its 120 ms hard cap and stayed there for the rest of the session; that is the "audio latency is too high" report. Apple did shed, 40 ms in one go, which its own comment called "one audible blip". All four now share `punktfunk_core::audio::JitterPolicy`: depths in MILLISECONDS rather than device quanta (`3 x quantum` meant 15 ms at a 5 ms quantum and a silent 64 ms at a 20 ms one), a crossfaded 5 ms shed once the depth average has sat above target for 2 s of consumed audio, and de-prime hysteresis. Linux and Windows had never had that hysteresis — they still carried the `if ring.is_empty()` instant re-prime that Android identified as self-inflicted crackle, where one transient drain manufactured a whole target's worth of silence. Android's floor drops 40 -> 25 ms: the policy grows the target on the devices that actually underrun, instead of every device pre-paying for the worst one. The Windows ring moves from raw bytes to interleaved f32 so it can share the policy and the crossfade helper at all. Apple is the one client where the policy is hand-written in a second language, so it gets its own XCTest (`AudioRingDriftTests`). Verified here by compiling `AudioRing.swift` standalone against a simulation harness — +200 ppm for 5 minutes settles at 30 ms with zero silent callbacks, where the old ring would have ridden its 80 ms high-water mark. **WP3.2 — recovery lives in core, not in the clients.** The rebuilt frame is re-inserted into the demux queue in order, so every embedder (including any C-ABI consumer) gets a complete stream without knowing the `0xD2` plane exists, and their `AudioGapTracker` simply stops seeing the gap. `recovery_and_the_gap_tracker_agree` pins exactly that. For the same reason core advertises CLIENT_CAP_AUDIO_RED itself rather than making four embedders remember to. Verified: clippy --all-targets -D warnings and the full test suites for punktfunk-core, pf-client-core, punktfunk-host, pf-host-config under Linux/docker (163 + 61 tests); punktfunk-client-android `cargo ndk check` for aarch64 with the gate proven non-vacuous by a planted type error, and its 6 clippy findings confirmed IDENTICAL to the pristine file (all are the documented arm64-only artifacts); AudioRing.swift type-checked and simulated on macOS; fmt. The Windows client half (audio_wasapi.rs) is still not compile-verified anywhere. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 09:28:01 +02:00
enricobuehlerandClaude Opus 5	3055e29ebb	feat(host/audio): make audio observable, fix the endpoint choice, raise the encode quality ... Phases 0-3 of design/audio-quality-and-latency.md, host side. **WP2.1 — the 2026-08-03 root cause.** The client-only loopback preference took Steam's Streaming *Microphone* render endpoint over real hardware unconditionally, because it is silent on the host. But that endpoint exists to carry remote VOICE, and nothing checked whether it could carry music: on the reporter's box it won all 31 loopback opens across 25 sessions while a clean AMD HD Audio endpoint sat idle, and the whole desktop mix went through it before reaching Opus. A silent sink now has to EARN its preference — if its mix format narrows the mix it drops below real hardware. It is still taken when nothing better exists (narrow audio beats no audio), but flagged so the capture side says why. `plan_with_formats` takes a probe rather than reading WASAPI, so all 26 wiring-plan tests still run on every platform. An unknown format counts as fine, which is asserted: `unknown_formats_reproduce_the_formatless_plan` proves a probe failure can never make the plan worse than it was before formats existed. **WP0.1 — log the endpoint's ACTUAL mix format.** Everything the old log printed ("48 kHz f32 channels=2") was our REQUEST; with `autoconvert` WASAPI converts silently from whatever the endpoint really runs. That is why a 3,600-line log filed over an audio-quality complaint contained nothing that could diagnose it. **WP0.2 — count what we drop.** The capture->encode handoff was a silent lossy `try_send`: a stalled encode thread lost chunks, the encoder concatenated across the hole, and nothing recorded it — a click plus a permanent shift of everything after. Now counted and warned, alongside per-window peak/RMS/delivered% so a quiet host, a broken endpoint and a stream we are damaging ourselves stop looking identical. **WP2.4 — stop the default-device tug-of-war.** In Assert mode the capture is bound to the planned endpoint EXPLICITLY, so a hijacked default changes only where apps render — the old full reopen tore the capture down for nothing. The field log shows the cost: something re-set the default every ~4 s and each round was a teardown, a wiring pass with IPolicyConfig writes, and an audible dropout — seven in sixteen seconds, one ending in a 2 s error backoff. Now: put the default back, keep the stream, and after four rounds in twenty seconds concede for a minute and say so once. **WP1.1/1.2 — encode quality.** Constrained VBR (the hard-CBR comment justifies itself with GameStream's audio FEC, which this plane does not have) and `AudioTier::High` by default: stereo 128 -> 256 kbps, ~1 % of a 20 Mbps session. GameStream's encoder is deliberately untouched — its FEC really does need fixed-size packets. **WP3.1 — redundant `0xD2` plane**, sent when the client asked for it. **WP2.2 — `audio.output_mode`** as a first-class setting (`client_only` / `host_and_client` / `follow_default`), superseding the two undocumented env vars, which stay honoured. The enum lives in pf-host-config, which is deliberately dependency-free, so the tier table stays in core where the codec knowledge is. `capture_policy.rs` is split out for the same reason `wiring_plan.rs` is: both encode field behaviour, so their tests must run on Linux CI, not only on a Windows box. That split immediately earned itself — `capture_stats_separate_silence_from_signal` caught RMS being divided by the FRAME count while summed over interleaved SAMPLES, which inflated it by sqrt(channels) and made a sine report an RMS equal to its own peak. WP4.5 (open the loopback at the minimum device period) is deliberately NOT done: in shared mode `IAudioClient::Initialize` cannot change the engine period at all, so it would be a no-op at best and a new failure path at worst. Recorded in the code. WP2.3 (force the parked endpoint's volume) is deferred — `wasapi` keeps IMMDevice private, so it needs new raw COM on a path this tree cannot compile, let alone test; its diagnostic half ships as the RMS line above. Verified: punktfunk-host + pf-host-config clippy --all-targets -D warnings and the audio test suite under Linux/docker (gate proven non-vacuous with a planted type error); 26 wiring-plan tests standalone; fmt. The Windows-only halves of wasapi_cap.rs and audio_control.rs are NOT compile-verified anywhere yet. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 09:02:12 +02:00
enricobuehlerandClaude Opus 5	7077b0a0df	feat(core/audio): bitrate tiers, a shared de-jitter policy, and a redundant audio plane ... Foundation for the audio quality + latency plan (design/audio-quality-and-latency.md). All three pieces are pure and unit-tested here so the four client rings and the Windows host glue that follow stay thin. **Bitrate tiers** (`AudioTier`). The layout table's `bitrate` becomes the `Standard` value, so that tier reproduces the pre-tier wire byte-for-byte — the tier machinery is provably non-regressive. `High` (stereo 256 kbps) is the default: 5 ms Opus frames are much less efficient than 20 ms ones, so the historical 128 kbps buys roughly what ~100 kbps buys at 20 ms, while the same session carries tens of Mbps of video. Purely a host-side encoder knob — libopus reads the bitrate out of the packet, so no client change and no negotiation. **`JitterPolicy`** — the ms-denominated de-jitter state machine every client will share. Two defects it exists to fix: (1) each ring computed its target as `3 x quantum`, a sane 15 ms at a 5 ms quantum and a silent 64 ms at a 20 ms one; (2) every ring primed *up* and clamped at a ceiling, and none walked the depth back *down*, so drift/bursts added latency permanently — Android, with no shed at all, converged on its 120 ms cap. Here a depth EWMA that sits above target for 2 s of consumed audio sheds ONE 5 ms frame with a crossfade. Driven by samples consumed rather than the wall clock: allocation- and syscall-free (safe in a realtime callback) and deterministic under test. `every_preset_sheds_before_it_trims` pins the invariant that makes this real rather than decorative. The first draft had `headroom_ms` <= the shed threshold on all four presets, so the ring was trimmed back before the average could ever reach the shed point: drift correction was dead code and the ratchet test passed for the wrong reason (the hard cap did the work). `a_transient_burst_does_not_shed` caught it. The shed point is now derived from `headroom_ms` so it cannot invert again. **`0xD2` redundant audio** — each datagram carries its frame plus a copy of the previous one, so a single lost packet is reconstructed instead of concealed. Opus in-band FEC cannot do this job: LBRR is a SILK feature and the desktop encoder is CELT-only (RESTRICTED_LOWDELAY, 5 ms), so `set_inband_fec` there is a no-op. Costs no latency — the copy rides the successor, which arrives inside de-jitter slack that already exists. Gated capable-and-agreed via CLIENT_CAP_AUDIO_RED/HOST_CAP_AUDIO_RED; every other session keeps the `0xC9` wire unchanged. 0xD1 is left free for the pad-audio program. cbindgen: prefix the four new exported constants. `FRAME_MS`/`SAMPLE_RATE_HZ` as bare C macros are the same hazard the BTN_* renames already document — a clashing #define takes the last definition silently rather than failing to compile. Verified: 300 core tests, clippy -D warnings, fmt. (`c_abi` fails identically on a pristine tree — this Mac has no system libopus for the C harness link.) Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-04 08:11:35 +02:00
enricobuehler	5582a6ea51	Merge branch 'main' into worktree-haptics-m1-rumble-seq	2026-08-03 19:17:01 +00:00
enricobuehler	ab4cd06e86	Merge remote-tracking branch 'origin/main' into worktree-haptics-m2-pad-slots	2026-08-03 19:47:34 +02:00
enricobuehler	3eab1e41df	Merge remote-tracking branch 'origin/main' into worktree-haptics-m1-rumble-seq	2026-08-03 19:47:32 +02:00
enricobuehler	1ae8b4d4ca	fix(client/abr): let the ceiling follow a host-initiated re-target ... Interaction between two fixes in this series. The host now tells the client when a rebuild re-resolves an Automatic rate, and that rate can legitimately sit ABOVE the client's climb ceiling — the ceiling is the negotiated start rate until the capacity probe raises it, while the host's re-resolve answers "what do these pixels actually need" (a 1080p session mirroring a 4K panel resolves ~3× higher). Left alone, the client would learn the new rate, notice it was above a stale ceiling, and step the host straight back down off the rate it had just chosen for itself. So an ack raises the ceiling to meet it. `set_ceiling` only ever raises and still clamps to PUNKTFUNK_ABR_MAX_MBPS, which is the one limit that should bind here. No effect on ordinary acks: a climb is never requested above the effective ceiling to begin with.	2026-08-03 18:53:02 +02:00
enricobuehler	33ecd8e1a5	fix(client/abr): a granted climb disproves the learned cap ... Completing the cap-escape fix. Backing the re-probe clock off to 12 s got the client asking again quickly, but each ask only LIFTED the cap by +12.5 % — so even a host that had fully recovered still granted the session its real ceiling one small step at a time, ~4 minutes from the 20 Mbps default to a 300 Mbps link. The crawl was never the point; re-learning was. A request granted IN FULL at or above the cap is the host's own word that the limit is gone. Drop the cap outright at that point instead of nudging it. A standing limit is unaffected — it answers the same re-probe with another short ack, which re-latches it and doubles its clock, exactly as before. Adds the end-to-end regression the sweep was really about: a session pinned at 20 Mbps by a transient cadence refusal, under a probe-measured 300 Mbps ceiling, now reaches 150 Mbps in 22 windows (~16 s) where it used to need ~17 minutes.	2026-08-03 18:53:02 +02:00
enricobuehler	48565c4e9e	fix(host/abr): stop pinning Automatic sessions, and tell the client when the rate moves ... Two host-side halves of the same sweep. **The cadence latch.** `cadence_degraded` — which makes the control task refuse bitrate CLIMBS — was latched true for as long as the session was escalated (adaptive capture depth or pipelined retrieve), independently of whether encode was still missing deadlines. The client cannot tell that refusal apart from an encoder's real ceiling: both arrive as a short `BitrateChanged`, and two identical ones latch a cap. Escalation needs ~20 net behind-frames, which a startup hitch supplies while the ABR is still in slow start at the 20 Mbps default — so one transient pinned the whole session there, long after the escalation had bought back the headroom it was for, and escaping cost +12.5 % per 60 s. An escalated session is still judged strictly (ANY net behind-frame keeps it flagged, where an unescalated one gets the full bucket), but being escalated no longer flags it by itself: escalating exists so cadence CAN be held, and once it is, refusing climbs refuses the thing that worked. The rule moves into `encode_behind_cadence` so it is stateable and testable. **The silent re-target.** `adopt_built_bitrate` publishes the rate a rebuilt pipeline actually opened at — `build_pipeline` re-resolves an Automatic rate whenever the source delivers a size the session did not negotiate, the mirrored-panel case — and the encoder's own clamp can land below what the control task already acked. Neither reached the client, whose controller keeps its own copy of that number as its climb base. A 1080p client mirroring a 4K panel therefore believed 20 Mbps while the host encoded 60, and its first climb computed from the stale base asked for 40: a re-target DOWNWARD, paying an encoder rebuild to get there. Both paths now push the applied rate to the control task, which sends `BitrateChanged` — the existing 9-byte message, which already means precisely this and which clients already handle arriving unprompted. No wire-format change, no capability negotiation, old clients unaffected. 2 host tests added.	2026-08-03 18:53:02 +02:00
enricobuehler	e9a7373c76	fix(client/abr): measure delivered throughput in media bytes, not wire bytes ... The controller's two throughput-driven gates both compare "what the pipeline carried" against the ENCODER's target: the utilization gate asks whether a clean window actually tested that target (a calm menu proves nothing), and the never-decaying proven mark bounds how far every later climb may step. Both were fed `bytes_received`, which counts every accepted datagram — headers, FEC parity, probe filler, audio. So the figure rose with the redundancy the host adds in ANSWER to loss: at 25 % FEC the gate passed with the encoder emitting ~55 % of target, and the proven mark inherited the same inflation permanently. The signal was weakest exactly on the lossy links it exists for. Count data-shard payload separately at the reassembler's routing decision — the same place, and for the same reason, the probe counters are already stamped — and feed the ABR that. First time both gates are dimensionally honest: a media rate compared against a media target.	2026-08-03 18:53:02 +02:00
enricobuehler	f7a8c2013d	fix(client/abr): the controller stops learning the wrong lessons from one window ... Six defects found by a sweep of the Automatic-bitrate path, all of them the same shape: a single window, or a single refusal, taught the controller something it then treated as permanent. - Rolling baselines (OWD, client decode, host encode) armed off ONE sample. The baseline is a rolling minimum, so one window IS the floor — and `on_ack` deliberately clears the encode baseline after every decrease we ourselves asked for, re-opening that hole each time. A calm re-seed window followed by ordinary motion read as 4 ms of "congestion", backed off, cleared again, and ratcheted toward the floor on a link that was never the problem. All three now need BASELINE_MIN_WINDOWS of evidence before they may fire, via one shared `score_baseline` (the three copies had already drifted apart). - A mode switch rebased only the encode baseline. Decode and OWD are just as mode-scoped: 4K120 decodes slower and puts bigger frames on the wire than 1080p60, so the old floor was one the new mode cleared on its first window — ~30 s of every window scoring bad, i.e. a backoff every other window. A switch UP in mode cratered the rate instead of raising it. `proven_kbps` goes with them; throughput the old mode's decoder digested is not evidence about this one. - `proven_kbps` — never decayed, and permanent authority over how far every later climb may step — was raised by any window without a decode rise, including ones scored SEVERE. The windows that overstate delivered throughput are exactly the damaged ones: a stall's backlog draining at once, a flush's queue, the FEC surge answering a loss burst. Now only clean windows raise it. - A learned cap escaped at +12.5 % per ~60 s. The host cannot distinguish a durable encoder ceiling from a climb refused while it is transiently behind cadence, and the latter routinely latches during slow start at the 20 Mbps default — from which crossing the gap to a probe-measured ceiling took upwards of twenty minutes. Re-probe after 12 s instead, doubling the interval each time the lift is immediately re-learned: a transient is out in one interval, a real ceiling settles into a slow poll. - The decode cap latched AT the rate that choked, authorizing a climb straight back into the failure, and a bare jump-to-live flush could teach a "decoder knee" from what was a network event. It now latches just under the choke rate (inside the ±1/8 band the evidence already required) and only credits a flush where the decode signal is absent and cannot speak for itself. - PUNKTFUNK_ABR_MAX_MBPS bound only probe-learned ceilings, not the negotiated start rate — so the one knob an Automatic session gives the operator did nothing when the session already started above it. It now binds at construction, and a session sitting above its ceiling steps down to it (no congestion signal will ever find that: the link is fine, the cap is policy). Also: a SetBitrate dropped by a full control queue counted toward MAX_UNACKED, so three of them retired the controller for the session while logging that an "older host" was at fault. The pump now tells the controller what happened. Wire format and ABI untouched. 34 abr tests green (3 new).	2026-08-03 18:53:02 +02:00
enricobuehler	9979489b56	fix(host/pads): an unplugged controller actually disappears ... Unplug a controller mid-session and the virtual pad it was driving outlives it: the game keeps seeing a connected, permanently idle device for the rest of the session. The single-controller session — the common case — hits this every time. `PadSlots::sweep` needs two passes to retire a pad. The first pass to see the mask bit clear only ARMS the 300 ms devnode-churn grace; the drop lands on a later pass. But sweep runs only from a state frame, and the producer emits exactly one frame per detach — `native/input.rs` guards the emit on the bit still being set — so for a pad with no still-changing sibling in the same manager, the second pass never comes. Nothing periodic reaches sweep: `heartbeat` and `pump` walk the slots without it. Split the two halves. `sweep` still folds a frame's mask into the grace clocks, and `reap` — new — drops whatever has run out, with no frame needed. Every manager now reaps on the periodic pump it already runs, so the teardown completes ~300 ms after the detach instead of never. `reap` deliberately cannot arm a clock: it only reads `inactive_since` and clears it, so a pad whose bit never went clear has nothing to run out and no amount of reaping can drop it. That is what makes it safe on a hot loop, and it keeps the anti-flap guarantee intact — a mask that blips clear and returns still never churns a devnode. The two existing tests hand-fed a SECOND removal frame, which production never sends; they passed while the real path leaked. Both now drive the unplug through a pump tick, and PadSlots gains three tests pinning the new invariants. Verified non-vacuous: with the reap neutered, both manager tests fail with "the pump tick never completed the unplug". Behaviour notes: this puts UI_DEV_DESTROY on the GameStream control thread's budget for the first time, and a mask glitch longer than the grace now really does flap — which is SWEEP_GRACE working as documented, so the constant stays. Found by the 2026-08-03 force-feedback sweep (B2 — see the backlog in punktfunk-planning design/haptics-sweep-2026-08-03.md).	2026-08-03 17:34:47 +02:00
enricobuehler	14502769e0	fix(host/input): rumble comes back when a controller does ... Unplug a pad mid-session and plug it back in, and roughly half the time it never rumbles again for the rest of the session. The removal arm restarted the pad's rumble sequence counter. The client's reorder gate does not restart: `rumble_last_seq` lives for the whole QUIC connection and has no reset path, so it still holds whatever the pad reached before the unplug. Restarting the host counter therefore hands the client a seq it has already seen, and its wrapping half-space compare drops every envelope until the counter climbs back past the stored value — up to 128 sends. Since the counter only advances on a level change or a ~120 ms renewal while a level is non-zero, that spans many separate rumble events, so it reads as a flaky controller rather than a clean outage. Whether it bites is decided by how much the pad rumbled beforehand, which is why it looks intermittent: a pad that never rumbled before the re-plug has `None` on the client side and always heals. The counter now survives, matching the sibling pad-state gate — whose comment eleven lines above already explains that a re-plug must arrive with a still- newer seq to be accepted. The three clears that actually end the stale lease move into `clear_pad_feedback`, whose signature deliberately has no seq parameter so the arm cannot regress by editing. Covered by a regression test that drives the real wire encoder and the real client gate, and asserts the pre-fix behaviour is genuinely rejected across the whole forward window, so it cannot pass vacuously. Found by the 2026-08-03 force-feedback sweep (B1/T5 — see the backlog in punktfunk-planning design/haptics-sweep-2026-08-03.md).	2026-08-03 16:57:11 +02:00
enricobuehlerandClaude Opus 5	442ea12b96	test(mgmt): pin the two things that would silently break plugin logging ... The runner holds the PLUGIN token and nothing else — on Windows its LocalService principal cannot read the admin one at all. `plugin_may_access` is an exclusion list, so `/plugins/logs` is reachable today only because it happens not to match `/ui-credential`. If that ever changed, plugin logs would go quiet in the console with no other symptom and no failing test. Now asserted on that lane directly. The second test covers ingest end to end through `GET /logs`: the `plugin:` target prefix the console's Host/Plugins filter keys on, the level coercion (an unranked level would sort as 0 and hide under every filter setting), a sourceless line being attributed to the runner rather than to nothing, the caller's timestamp surviving the trip, and an oversized batch being refused whole. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:56:25 +02:00
enricobuehlerandClaude Opus 5	365caa23be	fix(plugins): plugin output reaches the console's log page, and /tmp is no longer hidden from the runner ... A user could not get the VirtualHere plugin to use their VirtualHere client and asked, reasonably, where the logs were. There was no good answer, and the reason they were stuck turned out to be ours. **The runner could not see /tmp.** `punktfunk-scripting.service` set PrivateTmp=yes, which hands the unit a private tmpfs. But integrating with things already running on the box is the entire job of a plugin, and on Linux those talk over /tmp: VirtualHere's client IPC is the FIFO pair /tmp/vhclient + /tmp/vhclient_response, X11 is /tmp/.X11-unix. So the plugin launched the vendor binary happily and could then never reach the daemon behind it — while the same command worked perfectly in the operator's own shell, because that shell has the real /tmp. No config change could fix it, which is exactly the loop the report described. PrivateTmp is now off, with /tmp added to ReadWritePaths (which ProtectSystem=strict would otherwise make read-only). **Plugin logs now land in the console.** Plugins are not host child processes — the runner is a separate bun process that import()s each plugin in-process — so nothing they print passed through the host's tracing, and the console's Logs page could not show a single plugin line. The fallback was journalctl on Linux; on Windows the runner's scheduled task writes no log file at all, so a failing plugin was diagnosable only by stopping the task and re-running the runner by hand. Both mean shell access on the host box, which is what the console exists to avoid — and it left the one question a stuck user asks with no answer. So the runner now tees its output to POST /api/v1/plugins/logs, and those lines join the host's own ring under one cursor, targeted plugin:<name>. The console grows a Host/Plugins switch beside the level filter; an empty Plugins view says the thing that is actually usually wrong (the runner isn't running) rather than "adjust the filter". The shipper keeps stdout authoritative — journald and foreground output are unchanged whatever the host is doing — and is built so that logging can never hurt the thing being logged: it never throws into a caller, holds a bounded queue that drops oldest and then says how many, backs off when the host is away (a restart is normal), and re-sends a batch the host failed to take. Lines logged while a POST is in flight are kept, which cost one round to get right: the first version held its recursion guard across the await and silently dropped exactly the lines a busy plugin produces. Runner lines that report a failure (a refused unit file, a crashed plugin, a give-up) now go out at warn/error instead of all arriving as INFO, so the console's level filter means something for them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:47:51 +02:00
enricobuehlerandClaude Opus 5	6b3c582eb1	feat(client/present): use the driver's queue-free vblank mode where it exists ... `VK_PRESENT_MODE_FIFO_LATEST_READY_EXT` is FIFO's tear-free vblank pacing that presents the LATEST READY image at each refresh and retires the older ones, instead of draining a queue. That is precisely what the software glass gate emulates — so where the driver offers it, the driver does the job, and it does it exactly where the gate matters most: a surface with no MAILBOX gets newest-wins behaviour back without the app holding frames. Found by asking the surface what it actually offers rather than trusting a comment: the previous commit's `surface present modes` line read back `[MAILBOX, 1000361000, FIFO]` on NVIDIA/Wayland, and 1000361000 is this mode. The extension postdates the Vulkan headers ash 0.38 is generated from (1.3.281), so there is no binding — hence the bare number in the log. It is hand-declared here: mode value, extension name, and `VkPhysicalDevicePresentModeFifoLatestReadyFeaturesEXT` spliced into the device pNext chain. One trap worth naming: the SURFACE advertises the mode even with the extension disabled, and using it on that basis is undefined — so the ladder only offers it when the device feature actually came back true and we enabled it. The gate/probe predicate had to split in two, and the distinction is the point: * `needs_glass_gate()` — FIFO and FIFO_RELAXED only. NOT this mode: gating on top of a driver that already retires stale images would hold frames back to emulate something the presentation engine is doing, paying the serialisation twice, which is the ~27 ms the last commit measured. * `vblank_locked()` — the whole FIFO family INCLUDING this mode, because it still presents on the refresh boundary, so the VRR cadence probe's premise ("with VRR off, a present waits for vblank") still holds. Ranking: MAILBOX first (measured good at 1.4 ms), then LATEST_READY, then plain FIFO — so a MAILBOX-less surface reaches newest-wins in the driver rather than in our gate. MEASURED ON GLASS (.21, NVIDIA 610.43.03, GNOME/Wayland): the extension probe, feature enable and swapchain creation all succeed with a mode ash has no binding for. Default ladder selects MAILBOX with `fifo_latest_ready=true`; the VRR ladder selects `present_mode=1000361000` and measures `display 2.6 ms (pace 0.6 + latch 2.0)` — against 13-28 ms for plain FIFO + gate on the same box. The vblank-locked path is now MAILBOX-class. That changes the previous commit's reversal. The VRR ladder was reverted to opt-in because it led with plain FIFO and cost ~27 ms; led with LATEST_READY it costs 0.6 ms over MAILBOX. So `allow_vrr` is automatic again WHERE THE DEVICE OFFERS THE MODE, and stays behind `PUNKTFUNK_VRR_FIFO=1` where it does not — on those drivers the ladder would fall back to plain FIFO and the regression returns. Both branches are pinned by tests. This also retires a dead switch: the "Follow variable refresh rate" row did nothing at all after the reversal, and now does something real on any driver with the extension. ⚠ Still unverified off this box: whether Windows and Intel drivers expose the mode at all. Nothing measured here carries over — Windows Vulkan WSI goes through DXGI, so exposing the enum and mapping it usefully onto flip-model semantics are separate questions, and Intel is a different vendor stack again. Both facts are logged unconditionally now (`surface present modes` + `fifo_latest_ready=`), so one run on any box settles it. The code is safe either way: the mode is only requested where the device feature enabled, and `allow_vrr` only goes automatic there — everywhere else the shipped MAILBOX-first behaviour is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:01:56 +02:00
enricobuehlerandClaude Opus 5	e08474d96d	fix(client/present): log the surface's actual present modes, and document the VRR opt-in ... "AMD's Windows driver offers no MAILBOX" is the premise the FIFO glass gate is built on, and it has been carried in a code comment rather than measured. Present modes are a property of the (surface, device) pair — they vary by platform surface, driver version and fullscreen state — so the only way to settle it is to read them back from real machines. One unconditional log line makes every field log answer the question. First reading, .21 (NVIDIA 610.43.03, GNOME/Wayland): surface present modes available=[MAILBOX, 1000361000, FIFO] Two things fall out. No IMMEDIATE and no FIFO_RELAXED on this surface, which is why a PUNKTFUNK_PRESENT_MODE=immediate run reported mode=fifo — the pin was not offered and the ladder fell through; previously that looked like a puzzling result and is now evidence. And 1000361000 is VK_PRESENT_MODE_FIFO_LATEST_READY_EXT: FIFO's tear-free vblank pacing that presents the LATEST READY image instead of draining a queue — the driver-native version of what the glass gate emulates in software, and a candidate to replace it wherever the driver exposes it (needs VK_EXT_present_mode_fifo_latest_ready enabled at device creation, so a work package rather than a tweak). Also documents PUNKTFUNK_VRR_FIFO, which the previous commit introduced without a docs entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:01:56 +02:00
enricobuehlerandClaude Opus 5	f422ae3e38	fix(client/present): what the first on-glass session found, including a reversed default ... WP6 ran against .21 (CachyOS, RTX 5070 Ti, NVIDIA 610.43.03, GNOME/Wayland, 1080p60 HDMI, VRR provably disabled — `org.gnome.mutter experimental-features` is empty), host and client on the same box, `VK_KHR_present_wait` available. Five defects that unit tests and both CI gates had passed over: 1. The latch learner and the VRR probe observed NOTHING. Both derived spacings with `windows(2)` inside a single batch, but the run loop drains present-wait samples every pass, so a batch is normally ONE stamp. `period_us` read back exactly the mode fallback — correct by luck on a 60 Hz panel, wrong the moment a mode lies, which is the entire reason PanelGrid exists. The tests fed 40-stamp batches, a shape the live loop never produces. Spacings are now measured against the previous stamp across calls. 2. The VRR reference was circular. It compared spacings against the LEARNED period, but the grid cannot be learned from our own presents when the stream runs below panel rate — we only ever observe multiples ≥ our frame interval, so the learner adopts our own cadence and every delta is on-grid by construction. It learned 18-22 ms from a 40-50 fps stream and reported VRR on a display with VRR off. The reference is now the DISPLAY MODE's period, which is the vblank grid presents actually quantize to. 3. The probe is meaningless outside FIFO. MAILBOX deliberately decouples presents from scanout, so its stamps are never grid-quantized: same panel, same minute, FIFO read `no` (correct, period 16.4 ms) and MAILBOX read `yes` (wrong). Outside a FIFO-family mode the honest answer is Unknown, and that is now what it reports. 4. Round evaluation was per-CALL rather than per-sample, so the verdict depended on how the caller batched its stamps. Closed inside the sample loop now, with a test pinning bulk-vs-one-at-a-time equivalence — the same invariant (1) violated, in a second place. 5. `force_latency` was dead code without the `pyrowave` feature: a warning in the `--no-default-features` build CI actually ships (the Windows ARM64 leg). The gate only ever tested default features; it now tests both. DESIGN REVERSAL — the VRR FIFO-first ladder is opt-in (`PUNKTFUNK_VRR_FIFO=1`), no longer default. It shipped default-on for `allow_vrr` + fullscreen, which is the default configuration. Measured A/B, same box, back to back, reproduced across three runs: FIFO+engine `display 28.4 ms (pace 11.8 + latch 16.6)` versus MAILBOX `1.4 ms (0.2 + 1.2)`. Under a compositor the FIFO present's on-glass confirmation arrives a whole refresh later and the presenter serialises behind it. The VRR upside is real in principle but UNMEASURED — no VRR panel was available — and a default that is measurably ~27 ms worse on the hardware we could test, bought against an unproven win on hardware we could not, is the wrong way round. A test pins the default to MAILBOX; flip it back when a VRR panel confirms the win. NOT measured, and not claimed: the FIFO glass gate's own headline. The standing queue only forms when the stream rate approaches the panel rate, and an idle GNOME desktop is damage-driven at 40-50 fps on a 60 Hz panel, so `gated`/`forced` read 0 in every mode and the mechanism never engaged. The 11-13 ms figure is still the code's inherited documentation, not a fresh measurement. It needs its actual target: AMD-on-Windows (no MAILBOX, direct scanout) under load. Rig caveats recorded rather than smoothed over: host and client shared one GPU, so absolute latencies are contended and run-to-run variance was large, and it could not be visually confirmed what the physical screen showed. Mode selection, the fallback ladder, the VRR verdict and the counter plumbing are robust to that; absolute numbers are not. Gates: fmt, clippy -D warnings over the five client crates AND the `--no-default-features` build (added because defect 5 hid there), 160 tests. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:01:56 +02:00
enricobuehlerandClaude Opus 5	e38e3c44c9	feat(client/present): V-Sync and VRR become real settings, and VRR is measured ... WP3 of design/desktop-presentation-rebuild.md. The `vsync` and `allow_vrr` settings have existed since WP1 but nothing consumed them — the swapchain picked MAILBOX-or-FIFO once, from an env var, and froze. This makes them mean something, which is also what unblocks their settings rows (deliberately withheld from WP5 rather than shipped as dead switches). Present-mode selection is now a preference ladder, not a constant: * V-Sync off — IMMEDIATE, then FIFO_RELAXED, then the tear-free modes. Asking to tear and silently getting vsync is a lie, so the mode that actually took is named in the stats line and a refused preference is logged requested-vs-active. * V-Sync on + VRR allowed + fullscreen — FIFO first. On a variable-refresh panel with direct scanout the FIFO present IS the flip, so the panel follows the stream's cadence instead of a fixed grid; MAILBOX would decouple presents from scanout and re-quantize to the compositor's clock. This is only safe because WP2's glass gate bounds the standing queue that historically made FIFO costly. * Otherwise — MAILBOX then FIFO, the shipped default, unchanged. `PUNKTFUNK_PRESENT_MODE` still pins a mode outright and now falls back to the settings (rather than to mailbox) when the name is unknown. VRR detection is MEASURED, never queried. No portable query exists — SDL exposes none, Wayland does not report adaptive-sync state, Windows surfaces nothing through Vulkan — and the platforms that do answer have been caught lying (see the Android per-uid refresh-rate finding). The discriminator is quantization: on a fixed-refresh panel every on-glass instant lands on the vblank grid, so the spacing between presents is ~k×period for whole k even when the stream runs slower than the panel (it just picks a larger k); under real VRR the panel refreshes when we present, so the spacing follows our own cadence and sits off the grid. `CadenceProbe` folds each delta to its distance from the nearest multiple of the learned period and takes the median. Tri-state: it stays Unknown below 24 deltas and after a display change, so `vrr` is reported only when it has been measured — never inferred from what the display claims. Also fixes the read-once refresh rate: `native.refresh_hz` was sampled at startup and never revisited, so dragging the window to another monitor left a 60 Hz-seeded clock pacing a 144 Hz panel. `WindowEvent::DisplayChanged` now relearns the latch grid, resets the cadence verdict, and clears the served-slot latch. Settings rows for both, on all three surfaces (GTK, WinUI, console). The console's V-Sync row is reachable in Gaming Mode, which is the only editor a Deck user has. Gates: punktfunk-rust-ci linux/amd64 — fmt, clippy -D warnings over pf-client-core, pf-presenter, pf-console-ui, the session binary and the GTK client, 160 tests (the two new ones cover every ladder and both cadence regimes, including the case that matters most: a stream slower than a FIXED panel must still read as fixed). WinUI leg on the Windows runner .133: clippy=0 tests=0, against a tree proven by content to contain the edit. ⚠ On-glass validation is still owed and is NOT claimed here: every box with a real display was powered off when this landed, so the VRR ladder and the detector have been exercised only against synthetic stamps in unit tests. Rebase follow-up: `20de58a7` landed the same "panel grid can be wrong in both directions" defect fix on Android and extracted the corrected learner into `punktfunk_core::phase::PanelGrid` for the iOS and desktop presenters to share. This clock had the identical bug — it capped the learned period at the display mode's refresh, and the mode is only a CLAIM, so a display really running slower than it advertises pinned a grid whose instants never arrive, for the session, with no way back. Adopted the shared learner rather than carrying a second, buggier copy; still fed the window's MIN spacing, which preserves the k×period resistance the cap was actually aimed at while the streak requirement lets a genuinely slower panel be discovered. New test: seed 120 Hz, real panel 60 Hz, the clock must climb back out. Took the same commit's third lesson too: the adaptive margin widened on a latch over 1.5×period (a number picked here), and now widens on the latch exceeding one period plus the lead already applied — the slot actually aimed at. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:01:56 +02:00
enricobuehlerandClaude Opus 5	b1ac4d02de	feat(client/present): the display stat splits, and the intent reaches the settings UI ... WP4 + WP5 of design/desktop-presentation-rebuild.md, on top of the WP1/WP2 engine. The engine shipped with no way to choose it and no way to see what it cost; this closes both. WP4 — the display stage splits into `pace` (decoded → present-submit, our own pipeline) + `latch` (submit → on-glass, the presentation queue and the vblank wait), off the `submitted_ns` stamp WP2 already carried. That split is what makes a high `display` self-diagnosing: latch dominating is the vsync floor or a standing queue, pace dominating is us. A `present:` line joins the Detailed tier naming the live swapchain mode — the answer to most "why is my latch a whole refresh" questions, since a MAILBOX request silently lands on FIFO wherever the driver has no mailbox — plus the engine's counters, rendered only when they are non-zero so a healthy latency session shows just the mode. Deviation from the plan: the planned `display_adj` twin is NOT here. It was specified as `display − latch_p50` for parity with the Apple HUD's shaved figure, but with a real per-sample `pace` percentile that twin is the same quantity derived worse (subtracting percentiles). `pace` IS the Apple-comparable number — Apple subtracts its OS present floor, the latch is ours — and the user docs now say exactly that. WP5 — Prioritize + Smoothness buffer on all three surfaces: the GTK dialog (a new Presentation group on the Display page), the WinUI settings page, and the console settings screen, which is the ONLY editor reachable in Gaming Mode and so the one that decides whether Deck users can reach this at all. The buffer control follows the intent the way echo cancellation follows the mic: hidden on the desktop shells, dimmed and inert on the console, where a row that vanished mid-list would shift everything under the cursor. The V-Sync and VRR rows are deliberately NOT here. Their settings exist and are profile-routed, but the swapchain does not honour them until WP3, and a toggle that does nothing is exactly how "Full chroma (4:4:4)" shipped inert on desktop for three releases after being announced. Buffer labels carry no millisecond hints (Apple/Android derive them from the session refresh): under a Native mode the shells do not know the refresh at settings time, so the captions state the cost as one refresh per frame rather than a confident wrong number. Docs: the stats page documents the split and the `present:` line, and stops claiming Linux/Windows measure to the present instant (untrue since present_wait); client-settings documents both new rows and drops the stale claim that the desktop 4:4:4 toggle has no effect (it was wired to VIDEO_CAP_444); configuration documents PUNKTFUNK_PRESENTER and PUNKTFUNK_PRESENT_DEBUG. Gates: punktfunk-rust-ci linux/amd64 — fmt, clippy -D warnings over pf-client-core, pf-presenter, pf-console-ui, the session binary and the GTK client, 158 tests. The WinUI leg cannot be reached by any Linux or macOS check, so it was compiled on the Windows runner .133: clippy -D warnings and tests both exit 0, against a tree proven by content to contain the edit. ⚠ The first run there reported a false pass — the script printed its done-marker while the log carried a test failure (a STATUS_DLL_NOT_FOUND launch failure, ffmpeg's DLLs missing from PATH); the harness now echoes each phase's exit code so the verdict is a fact in the log rather than an inference from a marker. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:01:38 +02:00
enricobuehlerandClaude Opus 5	5f55fa874a	feat(client/present): the desktop presenter gains the Apple/Android intent model ... WP1+WP2 of design/desktop-presentation-rebuild.md. The shared Linux/Windows session client presented arrival-paced with no pacing layer at all: two depth-2 newest-wins hops into a drain-to-newest and an immediate present. That IS the lowest-latency intent, but it was unnamed, unselectable, and had no alternative — and on a surface without MAILBOX (AMD's Windows driver offers none, and any compositor holding images does the same) the swapchain's own FIFO becomes a standing queue worth a measured 11-13 ms at 60 Hz. WP1 — the settings cluster, under the keys the Apple client already writes into the shared profile catalog (present_priority / smooth_buffer / vsync / allow_vrr): mismatched names would ride SettingsOverlay::extra, carried but never applied. PresentPriority::resolve mirrors the Android reference exactly (anything but an explicit "smooth" is latency; a buffer outside 1..=3 becomes 2), so a profile authored on any client means the same thing on all of them. Only the first two are consumed here; vsync/allow_vrr land in WP3. WP2 — the engine (present_pace.rs, pure state + arithmetic, 6 tests): - FrameStore: newest-wins slot, or the smoothing FIFO with preroll-to-capacity, drop-oldest overflow, and an underflow that re-arms the preroll (repeat by omission) — the Apple/Android semantics, with qDrop/qDry counters. - LatchClock: the panel grid learned from VK_KHR_present_wait glass stamps, min positive spacing capped by the mode refresh (measured, never queried — VRR and Android's per-uid refresh lie both punish trusting a reported rate). It now also publishes the host-facing LatchGrid, so the phase-lock report and the local scheduler cannot disagree about the grid. - PresentGate: one undisplayed present in flight on FIFO surfaces, with the 100 ms stale force-open. This is the standing-queue killer, and it is inert on MAILBOX/IMMEDIATE and without present timing — where behaviour stays byte-for-byte the shipped arrival pacing. Wiring: glass samples drain every pass (a 1 Hz batch would starve clock and gate) and the waiter pushes an SDL wake, so a gate reopen never waits out the event timeout; smoothness serves one frame per latch slot and tightens the loop's wait to that deadline; the adaptive slot margin starts at 0 and widens +500 us per missed window toward 2.5 ms (a fixed lead was measured to be pure display tax). PUNKTFUNK_PRESENTER=arrival disables the whole engine for field A/B without a rebuild. PyroWave collapses smoothness to latency for the stream: its plane-ring retirement accounting assumes the depth-2 newest-wins hand-off, and all-intra frames make buffering moot anyway. Gates (punktfunk-rust-ci, linux/amd64, sources touched first so a warm target cannot print a vacuous Finished): clippy -D warnings across pf-client-core, pf-presenter and punktfunk-client-session; 80 + 32 tests pass; rustfmt clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 00:00:50 +02:00
enricobuehlerandClaude Fable 5	d839f4c2b6	fix(client/windows): settings stop going stale behind your back, and the log has a door ... A field reporter's codec setting "changed by itself" between sessions. Nothing writes the negotiated codec back — what they saw was a stale snapshot. `AppCtx.settings` is loaded ONCE at process start and the page renders from it, but this process is not the file's only writer (the spawned session persists its match-window size, the console UI and Decky save too), so the page showed values another process had already replaced — until a row was touched and `commit`'s rebase pulled the file in, at which point the value visibly jumped. The 2026-07-31 rebase fix covered the whole-file writers and missed two spots: nothing re-based on page ENTRY, and the profile-scope commit arm cloned the snapshot without reloading, so overlay absorption diffed against stale globals. Both now re-base on the file. Two more ways a setting could vanish or cost time: * An older binary's whole-file save DROPPED a newer client's keys — `Settings` had no unknown-key passthrough, unlike `SettingsOverlay`, whose `extra` map already gives profiles exactly that contract. Extended to the globals: additive, empty on every existing store, and an empty map serializes to nothing so no file churns. (`save()` was already temp+rename, so the torn-file → silent-Default reset was closed.) * "Check the client log" never said WHERE. Settings ▸ About grows an Open log folder row (%LOCALAPPDATA%\punktfunk\logs, folder not file so the rotated .old generation is in reach), and the failed-spawn banner now names the path. The 4:4:4 caption said "HEVC only, and only where the host can encode it", which sends people hunting: the host gate is PyroWave or an NVENC backend. It says so now. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 23:49:45 +02:00
enricobuehler	0de161e29b	Merge pull request 'feat(clients/input): controllers can stop being forwarded, for couches that hand the pad over another way' (#22) from worktree-gamepad-passthrough-toggle into main ... Reviewed-on: unom/punktfunk#22	2026-08-02 21:38:01 +00:00
enricobuehlerandClaude Opus 5	b297542c4d	feat(clients/input): controllers can stop being forwarded, for couches that hand the pad over another way ... A controller that reaches the host by USB passthrough — VirtualHere and friends, or simply a pad plugged into the host — arrived there twice: once as the real device, once as the virtual pad this client built from the same hands. Games read both, so a stick drifts against the centred second pad and menus take every input twice. New per-client setting, "Forward controllers", default on (today's behaviour). It is tier-P, so a profile can decline what another profile forwards. On Linux and Windows it is deliberately stronger than "send nothing". Opening a controller is what CLAIMS it — SDL's HIDAPI drivers take the device node — and a claimed device is one a passthrough tool cannot bind, so with this off the session opens no slot at all and never enables the Valve HIDAPI drivers. Menu navigation is untouched: the launcher still opens the active pad, and a session supersedes menu mode whether it forwards or not, so the pad is free for the whole time a stream is up. The consequence, documented at both the setting and the chord: the controller escape chord is read off forwarded pads, so it is unavailable there. The Apple and Android input stacks claim nothing, so those clients keep their slots and their chords and only gate the wire sends — losing tvOS's only controller way out of a stream would have been the worse bug. Android does stop its DualSense and Steam Controller 2 USB captures, which do claim the device. Surfaces: GTK, WinUI, the console settings screen, Apple's touch and gamepad settings, the Android touch and gamepad settings, and Decky (which also hides the rows that now have nothing to act on). Everywhere the "which pad" and "pad type" rows grey out while it is off. Verified: cargo clippy --all-targets -D warnings + 79 tests on pf-client-core, pf-console-ui, punktfunk-client-session and punktfunk-client-linux (linux/amd64 container, gate proven non-vacuous with a planted error); swift build for the Apple clients; gradle compile + 49 unit tests for Android (likewise proven); tsc for Decky. clients/windows is UNCOMPILED — both Windows boxes were offline; its edits were reviewed against the helper signatures by hand. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 22:21:26 +02:00
enricobuehlerandClaude Fable 5	98e040fd01	fix(host/stream): the wire holds the session rate when the display outruns it ... PUNKTFUNK_VDISPLAY_HZ_MULT promises extra display refreshes without one extra frame on the wire, but the frame-driven trigger enforced its pace only as a per-gap floor: sleep to 0.9×interval, then wake on arrival. A source that always has a frame pending — the overdriven display under uncapped content — settled at 0.9-interval spacing, 1.11× the negotiated rate. That is the field report's 132 fps on a 120 fps session: ten percent more bitrate, encode and decode for frames a 120 Hz panel can only drop. A credit bucket (PaceBudget) now pins the long-run average at the pacing rate: credit accrues at one frame per interval of real elapsed time, capped at 1.25 frames of post-stall burst, and every submitted frame spends one. A grab may run early only against banked credit, so the 0.9 floor keeps its per-gap jitter headroom while the average cannot exceed the rate — and a source at or below it banks faster than it spends and is never delayed. Anchoring to real elapsed time also keeps the synchronous-encode overlap the arrival-anchored floor bought (the owed fraction absorbs a constant encode tail instead of stacking on top of it), and it cannot fight the phase lock's submit grid: both agree the period is the interval. The charge lives under the same guard as the gate — the legacy fixed tick paces by its own grid, and charging it without ever accruing would bank unbounded debt that stalls the loop if a rebuild later flips the capturer to arrival-wait. Verified on .25: native::stream tests 15/15 (three new PaceBudget tests), punktfunk-host 369/369, clippy -D warnings clean, fmt clean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 21:54:09 +02:00
enricobuehlerandClaude Fable 5	5174a59832	fix(capture/kwin): a hidden cursor leaves the stream — KWin's id-0 meta is the hide ... Since the 0.22.0 cursor work (the seat-pointer park + the metadata composite), a KWin capture-model stream always has a cursor — and it never went away again: not in game, not in Big Picture, not with a controller in hand (field report, 2026-08-01). The host blended the arrow forever because pf-capture deliberately ignores SPA_META_Cursor id 0, and once `visible` latched true nothing on Linux ever cleared it. Two producer contracts meet on id 0, and one flag now carries which one a stream follows. KWin rewrites the cursor meta on EVERY enqueued buffer and writes id 0 whenever Cursor::isOnOutput says the pointer is not in this stream — which covers both a globally hidden cursor and a client null-cursor surface (empty geometry intersects nothing). There id 0 IS the hide, and honoring it is what lets a game hide the pointer mid-stream. Mutter only rewrites a buffer's meta when the cursor changed, so recycled buffers carry stale id-0 regions between damage frames — honoring those flickered the cursor off between hovers (on-glass round 5), and that path keeps its last-known-state behavior. The flag rides from the backend that created the output (correct for registry-pooled reuse too — a kept display only ever matches its own backend) through capture_virtual_output into the parser's CursorState. The portal-monitor path stays on the stale-meta contract: the only thing routed through it today is Mutter's HDR mirror. Verified on .25: pf-capture 45/45, punktfunk-host 369/369, clippy -D warnings clean (pf-capture, punktfunk-host, cursor-probe), fmt clean. On-glass KDE validation still owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 21:54:09 +02:00
enricobuehlerandClaude Opus 5	20de58a78a	fix(android/present): the panel grid can be wrong in both directions, and the margin listens to the latch ... Three defects in the 0.23.0 timeline presenter, all found while root-causing the field report that turned out to be the slice wire. None of them is that bug; all three are real, and the first is the one that would still bite once it is fixed. The panel-period learner could only ever narrow. It is seeded from the display mode Kotlin asked for — and `preferredDisplayModeId` is a REQUEST the system may refuse (Smooth Display off, battery saver, thermal, an OEM governor). Ask for 120 Hz on a panel that stays at 60 and the presenter pins an 8.33 ms grid on a 16.67 ms display with no way back, for the rest of the session: it then aims at instants that never arrive and releases faster than the panel scans. The learner moves both ways now, and lives in `punktfunk_core::phase::PanelGrid` where it is host-testable and where the iOS and desktop presenters can share it. The asymmetry is kept and made explicit — narrowing is immediate (a finer real grid is always safe to subdivide onto, and it is the per-uid down-rate case the seed most often gets wrong), widening needs eight consecutive agreeing observations and then takes the narrowest of them, because one wide sample is a missed callback and eight in a row is a display that really did slow down. The glass budget was a prediction with nothing underneath it. `OnFrameRendered` already reports what actually reached glass, but the budget never consulted it, so a wrong grid could hand SurfaceFlinger frames indefinitely: BufferQueue fills, MediaCodec runs out of output buffers, the decoder stalls, and the no-output backstop starts begging for keyframes. Releases are now counted against their confirms and the presenter holds back past six outstanding — loose on purpose, since the callbacks are allowed to arrive batched and a held frame in the newest-wins slot is a dropped one. It self-clears when the confirms catch up, and writes the ledger off after the same 100 ms the stale reopen uses, so a platform that stops confirming can never wedge the stream. `qWait` and `unconfirmed` join the 1 Hz pf.present line, which is what would have made this visible from a log. The adaptive latch margin widened on `paced_drops` — the newest-wins store's own policy evictions, which happen whenever the stream out-runs the panel and say nothing about SurfaceFlinger's latch lead. On a healthy device that walked the margin to its 2.5 ms ceiling and re-imposed the display latency the P2e sweep had just measured away. It now widens on the measured latch exceeding one panel period plus the live margin, which is what a missed vsync actually looks like. Also corrects two doc comments that named `display.refreshRate` as the panel_hz source; it has been the mode table since the A024 down-rate fix. Gates: 278 punktfunk-core lib tests (7 new PanelGrid cases incl. the refused-mode regression), clippy -D warnings and fmt clean, cargo ndk check green on arm64 and armv7. Android clippy reports the same 4 warnings as the base commit and no new ones. NOT yet confirmed on glass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 20:15:45 +02:00
enricobuehlerandClaude Opus 5	97b2c01ac1	fix(core/packet): a slice-streamed frame costs its own size, not the whole frame ceiling ... The 0.23.0 slice wire flushes a block every MIN_STREAM_BLOCK_SHARDS, so every ordinary access unit is now opened by a SENTINEL — a header with no totals. The reassembler sized those frames at `max_frame_bytes`, which the QUIC handshake clamps to 8-64 MiB. That was survivable while sentinels were rare (the streamed path emitted one only for an AU exceeding a whole FEC block, ~281 KB); it is not survivable now that every frame is one. Two consequences, both measured: each access unit allocated and ZEROED a multi-megabyte buffer, and the in-flight budget (IN_FLIGHT_BUF_FACTOR x max_frame_bytes) was spent after ~3 concurrent frames — with production geometry, 12 ordinary AUs in flight lost 9 of them outright, every packet dropped before it could be placed. On a link with normal reorder that is a permanent loss storm: frames never complete, the re-anchor gate freezes the picture, and the client begs for keyframes. Only clients advertising VIDEO_CAP_MULTI_SLICE reach this path — Android and the Linux/Windows session client; Apple and the Windows in-process client never did, which is why it read as a platform-specific "video pipeline" fault in the field. A sentinel carries no total but does pin its own block's extent: a slice sentinel by its wire base, a legacy one by its full-K position. Size the buffer to that and grow as later blocks (or the final block's totals) reveal more. The budget is re-checked on growth for the same reason it is checked at open. The same flush also drained `pending` to empty whenever the AU's length was an exact multiple of the shard payload, leaving `finish_streamed` to seal a final block of one zero-padded FILLER shard. Its derived base overlapped the block flushed a moment earlier, retro-validation correctly read that as a lying header, and the whole AU died — one frame in every 1408 on a 1500-MTU link, ~12 s apart at 120 fps, each costing a freeze and a recovery keyframe. A flush now keeps one whole shard back, restoring the invariant `StreamedAu::pending` already documented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 20:15:45 +02:00
enricobuehlerandClaude Opus 5	b6acbd096e	fix(host/vdisplay): waking the PC stops failing the first session ... A woken Windows host refused every connection with "pf-vdisplay driver interface not found", on a box where the driver was installed and running. Resuming re-enters D0 and re-registers the IddCx control interface while the rest of the resume storm is still going. A client reconnecting a second after wake lands inside that gap. `ensure_available` probed exactly ONCE, so it read the gap as a dead driver and answered a device that was seconds from ready by disabling and re-enabling it — then gave the interface 4 s to come back, which a contended post-resume PnP does not meet. The session failed, and the log blamed a missing install. The recovery also could not tell whether it had recovered anything. It ran the whole cycle under `SilentlyContinue` and reported `(Get-PnpDevice).Status` — the DEVICE's status, not the cycle's outcome — so a disable that was REFUSED left the adapter untouched, started, and reading `OK`. That is the reporter's `cycled the adapter device … status=OK` line: a recovery that never happened, announcing success. And a refusal is the expected case here, not the exotic one: reset-pf-vdisplay.ps1 stops the host service first precisely because the host holds the driver's control device open, a step an in-process cycle structurally cannot take. - Distinguish a devnode MID-TRANSITION (interface registered, not started yet, or the open refused) from one genuinely ABSENT. Wait the first out; only the second earns a reload. `Probe` carries the counts. - Report what the reload DID, not what the device looks like afterwards: every failable step is `-ErrorAction Stop` in a `try`, and `pnputil /restart-device` is the fallback for the in-use device that `Disable-PnpDevice` refuses. Failure paths re-enable, so a half-cycle can never strand the adapter DISABLED. - Give the interface 15 s to arrive after a reload, not 4 — under a 30 s hard ceiling so a permanently wedged devnode still fails predictably. - Serialize recovery: N sessions racing in after a wake perform ONE reload, not N interleaved ones. The lock is taken only where no manager lock is held, so the order stays one-way. - Retire the manager's cached control handle when a reload runs, instead of letting the next session discover it via a failed IOCTL. - Surface the real reason. `ensure_available` returns `Result`, so the log names how long it waited, whether a reload ran, and how many interface instances were seen in what state — the detail that would have identified this from the field report's log alone. `VdisplayDriver::open` now shares the wait (brief, no reload) instead of carrying a second, drifted copy of it — that path is also reached by `hw_cursor_capable` mid-handshake, where a reload would be the wrong trade for one capability bool. Windows-gated, so verified with scripts/xcheck.sh (check + clippy -D warnings, --all-targets) and cargo fmt; on-glass wake test still owed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 13:12:54 +02:00
enricobuehlerandClaude Opus 5	362595b20f	fix(vdisplay/kwin): the streamed output declares it mirrors nothing, so a stored replicationSource can't clone a panel into the stream ... KWin stores output configuration per *setup* — the exact set of connected outputs, matched by EDID/connector — in `kwinoutputconfig.json`, and `replicationSource` is one of the fields it saves and restores (`OutputConfigurationStore::storeConfig` / `setupToConfig`). Our virtual output carries a STABLE name on purpose, so once any setup has an entry making `Virtual-punktfunk` a mirror of a physical head, KWin re-applies it to OUR output on every session that reproduces that same monitor set — and only that set, which is why the failure looks environment-dependent: a field report has the stream cloning the panel whenever exactly one monitor is live, and behaving normally the moment the others come back (a different setup key, a different stored entry). A mirroring output is not a desktop. KWin's `applyMirroring` overrides its scale and render offset to the source's, so the stream carries the physical screen's viewport at the physical screen's size instead of the mode the client negotiated. The protocol says the rest out loud on `priority`: "an output may not be in the output order if it's disabled or mirroring another screen" — so the primary assertion this module works so hard to verify silently stops meaning anything too. Nothing we sent ever contradicted the stored value. The topology config enabled our output, took priority 1 and disabled the others, but never stated the one property that decides whether the thing is its own screen. Now it does: `set_replication_source(ours, "")` rides along in the config we already build (free, idempotent — an empty source is exactly what KWin resolves to "mirrors nothing"), gated on management v13 where the request appeared, since wayland-rs does not range-check requests and an out-of-range opcode would kill the connection. `extend`/`auto` issue no topology calls by design — the streamed output is meant to join the desk without rearranging it — but a mirror is not an arrangement, it is a broken source under every topology. So they get `clear_replication_source`, which enumerates and applies ONLY when our output really is mirroring. The device's `replication_source` event is now read, so the state is visible: a mirrored streamed output names its source in a warn instead of leaving "the stream just shows my monitor" as something only the reporter can see. Verified on 192.168.1.25 (Ubuntu, cargo 1.96): `cargo test -p pf-vdisplay` 128 pass (7 in `kwin_output_mgmt`), `cargo clippy -p pf-vdisplay --all-targets --locked -D warnings` clean, `scripts/xcheck.sh linux` clean, fmt clean. NOT yet on-glass — no KDE box here reproduces a stored mirror; the reporter's setup is the real test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-02 11:55:34 +02:00
enricobuehlerandClaude Fable 5	caa47e28e6	fix(client/decode): AV1 hardware decode stops silently opening libdav1d ... avcodec_find_decoder(id) returns the registry's FIRST decoder for the id, and upstream orders the native av1 decoder LAST on purpose ("hwaccel hooks only, so prefer external decoders" — allcodecs.c). All three hardware backends selected by id, so every AV1 session opened libdav1d: a software decoder that silently ignores hw_device_ctx and never calls get_format. Each frame then failed the backend's hw-format guard and the session burned the demotion ladder MID-STREAM — field-logged as 68 Vulkan fails → D3D11VA → 102 fails → software, ~3 s of black — with "hardware decode active" already printed and the D3D11 profile/pool probes all green. H.264/HEVC never hit this only because their native decoders happen to be registered first. Selection is now by capability: find_hw_decoder walks av_codec_iterate and takes the first decoder whose avcodec_get_hw_config advertises the backend's surface via HW_DEVICE_CTX, so a build without a usable hw decoder fails at OPEN in milliseconds and the ladder runs there — the idiom the D3D11 probes already follow. Registry order still wins among capable decoders, so H.264/HEVC select exactly what they always did. The software path keeps the id lookup on purpose: libdav1d is the fastest CPU AV1, and the native av1 decoder has no software path at all. Every decode log now carries the selected decoder's name — decoder="av1" vs decoder="libdav1d" is the whole diagnosis, and no log line said it. The session log names the WIRE codec and drops the FFmpeg id for PyroWave (ffmpeg_codec_id's fallthrough claimed codec_id=HEVC for wavelet sessions that never touch FFmpeg). The CPU lane also stops passing raw PQ off as a tone-map: software-decoded frames deliberately never take the HDR10 swapchain, but a PQ stream there was then shown UNtonemapped (washed out) with no warning — the pq-downgrade warn keys off the swapchain answer — while the Detailed OSD badge claimed the "HDR→SDR" tone-map that only the hardware lane's CSC runs. The presenter now warns once when a PQ CpuFrame arrives, and the badge distinguishes "HDR→SDR (raw)" (no tone-map pass) from the hardware lane's real "HDR→SDR". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:54:43 +02:00
enricobuehlerandClaude Fable 5	652abeb397	fix(host/audio): an unsatisfiable wiring plan waits for an endpoint change instead of hammering ... Field case 2026-08: the display isolate invalidated the only real render endpoint; the mic held the Steam Streaming Microphone, the Speakers were blacklisted, and the capture loop re-ran the full wiring pass — three IPolicyConfig SetDefaultEndpoint writes included — every 2 s for 8+ minutes, retrying a verdict that could never change. - wiring_plan: a plan with no loopback is a typed structural verdict (Wiring::loopback_unsatisfiable + an endpoint-set fingerprint); the dead leftover() tier (byte-identical to real_hw()) becomes a real last resort that accepts ONLY the Steam Streaming Speakers, flagged loopback_last_resort — a known-silent-loopback QUALITY risk, never the cable/VoiceMeeter echo CORRECTNESS risks. excluded_from_loopback stays untouched (judge_default's mid-stream snap-back semantics). - wasapi_cap: an unsatisfiable plan errors ONCE per topology with the render inventory, per-endpoint rejection reasons and only the remedies not already taken, then parks on a cheap enumerate-and-hash poll and re-plans the instant the set changes; transient failures get a real capped exponential backoff (2 s → 60 s, reset on success or set change); a last-resort capture re-plans on any set change and promotes the 30 s zero-packet breadcrumb to warn. - audio_control: the recording default is asserted only when the plan changed or the default drifted — set_default_endpoint fires all three SetDefaultEndpoint roles unconditionally, so the 2 s loop silently stomped any operator recording-device change; the "attach one, or let the host install the Steam Streaming pair" warn (already satisfied in the field case) is replaced by the same diagnosis. Verified: 19/19 wiring_plan tests (native rustc --test and the Linux CI image via docker); both Windows files type-check and clippy clean against wasapi 0.23.0 / windows 0.62.2 for x86_64-pc-windows-msvc via an xcheck-style stub harness (the in-tree target check dies in openh264-sys2's build script on macOS, as scripts/xcheck.sh documents). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:53:36 +02:00
enricobuehlerandClaude Fable 5	48511d1267	fix(abr): probe throughput is measured over the client's receive interval ... The capacity probe divided client-side bytes by the HOST's burst duration — a window wrong on both edges (base snapshotted before the burst reached the host, frozen only when the ProbeResult landed, while the host's clock stops the moment ITS send window closes, before the switch/kernel queue finishes draining toward the client). On a 1 GbE link a 2 Gbps burst target "measured" 1266 Mbps and set an 886 Mbps climb ceiling the link could never carry — permanent for the session, because set_ceiling never lowers. The reassembler now stamps probe-scoped counters (bytes, packets, first/last arrival, monotonic ns) at its FLAG_PROBE routing, so video around the burst contaminates neither numerator nor denominator; the throughput divisor is the client's first→last arrival interval, with the host duration kept as the fallback when fewer than two probe packets arrived. The user-facing speed test shares the corrected computation (ProbeOutcome/PunktfunkProbeResult layouts unchanged; elapsed_ms docs updated to the new semantics). Two guards ride along: - PUNKTFUNK_ABR_MAX_MBPS clamps inside set_ceiling — the one funnel every learned ceiling passes through — so a user cap binds no matter what any probe concludes. - The controller latches decode_cap_kbps when two CONSECUTIVE backoffs carry decode-severe evidence (deep decode excursion or jump-to-live flush) at a similar pre-backoff rate, mirroring host_cap_kbps for the client decoder: a knee below the link ceiling was a permanent 30-60 s sawtooth costing a flush + dropped-frame burst per cycle (1440p120 HEVC field case, knee ~490 Mbps). One spurious flush never latches; the cap re-probes on the CAP_REPROBE_WINDOWS clock, so it lifts when the decoder recovers. Also rights the three stale "3 Gbps" probe-clamp comments (the host constant has been 10 Gbps since MAX_PROBE_KBPS moved). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:53:36 +02:00
enricobuehlerandClaude Fable 5	3e649d372e	fix(capture/stall): the ETW witness testifies in QPC, so compose-silence stops convicting content ... The stall classifier's present witness never worked: the consumer was opened without PROCESS_TRACE_MODE_RAW_TIMESTAMP, so ProcessTrace converted every event's TimeStamp to FILETIME regardless of the session's ClientContext=1 — FILETIME ticks (100 ns since 1601) are ~4 orders of magnitude above QPC, so every ts <= to_q comparison was false. summary() always printed etw=none, window_counts() always returned presents=0/queue_adds=0 while present_history was still true (satisfied by the unfiltered ring), and classify() therefore convicted EVERY compose-silence hole as CONTENT-SILENCE; FRAME-GENERATION — the class the program exists to catch — was unreachable. Two comments asserted the wrong contract ("TimeStamp IS a QPC value"); both now state the real one: ClientContext selects the session clock, RAW_TIMESTAMP is what stops the FILETIME conversion on delivery. Three adjacent defects fixed with it: - summary() and window_counts() each took their own ring lock and their own (Instant::now(), qpc_now()) anchor, with OpenProcess syscalls between the two calls — the prose and the verdict could disagree about the same hole. Merged into window_report(): one snapshot, one anchor, both halves; the summary keeps its 300 ms lead-in, the counts keep the gap-only window, and the etw=/etw_presents=/etw_queue_adds= log fields are unchanged. - present_history/queue_history meant "an event EVER sat in the ring" — satisfied by events arriving after the hole, or by a previous session's leftovers in the never-cleared static RING. Both flags now mean witness LIVENESS: at least one event inside a 5 s LOOKBACK ending at the hole's start, i.e. the witness demonstrably worked before the hole opened. The ring is cleared when a new session starts, so a dead session's events can never pose as the next one's history. - window_counts() accepted only BltQueueAddEntry (1071) as queue history while summary() also took BltQueueCompleteIndirectPresent (1068); either proves the queue witness works, so the merged reader takes both. The windowing math is factored into a pure count_window() (plain i64 tick arithmetic) with unit tests, and the classify() matrix gains the live-witness zero-presents case. Conviction thresholds are untouched. Verified: scripts/xcheck.sh windows clippy (-D warnings, --all-targets) green for pf-frame/pf-win-display/pf-capture/pf-vdisplay; native cargo check green. The new Windows-gated tests type-check but need a Windows box to run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:53:36 +02:00
enricobuehlerandClaude Fable 5	0d004c4680	fix(host/handshake): the 4:4:4 gate names the encoder backend, not the capturer ... capture_supports_444 was an encoder-backend fact (direct NVENC or PyroWave) logged under a capture-ish name — a field report burned real time hunting a capture problem because of it. The 'encode chroma' line now says ingest_chain_supports_444, a requested-but-declined session logs WHICH gate lost, and the console UI's Full chroma explainer names the real requirement. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:53:29 +02:00
enricobuehlerandClaude Fable 5	8d7e273a96	feat(client/present): PUNKTFUNK_PRESENT_MODE gains explicit mailbox and fifo_relaxed arms, and the docs stop guessing ... The env knob silently folded 'mailbox' and every typo into the default arm, FIFO_RELAXED was not reachable at all, and clients/session/README.md claimed the default is FIFO (it is MAILBOX with a FIFO fallback). An AMD-on-Windows client always lands on FIFO because that driver offers no MAILBOX — now documented at the picker and in the docs-site client table, next to the ABR probe/ceiling knobs a field report went looking for and couldn't find. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 09:53:28 +02:00
enricobuehlerandClaude Fable 5	02a5bdb965	fix(gamepad): the virtual DualSense stops demanding a firmware update it cannot take ... The emulated pad's firmware-info feature report (0x20) advertised update version 0x0154 — a 2021-era number. PlayStation Accessories compares it against Sony's latest (0x0630 as of 2026-08) and offers an Update that can only end in "can't complete the update", since the virtual pad speaks no DFU; libScePad titles (Stellar Blade) surface the same nag in-game. A real pad plugged in directly reads up to date, which made the prompt look like punktfunk corrupting the controller. The old value was chosen to keep the kernel and SDL on the flag0 COMPATIBLE_VIBRATION convention, but parse_ds_output has since learned the firmware-≥2.24 COMPATIBLE_VIBRATION2 flag as well, so nothing depends on looking old anymore. Advertise 0x0999 — above anything Sony has shipped and comfortably ahead of their ~yearly cadence — instead of chasing their exact latest, which would resurrect the prompt on every Sony release. Writers that read the version now use the v2 flag; both conventions land in the same rumble plane. Bumped in both copies of the blob (host uhid + Windows driver); the DualSense Edge shares them, and its own versioning (0x0217 latest) sits below the new value too. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 10:24:20 +02:00
enricobuehler	ea469162f9	fix(docs): three doc comments start a markdown list they never meant to ... Windows clippy on the v0.23.0 tag: `doc_lazy_continuation` in crates/pf-client-core/src/audio_wasapi.rs:37. The cause is one line break — `+ wire cost.` begins a line, so the markdown parser reads `+` as a bullet marker and the following line becomes a lazy continuation of that list item. Fixed by reflowing so the `+` is mid-line rather than by taking clippy's suggested indent: indenting would keep the accidental bullet in the rendered docs, which is the actual defect. Same treatment for the two siblings a sweep of every `///` line found, both invisible to the Linux gate for their own reasons: - gamestream/audio.rs:237 — `+ libopus;` at line start, on the cfg(not(linux/windows)) stub, so only a macOS clippy would ever see it. - mgmt/tests.rs:1653 — `404.` at line start IS an ordered-list marker (CommonMark: 1-9 digits + `.`), and it is behind cfg(test), so only an --all-targets run sees it. This is the [[Windows clippy sees what the Linux gate structurally cannot]] shape again: audio_wasapi.rs is cfg(windows), so no amount of Linux CI would have caught it. Verified: a scanner over every .rs doc comment in the tree now reports zero line-initial list markers with an unindented continuation; rustfmt clean (it does not reflow doc comments, so these edits are stable).	2026-08-01 01:30:45 +02:00
enricobuehler	3c509d48c9	feat(core/abi): report_phase earns its version — C ABI 13 -> 14 ... `punktfunk_connection_report_phase` (fa822744, coherence tail 1d31e4c5) and the `PUNKTFUNK_CLIENT_CAP_PHASE_LOCK` mirror const (7cf71dd2) grew the embeddable C surface without moving ABI_VERSION. Every prior additive entry in that doc list bumped it — v3's wake_on_lan, v5's next_rumble2, v8's clipboard block, v13's send_pen — precisely so an embedder can ask punktfunk_abi_version() whether the function it wants to link is there. Left at 13, the one number that answers that question said "no report_phase" about a core that has one. The header was already regenerated with both symbols, so it carried the new surface under the old number; the regen here changes exactly the #define and its doc block and nothing else, which also confirms the committed header was otherwise current. Additive and capability-gated: the host arms on report receipt, the wire grows only PhaseReport (0x32) — a control message an old host never reads — and a strict-prefix append on the 0xCF host-timing tail, so WIRE_VERSION stays 2. No in-tree caller compares ABI_VERSION against a literal; mgmt/tests.rs asserts against the symbol. Verified: cargo build -p punktfunk-core regenerates include/punktfunk_core.h to exactly this diff; punktfunk-core lib suite 134/134; rustfmt clean. The C ABI harness cannot run on this Mac (`ld: library 'opus' not found`, the documented pre-existing local linker gap) — CI's Linux leg is the gate for it.	2026-08-01 00:58:11 +02:00
enricobuehler	951bcec650	Merge remote-tracking branch 'origin/main' into audio/mic-latency-echo	2026-08-01 00:47:50 +02:00
enricobuehlerandClaude Fable 5	f3a39df7b3	test(host/audio): prove a reopen recovered with a live uplink, not one frame ... `reopens_after_push_death` failed about one run in nine, and widening its timeout did not help — the earlier commit blamed the backoff and was wrong. The pump drops whatever queued while it was down: audio from before the device came back is stale, so a fresh instance drains the channel right after opening. The harness counts `opens` from the START of the open, so the moment the test sees the counter move, the pump has not reached that drain yet. The single frame it then sent landed inside the drain window and was discarded exactly as designed, leaving the test waiting for audio that was never going to arrive. So the test now keeps feeding, which is what a real uplink does and what the drain assumes. The sequence advances each time or the de-jitter reads the repeats as duplicates and drops them for a second, correct reason. Production behaviour is unchanged: this was the test asserting something the pump never promised. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:41:07 +02:00
enricobuehlerandClaude Fable 5	4d45a96ff9	feat(encode/windows): sub-frame readback defaults on where the GPU supports it ... Linux parity, validated by the .173 on-glass A/B (no regression; the win goes to clients that actually consume slice-progressive parts): the caps probe now reads NV_ENC_CAPS_SUPPORT_SUBFRAME_READBACK and seeds resolve_subframe with it instead of a hard false, so PUNKTFUNK_NVENC_SUBFRAME becomes the tri-state escape it already is on Linux, and the split×sub-frame arbitration hears the real forced flag for its log severity. The A/B also caught the default path opening every session with a WARN: the submit-time idr_hint missed that NVENC emits the session-opening frame as an IDR regardless of pic flags, so frame 1's early chunks went out unflagged and the divergence check fired at every start. The hint now carries the Linux twin's `opening` term. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:40:58 +02:00
enricobuehlerandClaude Opus 5	0985726415	fix(host,web): an empty update channel stops looking like a broken host ... A channel nobody has published to answers `manifest.json` with a 404, and the check reported that the same way it reports a dead registry or a bad signature: "Last check failed: feed returned HTTP 404". Every host on the stable channel shows it today, because the stable manifest only publishes when someone dispatches `announce` for a release tag — so the first thing an operator sees from the new Updates card is a red failure caused by nothing being wrong. The shared checker now distinguishes the two. `feed::fetch_manifest_blocking` returns a typed `FeedError` instead of a string, and only a 404 on the manifest ITSELF becomes `NotPublished` — a 404 on the detached signature still fails loudly, because that is the half-published pair the manifest-then-signature upload order can produce, and it must stay fail-closed. The host carries that through as `UpdateStatus.not_published`, mutually exclusive with `last_error`. It is benign only while no manifest has ever been seen for the channel: once a check has succeeded, the same 404 means the feed LOST a document it used to serve, which stays an error. The console then shows a plain sentence naming the channel instead of the failure banner, and "None published yet" rather than "Not checked yet". The Linux client makes the same distinction but deliberately NOT the same choice: `--check-update` keeps exiting 1 and keeps `error` set, because its consumer is a shell script and an empty channel is the absence of evidence that this build is current — not a confirmation that it is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:37:56 +02:00
enricobuehler	23f1debe69	Merge remote-tracking branch 'origin/main' into audio/mic-latency-echo	2026-08-01 00:21:24 +02:00
enricobuehlerandClaude Fable 5	10a1863cc7	test(host/audio): give the reopen tests longer than the backoff they wait for ... `wait_until` allowed 200 × 10 ms — exactly the 2 s `backoff_start` the reopen path spends before it can succeed. On a warm, idle machine it wins the race; on a cold binary or a loaded box it does not, and `reopens_after_push_death` failed 3 of ~5 cold runs while gating this branch. CI is always cold. Six seconds costs nothing when the test passes and only delays a genuine failure, so the budget now clears the backoff with room to spare. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:15:54 +02:00
enricobuehlerandClaude Opus 5	6a4ffcb15c	fix(client): HDR stops leaking out of the stream and blowing out the console UI ... The gamepad/console UI looked right on launch, and wrong forever after the first HDR session: connect to an HDR host, disconnect, and the UI came back overblown with wrong colours. The UI is not its own renderer. It is a `pf_presenter::overlay::Overlay` composited into the SAME swapchain the stream used, and it draws plain sRGB with no HDR awareness at all — so the swapchain's colorspace decides how its pixels are read. `present` switches SDR↔HDR10 from the FRAME's colour signalling, and a UI-only present is `FrameInput::Redraw`, which carries none: the mode block is skipped entirely and nothing ever hands HDR10 back. The UI's sRGB mid-tones were then emitted as PQ code points, i.e. near-peak nits. `leave_hdr` drops back to SDR, called where the UI-only present already happens and gated on the existing `browse_idle` — Browse mode with no live connector, i.e. the UI owns the screen. That covers every route back to the UI rather than just the Ended/Failed arms, and it is guarded internally so idle iterations stay free. It also bails when minimized, which is load-bearing rather than an optimization: `recreate_swapchain` keeps the old swapchain at a zero extent, but `set_hdr_mode` would by then have rebuilt the CSC and overlay pipes against the SDR format — mismatched against live HDR10 images. `present` early-returns on a zero extent above its HDR block, so this was unreachable until a caller outside `present` existed. Deliberately not applied to the `resize_scrim` arm of the same present: that scrim is a mid-stream gap in a session that is still HDR, and flipping there would rebuild the swapchain twice per resize. Does not address the adjacent case: an overlay drawn DURING a live HDR session (the stats HUD, the resize scrim) is blown out the same way. That needs the overlay to PQ-encode when `hdr_active`; dropping to SDR is only correct here because the console UI shows exactly when no stream is live. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:08:38 +02:00
enricobuehlerandClaude Fable 5	a7143a6510	Merge origin/main into audio/mic-latency-echo ... Main moved through the same surfaces while the audio work was in flight, so three files needed hand-resolution: - clients/windows/src/app/settings.rs — main gave Windows its speaker and microphone endpoint pickers, the gap this branch could only report. Both keep their rows: the pickers, then Echo cancellation, and the microphone description keeps the sentence naming the mute chord. - crates/pf-console-ui/src/screens/settings.rs — both sides grew the couch row list. Main's seven new rows and Echo cancellation are all reachable in Gaming Mode; the count is 22 and the rationale comment names echo cancellation among the fields that would otherwise be unreachable there. - crates/pf-presenter/src/run.rs — both sides added a stats test at the same line. Both are kept. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 00:04:34 +02:00
enricobuehlerandClaude Opus 5	43a631ea9c	fix(clients): a host that re-keys stops locking the client out for good ... Reinstall a host, wipe its ProgramData, or otherwise regenerate its identity, and the desktop clients refused it forever: "Host identity rejected — wrong fingerprint, or the host requires pairing", including immediately after a successful re-pair. There was no way out of it from the UI — the host list showed two cards for one address and forgetting the wrong one was a guess. `KnownHosts::upsert` matches on the FINGERPRINT, which is what lets a host that moved address keep its record and everything the user set on it. A host that changed identity matched nothing, so pairing appended a SECOND record for an address that already had one, and `find_by_addr` returned whichever came first in the file — the dead one, every time. Trust decisions (PIN ceremony, delegated approval, TOFU accept, headless pair — all funnelled through `persist_host`, plus the Windows shell's two direct upserts) now go through `upsert_trusted`, which retires any OTHER record for that address. Retired means DELETED, not demoted: a record whose certificate the host no longer holds cannot connect, so keeping it only reproduces the two- cards-one-address confusion this fixes. What described the box rather than the identity — its MAC, its OS chain, the bound profile, the pinned cards, when it was last used — moves onto the record that survives, so a reinstall doesn't quietly cost the user their setup. What described the dead identity does not: `paired` and `clipboard_sync` are decisions about one specific certificate and have to be made again for a new one, and the retired record's stable id stays retired (a deep link written from it falls through to the `host=` recovery the link grammar already specifies). Only trust decisions may retire a record. The wake path's address re-key and every learn-from-advert path stay on plain `upsert`: those are driven by unauthenticated mDNS, and letting an advert delete a saved host by claiming its address would trade this bug for a much worse one. A plain reconnect still fails closed on a pin mismatch — nothing here changes what the pin is checked against. Stores that already hold the duplicate recover on the next connect, not at load: which of two records is live isn't knowable at load time and guessing wrong would throw away the good one. Instead `find_by_addr` stops being positional — a real fingerprint beats a placeholder, and among real ones the newest trust decision wins, since records are only ever appended by one. The next successful pair then cleans the store up for good. Every lookup that picks a pin or a per-host decision for a connect now goes through it (the session's pin and clipboard read, the deep-link resolver, orchestrate's plan, both speed tests, the CLI's --wake and --library, which had also been ignoring the port), and an advert's learned MAC/OS lands on the record it identified rather than on a stale namesake that merely came first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-01 00:00:49 +02:00
enricobuehlerandClaude Opus 5	6af067da2d	fix(client): the bottom rows stop smearing — the decode pool is taller than the picture ... A user's 1080p stream repeated its last row of pixels over the final few rows, so the image looked stretched at the bottom. The Vulkan-Video CSC pass sampled the decoded planes with the fullscreen triangle's normalized 0..1 UVs, but its render target is built at the CROPPED frame size. Those are not the same rectangle: FFmpeg sizes the decode pool from `avctx->coded_*`, and H.264 codes `16 * mb_height` — so a 1080-row picture decodes into a 1088-row pool. Destination row 1079 sampled source row ~1087.5, dragging the 8 alignment rows into view and squashing the picture 0.7%. Encoders fill that padding by replicating the last picture line, which is why it reads as a smeared bottom row rather than garbage. Confirmed on glass (.173, RTX, H.264 1080p, vulkan-video): Vulkan Video first frame width=1920 height=1080 pool_w=1920 pool_h=1088 `VkVideoFrame` now carries the pool extent and `record_csc` takes a `uv_scale`, written to the shader's `params.zw` — which the CSC shader already reserved for a use like this. The chroma cositing offset is unchanged and stays correct: `textureSize` reports the pool width, which is the space the scaled UV is already in. Only the Vulkan-Video path passes a scale below 1.0. D3D11VA already clamps this in its VideoProcessor blit (the same bug, seen as a green bar there because DXVA padding is uninitialized rather than replicated); dmabuf imports its planes at the crop over the real stride; PyroWave allocates its ring at exact stream dims. Apple and Android crop at the OS layer. Every other call site passes [1.0, 1.0], so the change is inert there. Also adds a one-time first-frame layout log mirroring the D3D11VA one, so the frame-vs-pool gap is visible in the field instead of having to be re-derived from FFmpeg internals. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-31 23:40:33 +02:00
enricobuehlerandClaude Fable 5	7ec3107b4a	feat(client): the mic has an off switch, and echo cancellation has a switch too ... Ctrl+Alt+Shift+V mutes and unmutes the microphone mid-stream — V for voice, since M and S were taken. The uplink keeps running while muted: `MicStreamer::spawn` takes a shared AtomicBool the capture callback reads every quantum, and a muted callback drains whole frames and sends nothing. Stopping the stream instead would have re-primed the device buffers and, on Linux, re-run source selection on every unmute — a second of glitch for a key people press mid-sentence. The sequence counter deliberately does NOT advance while muted, so the host sees one continuous sequence with a pause rather than a gap the size of the mute, which its de-jitter would try to conceal frame by frame (its 600 ms stale-flush covers the rest). The mute lives on SessionHandle as a MicControl with two flags, not one: `live` is raised by the pump only once the uplink is actually running, so a session with the mic off in Settings — or whose capture device wouldn't open — reports "nothing to mute", the chord says so in the log, and no indicator appears. Per session, never persisted. Muted state draws as a persistent "Microphone muted" badge in the stream's top-right corner, off `FrameCtx::mic_muted` rather than the stats text: it has to be there with the stats overlay Off, which is where most people leave it. The Detailed mic line still reads throughput, so it simply falls to zero — the badge is what answers "am I muted". Echo cancellation stops being an env-only lever. `Settings::echo_cancel` (default on, `#[serde(default)]` so every stored file loads with it on) now gates the same hooks PUNKTFUNK_NO_AEC gated: the echo-cancelled PipeWire source preference and WASAPI's Communications stream category. The env var still wins, one-way — it can only turn AEC off, never back on — and both `aec_enabled` helpers say so. The row ships in the GTK, WinUI and console settings, under the microphone toggle and greyed out while it is off, matching what Apple and Android shipped in wave 1. SettingsOverlay grows `echo_cancel` as a first-class field — apply, absorb, clear, is_empty — instead of riding the `extra` passthrough, where `clear_override("echo_cancel")` answered false. The JSON key is the one Apple and Android already write, so one catalog round-trips through all three. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 23:07:30 +02:00