23 Commits

Include renames

Author	SHA1	Message	Date
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	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	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 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 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	2ce0bea830	feat(client): desktop phase-locked capture, a real display volume on Windows, and the console's missing rows ... The cross-platform half of the gap sweep: * Phase-locked capture reaches the DESKTOP clients (it shipped on Apple/Android only, though the desktop presenter has the best latch signal of all — true on-glass stamps via VK_KHR_present_wait). The presenter's 1 Hz fold publishes a latch grid (anchor = last on-glass instant; period = min positive present spacing, capped by the display mode's refresh so an arrival-paced sub-panel-rate stream can't claim a slower grid); the session pump folds every AU's arrival stamp against it with the SHARED `phase::circular_latch` statistic and sends the ~1 Hz PhaseReport (1 ms uncertainty — reference-client parity). The cap is advertised only when present timing is real (`VulkanDecodeDevice::present_timing` gates `SessionParams::phase_lock`), and the host's applied grid offset from the 0xCF tail is logged so an on-glass run can watch the controller engage. * `Hello::display_hdr` stops being hardcoded `None`: Windows reads the panel's colour volume from DXGI (`IDXGIOutput6::GetDesc1`, the `--window-pos` output else the primary, advanced-color outputs only, gated on the HDR setting) so the host's virtual-display EDID matches the real glass. Linux keeps the EDID defaults — no portable Wayland/X11 query exists — and the comment now says exactly that. * The console settings screen (the ONLY editor in Gaming Mode) learns the rows it was missing: render scale, full chroma 4:4:4, invert scroll, capture system shortcuts, fullscreen-on-stream, auto-wake and the game-library toggle. * A spec-run session's device picks (GPU adapter, speaker, microphone) now come from the `--resolved-spec` instead of a raw Settings load — the last store read the spec path still owed (§5), and what would make those fields profileable. * `session_args()` documents why the GTK/CLI spawners pass no `--window-pos` (Wayland exposes no global coordinates to read and SDL can't apply them). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 22:05:24 +02:00
enricobuehlerandClaude Fable 5	74863c96b3	feat(client): 4:4:4 can stay on hardware, and the overlay says what you actually got ... Two halves of the same honesty problem (client-gaps handoff items 1+2, done together as the handoff asked). The presenter learns full chroma: `vkframe_plane_views` accepts the 2-plane 4:4:4 pool formats (8-bit, and the 10-bit 3PACK16 sibling) — what NVIDIA's Vulkan Video reports for HEVC RExt decode — with the accepted set extracted into `vkframe_plane_formats` and pinned by a decision-table test. The CSC shader needed nothing: its 4:2:0 siting correction already self-disables when the plane widths match. The VAAPI leg gets the same treatment (NV24 in `drm_fourcc_for` and the dmabuf import, full-size chroma plane), and the Vulkan decoder's sw-format gate admits NV24/P410. 3-plane 4:4:4 stays rejected — it needs a third CSC binding — and demotes cleanly like every other unsupported format. Design call (the handoff's fork, argued here as requested): (B)+(C), not (A). No capability probe gates VIDEO_CAP_444 — software decode is the guaranteed display floor on both OSes (swscale → RGBA), the decoder ladder demotes on its own, and a probe-gated bit would turn the switch inert on exactly the boxes that rely on the fallback. What (A) wanted from a prediction, the overlay now delivers as ground truth: The Detailed tier prints the encoder's target next to the measured rate — `19.4 Mb/s · target 20 Mb/s (auto)` — and the resolved chroma, `4:4:4→4:2:0` when the host declined the ask (mirroring `HDR→SDR`). The target is live: `NativeClient::current_bitrate_kbps()` mirrors every BitrateChanged ack, so an Automatic session's ABR re-targets are visible as they move. This is the figure whose absence let the settings-drop bug (9c5af8d7) ship four releases — measured goodput alone cannot distinguish "the encoder is capped at 20" from "my 200 Mb/s grant met a cheap scene". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 21:21:10 +02:00
enricobuehler	65cd388a52	fix(presenter,core): close the last of the proof-lint hole — the Vulkan contract, stated once ... pf-presenter's 120 sites are `ash` calls almost without exception, so 120 independent arguments would have been 120 restatements of the signature — the exact noise this program exists to remove. They get the `abi.rs` treatment instead: the Vulkan contract stated once in `lib.rs`, each site naming which of three shapes it is. The three are not equal, and separating them is the point. CREATE and RECORD carry no real precondition — the device is owned, the builders are locals, nothing executes until submit. DESTROY does: the GPU must not still be using the object, and that is established by the path (a fence wait, a `queue_wait_idle`, a retired swapchain), not by the call. Those sites say so, because getting it wrong is a use-after-free no type catches. The contract also tells the next person that a block outside the three shapes needs a real proof, and that writing "as above" is the signal it doesn't belong in them. punktfunk-core's Windows half is finished here too: `qos_windows.rs`'s `GetLastError` reads (called before anything can reset the thread's error slot) and `udp/windows.rs`'s control-message write, whose argument is that `ctrl` is sized by `WSA_CMSG_SPACE(4)` — computed two lines up — so header plus payload cannot run past it, and `write_unaligned` is used because `WSA_CMSG_DATA` offers no alignment guarantee. ⚠️ THE WINDOWS BLIND SPOT BIT A THIRD TIME. A Linux measurement put this crate pair at 113; the real number was 129 — `d3d11.rs`, `win32.rs`, `qos_windows.rs`, `udp/windows.rs` are all `cfg`-hidden. Every crate in this sweep had to be finished on .47 after being "done" on .21. For a cross-platform crate the Linux number is a lower bound, never the answer. All three crates now deny `undocumented_unsafe_blocks`, which was the goal: it applied to 8 of 11 crates carrying unsafe, and the three exempt ones held 381 items between them — including the C ABI surface and the presenter. Verified: Linux .21 fmt + both CI clippy steps rc=0; Windows .47 all four closed crates clippy `-D warnings` rc=0 plus the full Windows CI clippy set and pf-capture's tests. Only small crates remain unguarded (75 items total, largest 26).	2026-07-29 08:48:42 +02:00
enricobuehlerandClaude Opus 5	e5e68f1d24	feat(presenter): DRM card selection + a usable kmsdrm swapchain error ... Both come straight out of the first compositor-less bring-up (P3), on a two-GPU box: PUNKTFUNK_DRM_CARD=<n> pins SDL's KMSDRM device index. SDL enumerates /dev/dri/card* and takes the first it can open, which is regularly the wrong one: it chose the card a live compositor already held DRM master on and died at swapchain creation, while the idle card with the connected display sat unused. Kept an explicit operator choice rather than auto-detection — deciding "is this card already mastered" needs the very ioctl that taking master IS, so any in-process guess would be fragile. The swapchain error now carries what to actually check. "vkCreateSwapchainKHR: Initialization of an object has failed" is useless to someone bringing up a kiosk; on the kmsdrm backend it now names the pinned card and lists the three real causes in order (no connected connector / another DRM master / NVIDIA). Empty on every other backend, where it would be noise. The NVIDIA note is measured, not guessed: on NVIDIA proprietary + kmsdrm, Vulkan enumerates the GPU AND the display (VK_KHR_display reports the connected HDMI connector) and still fails — as root, with nvidia_drm.modeset=Y, on a card no compositor was using. Not permissions, not DRM master; their direct-display path wants the display leased via vkAcquireDrmDisplayEXT and SDL's kmsdrm surface path does not do that. Plan: punktfunk-planning design/embedded-arm64-client.md §P3 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Opus 5	b7cea71bbd	fix(presenter): type the Vulkan extension pointers as c_char, not i8 ... `char` is signed on x86_64 but UNSIGNED on aarch64, so the hardcoded `Vec<*const i8>` compiles on every desktop target and then fails to match ash's `&[*const c_char]` when cross-compiling the client for ARM. Found by the aarch64 cross-build spike (punktfunk-planning: embedded-arm64-client.md) — the only portability defect in the client stack; nothing else in the client crates assumes an architecture. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 14:32:45 +02:00
enricobuehlerandClaude Fable 5	49c6dd00c9	fix(presenter): CPU frames never take the HDR10 passthrough surface ... Software decode uploads swscale RGBA with no CSC/tonemap pass. On the new desktop-compositor HDR10 surfaces (GNOME 48 / Plasma 6 + Mesa >= 25.1 offer ST2084 even on SDR desktops) that sRGB-encoded content was composed as PQ — the field-reported psychedelic picture (Fedora clients decode HEVC in software because stock Mesa strips it; reproduced + fix live-validated on GNOME Wayland: mode-0 soup -> HDR→SDR washed-out-but-correct). The CPU lane keeps the SDR swapchain and its known untonemapped-PQ gap; a real PQ→sRGB pass for CPU frames is the follow-up. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	da134ad045	feat(presenter): PUNKTFUNK_HDR10=0 refuses the HDR10 swapchain (SDR tonemap pin) ... GNOME 48 / Plasma 6 with Mesa >= 25.1 now offer HDR10_ST2084 surfaces even on SDR desktops, silently flipping PQ streams into the mode-0 passthrough lane — previously unreachable on desktop compositors and never validated there. The hatch pins the shader tonemap for diagnosis and as the field escape. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	40c2f68231	feat(client): device-pick plumbing — GPU enumeration + audio endpoint targeting ... The Settings GPU pick existed (adapter → PUNKTFUNK_VK_ADAPTER) but no Linux shell could enumerate anything to pick: the GTK shell deliberately links no Vulkan. pf_presenter::vk::list_adapters() reads the physical devices' marketing names (no surface, discrete first, deduped — the name is the whole match key in pick_device), surfaced as `punktfunk-session --list-adapters`. Audio gets the same treatment for the new speaker_device/mic_device settings (PipeWire node.name; empty = default): session main maps them onto PUNKTFUNK_AUDIO_SINK/SOURCE — a hand-set env still wins, like the adapter — and the playback/mic streams pass them as `target.object` (raw key: the keys::TARGET_OBJECT constant is feature-gated on a newer libpipewire than we require). pf_client_core::audio::devices() is the registry roundtrip the pickers read, exposed for debugging as `punktfunk-session --list-audio`. The WASAPI leg (Windows endpoint IDs) is still to come; the fields are ignored there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:32:38 +02:00
enricobuehlerandClaude Fable 5	1ef0229bd9	feat(client/windows): PyroWave decode + surface it in the GUI codec picker ... The decoder was gated to Linux because, when it landed, the Windows client still had its own in-process WinUI/D3D11 presenter and the PyroWave present path there was an open question. That client has since been retired: Windows now spawns the SAME Vulkan session presenter as Linux, and the decoder is plain Vulkan compute on the presenter's device (no fds, no dmabuf, no D3D11 interop), so the question that gated it answered itself. pyrowave-sys already builds on Windows too -- the Windows HOST encoder ships on it. So this is a port by un-gating: every cfg(all(target_os = "linux", feature = "pyrowave")) becomes any(linux, windows) -- decoder module, backend variant, Decoder::new_pyrowave, the CODEC_PYROWAVE advertisement, the session pump's opt-in/build/label arms, and the presenter's planar CSC pass. No new code. Then offer it in the Windows GUI, which is what prompted this. It stays preference-only (resolve_codec never auto-picks it) and a host or device that can't do PyroWave just falls back down the ladder to HEVC. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 19:06:06 +02:00
enricobuehlerandClaude Fable 5	fb8deb31a5	feat(client): HDR pass-through on the D3D11VA path ... A PQ stream on the D3D11VA backend was always tone-mapped to sRGB by the VideoProcessor — with D3D11VA now auto's first choice on Intel (40030e90), Intel Windows users would have lost HDR entirely. When the presenter can import an RGB10A2 D3D11 texture AND offers an HDR10 swapchain (the new VulkanDecodeDevice::d3d11_hdr10 probe), the hand-off ring switches to RGB10A2 and the VideoProcessor does a pure colorspace conversion (YCbCr G2084 -> RGB G2084, no tone mapping); the emitted frame carries PQ/BT.2020 color, so the presenter flips its HDR10 swapchain and video image exactly as it does for Vulkan Video PQ frames, and the blit passes the PQ values through untouched. SDR-only paths keep the tonemap-to-sRGB BGRA8 ring; in-band PQ flips rebuild the ring like a resize (generation-bumped). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 14:19:35 +02:00
enricobuehlerandClaude Fable 5	188edde2b3	feat(pyrowave): Windows host HDR + 4:4:4, Rust client HDR present ... Phase 3 of design/pyrowave-444-hdr.md. A PyroWave session now negotiates HDR (10-bit) and 4:4:4 on a Windows host exactly like HEVC/AV1, and the Linux client presents it through the real HDR10 path. Host (Windows): BgraToYuvPlanes becomes mode-aware — SDR/BGRA and HDR/scRGB variants at half- or full-res chroma. The HDR passes reuse HdrP010Converter's exact colour math (scRGB -> PQ BT.2020 limited studio codes, verified by hdr_p010_selftest) but write P010-style MSB-packed codes into two separate shareable R16_UNORM/R16G16_UNORM textures; chroma keeps the pyrowave family's centre-sited 2x2 box. idd_push pins the composition to the NEGOTIATED depth (SDR sessions force advanced color off as before; 10-bit sessions enable it and ride the FP16 ring), and the descriptor poller re-asserts that state instead of following display flips the fixed-format encoder can't. The encoder imports 8/16-bit planes per session and stamps the sequence header's BT.2020/PQ/matrix bits on HDR (stamp_color_bits, extending 574e3e4e's range stamp); supports_10bit/can_encode_10bit/can_encode_444 gates open (HDR Windows-only — Linux capture has no HDR source). Client: the plane ring becomes R16_UNORM for 10-bit sessions (with a STORAGE_IMAGE format probe), the planar CSC pass joins the HDR10 swapchain rebuild (set_hdr_mode previously destroyed it without rebuilding — latent), st.hdr follows frame.color.is_pq(), and the planar push constants carry depth-10 MSB-packed rows + the PQ tonemap mode, identical to the NV12 arm. Verified: .173 (RTX 4090) deploy-config clippy + fmt + wire tests + the extended pyrowave_win_smoke (10-case {SDR,HDR}x{420,444} matrix incl. R16 imports and header stamps); .21 (RTX 5070 Ti) clippy across 4 crates, host 186 tests, client/presenter/encode tests, both Linux GPU smokes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 13:21:06 +02:00
enricobuehlerandClaude Fable 5	aedee2a4e3	perf(latency): tier-0 attribution + tier-1 send-path levers from the latency plan ... design/latency-reduction-2026-07.md T0.1/T0.2/T1.2/T1.3: - T1.2 rate-capped front-loaded pacing: the paced overflow's budget is now min(0.9x slack, overflow wire time at ~3x the live encoder bitrate) (PUNKTFUNK_PACE_FACTOR, 0 = legacy deadline-only spread). A 300 KB-1 MB frame's tail leaves in ~2-5 ms instead of smearing across ~15 ms at 60 fps; GameStream schedule byte-identical (pins unchanged). - T1.3 data-first wire order: packetize emits every block's data shards before any parity (per-block parity pools keep all blocks' parity alive for the second pass), so lossless completion stops waiting behind the parity tail. EOF = last emitted packet; receiver already order-agnostic. - T0.1 staged 0xCF: HostTiming gains an append-extensible per-stage tail (queue/encode/pace us; seal+channel-wait derived as residual) - no cap bit needed, old peers read the 13-byte prefix. Joined client-side into Stats::host_{queue,encode,xfer,pace}_ms, the OSD detailed tier, and the probe's report. - T0.2 true on-glass present timing: VK_KHR_present_id/present_wait enabled when supported; a PresentTimer waiter thread resolves each present id to real visibility, replacing the submit-time display stamp (which undercounts by up to a refresh and hides a silent-FIFO standing queue). Validated on .21: core 185 + host 185 tests, pf-presenter 19, clippy -D warnings across all five touched crates; loss-harness recovery curve unchanged; C ABI harness round-trips. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:13:08 +02:00
enricobuehlerandClaude Opus 4.8	61118cbdd4	refactor(presenter/W8): split vk.rs into vk/ directory module ... Break the 2513-line pf-presenter/src/vk.rs into a vk/ directory module (mod.rs + 6 concern submodules), keeping ALL type definitions in vk/mod.rs so every submodule (a descendant of vk) sees the Presenter/OverlayPipe/etc. private fields with no field bumps: - vk/setup.rs : Presenter::new + device/format/present-mode selection - vk/present.rs : the per-frame present path (present + CSC record + AVVkFrame sync) — HOT PATH, moved whole - vk/reconfig.rs : swapchain recreate/resize + HDR reconfiguration - vk/resources.rs : video-image/staging (re)build + Retired-frame destruction - vk/overlay_pipe.rs: the presenter-side overlay composite pipeline - vk/gpu.rs : memory allocation, image barriers, geometry helpers (+ tests) vk/mod.rs keeps FrameInput/Presenter/OverlayPipe/VideoImage/Staging/Retired/HwCtx* + the public accessors + Drop. Methods/free-fns a sibling submodule calls became pub(super) (~18); zero field bumps, zero re-exports (Presenter/FrameInput never leave mod.rs). lib.rs unchanged (`pub mod vk;` resolves to vk/mod.rs). The moved overlay shader include_bytes! gained one `../` for the deeper dir. Pure move; no behavior change; the hot present path keeps only static pub(super) calls (inlinable). Verified both platforms: Linux (home-worker-5) clippy -p pf-presenter (--all-targets -D warnings) + test; Windows (winbox, ASCII CARGO_HOME) clippy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 14:39:36 +02:00