25 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Fable 5	33121ece4d	chore(kwin-composite): TEMP blend-path probes — DROP BEFORE MERGE ... Rate-limited journal logging bracketing the silent segment of the Linux composite path: what overlay (if any) the encode loop's composite arm hands the encoder, and whether the NVENC cursor-blend kernel launches and with what geometry. On-glass (KWin leg) the blend module loads yet the composite cursor stays invisible — these two probes attribute it to no-overlay / stripped-en-route / kernel-draws-nothing. The module-loaded INFO line is permanent (success must be as attributable as failure); everything else in this commit is temporary. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	4436c7fb61	fix(host/stream): composite mode re-blends the LIVE cursor on repeat ticks ... The frame-attached overlay is the pointer position at the last damage frame; repeats re-encoding a static desktop froze the blended cursor between redraws — on-glass the composite-mode cursor stuttered while window drags (constant damage) were smooth. Refresh the repeat's overlay from Capturer::cursor each tick so pointer-only motion re-blends at tick rate — the bandwidth the pre-channel embedded mode already paid. Linux only: the Windows capturer composites internally and its frames must never carry an overlay a blend path would double-draw. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Fable 5	c29186bd1a	fix(host+vdisplay): a mode-switch replacement display inherits the group topology ... The resize rebuild creates the new virtual display BEFORE retiring the old one (create-before-drop), so the registry saw a live same-backend sibling — its own dying predecessor — and told the backend it was not first in group. Mutter then skipped the Primary/Exclusive apply ("joining an existing display group — extending") and the retiring owner took the topology with it: every resize silently demoted the virtual output to an extended, shell-less desktop. Thread the superseded pool gen through acquire so the replacement establishes topology, and stop counting kept (Lingering/Pinned) entries as demoting siblings — no session owns them, so there is no live desktop to clobber. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	b50e4767de	fix(windows/cursor-flip): flag + forced same-mode re-commit — the working un-declare ... The empty-caps un-declare is REJECTED by IddCx (STATUS_INVALID_PARAMETER, on-glass driver 9.9.0722.1407) — there is no un-declare DDI. The composite flip now works with the only lever the OS gives us: every mode COMMIT reverts the path to the software cursor, and the driver skips its per-commit re-declare while cursor_forward_on is off. So: - driver: disable stores the flag only (no DDI call); enable still declares immediately against the live worker's event. - host capturer: after a successful disable flip, force a same-mode re-commit (win_display::force_mode_reenumeration) — DWM composites the pointer from the very next commit; the swap-chain flap is the class the driver's preserved-publisher machinery already rides out. - state now survives re-arrivals end-to-end: the capturer caches the APPLIED state (cleared on every channel (re)delivery, which re-created driver entries need — their flag defaults to declared), and the stream loop re-applies every tick instead of edge-gating (steady-state cost: one Option compare). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	92761813a9	feat(core+host+driver+client): mid-stream cursor-render flip — host composites in the capture model ... The cursor channel excluded the host pointer from the video for the whole session, but the client only draws it under the DESKTOP mouse model — flipping ⌃⌥⇧M to capture mid-stream left the session pointer-blind (user-found). The fix makes render ownership LIVE state: - wire: CursorRenderMode 0x51 (client→host, control stream) — client_draws: true = desktop model (host excludes + forwards), false = capture model / released (host composites, full fidelity — DWM on Windows incl. real XOR inversion, encoder blend on Linux). Sessions start client_draws=true (the pre-message behavior). - host: control task stores the flag; the encode loop edge-detects it — forwarding + frame.cursor strip while the client draws, quiet forwarder + overlay-into-blend while composited. SessionPlan now grants blend CAPABILITY wherever the capture has a pointer (dropping the !cursor_forward gate) so the composite side needs no encoder rebuild; per-tick frame.cursor decides what is drawn. - Windows: Capturer::set_cursor_forward → retained IOCTL_SET_CURSOR_FORWARD sender (proto v6) → driver (un)declares the IddCx hardware cursor on the LIVE monitor. Un-declare re-issues the setup with EMPTY caps (candidate mechanism — the DDI has no documented un-setup); resetup-on-commit is skipped while off, so a mode commit's software-cursor default is the fallback path. Failure against a pre-v6 driver logs and keeps declared-at-ADD behavior. - SDL client: one edge-detected reconciler at the cursor pump site — desktop-active = client draws; capture model or released = host composites. Covers the chord, the M3 auto-flip, and engage/release. - C ABI v12: punktfunk_connection_set_cursor_render (additive; wire version unchanged — pre-§8 hosts ignore the unknown message type). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	3a34440a6b	feat(windows): IddCx hardware-cursor channel — remote-desktop sweep M2c ... Brings the cursor channel to Windows hosts. The pf-vdisplay driver declares an IddCx hardware cursor for sessions that negotiated cursor-forward — DWM then EXCLUDES the pointer from the IDD frame and delivers shape/position out-of-band, into the same CursorOverlay → forwarder → wire → client pipeline the Linux portal path uses. - pf-driver-proto v5 (additive, host floor stays 3): AddRequest's spare tail becomes hw_cursor (same size/offsets); IOCTL_SET_CURSOR_CHANNEL delivers a host-created CursorShm section (64-byte seqlock header + 256² shape buffer, layout pinned + tested). No event crosses the boundary — the host polls at encode-tick pace. - driver: wdk-iddcx grows the two cursor DDI wrappers; a per-monitor cursor worker (event wait → QueryHardwareCursor → seqlock publish) starts only when BOTH the ADD asked and the channel arrived, so a failed delivery leaves DWM compositing as today. Shape bytes ship raw (BGRA/masked + pitch); the host converts. - host: the section rides the existing sealed-channel broker (least- privilege dup, remote reap on failure); IddPushCapturer::cursor() seqlock-reads → CursorOverlay (BGRA→RGBA, masked-color approximation, desktop→frame origin shift, per-shape conversion cache). New Capturer::cursor() trait hook — the encode loop prefers it over the frame-attached overlay because hardware-cursor moves produce NO new frame on a static desktop. hw_cursor survives the re-arrival resize (carried on the manager's Monitor). - negotiation: cursor_forward grows the Windows arm (client cap ∧ driver proto ≥ 5, probed once via the control device); SessionPlan carries cursor_forward → OutputFormat.hw_cursor. - drive-by: wdk-probe's two pre-existing same-type casts (clippy) and pf-vdisplay's stale spike-test refs (crate::win_display moved to pf-win-display; tracing-subscriber was never a dep) repaired. Verified: proto tests on Mac AND MSVC (15/15 incl. the CursorShm layout pin); clippy -D warnings for proto/frame/capture/vdisplay/host on Linux (.21) and native Windows (.173); the DRIVER workspace clippy -D warnings green against the real WDK 10.0.26100 bindgen (DDI names, enum variants and IDARG layouts all bind). On-box driver deploy + on-glass validation follow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	c3cbffe662	feat(host+client): host-driven mouse-model flip — remote-desktop sweep M3 ... The full Parsec model: launching a game from a desktop session flips the client into captured relative automatically, and back — no chords. - Capture overlay now distinguishes 'hidden' from 'no cursor yet': CursorOverlay grows a visible flag, overlay() returns Some whenever a bitmap is known (the encode loop strips invisible overlays after forwarding so no blend path ever draws one; the CPU composite guarded on visibility already). - Host forwarder maps it onto the reserved wire bit: visible ⇒ VISIBLE, hidden-but-known ⇒ RELATIVE_HINT (an app grabbed/hid the pointer), never any hint before the first bitmap — a cold start can't flip a desktop session into capture. - Presenter: edge-triggered auto-flip on hint changes via the new Capture::set_desktop (chord semantics untouched); a manual ⌃⌥⇧M sets an override latch that holds until the HOST's intent next changes, so the hint never fights the user. Leaving relative warps the local cursor to the host's last pointer position through the new content_to_window inverse-letterbox mapping (unit-tested against finger_to_content) — the hand-back is seamless. Verified on .21: fmt + clippy -D warnings + tests (presenter 20 incl. the inverse-mapping roundtrip, host 245). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	4a01bc4463	feat(core+host+client): cursor channel — remote-desktop sweep M2a+M2b ... The host cursor stops riding the video and becomes a real OS cursor on the client (the Parsec/RDP model): pointer feel no longer pays the capture→encode→network→decode→present round trip. Wire (M2a): - Hello grows a client_caps trailing byte (CLIENT_CAP_CURSOR) after the fixed display_hdr block — presence disambiguated by remaining length, which caps the post-HDR tail at 27 bytes (documented); Welcome answers HOST_CAP_CURSOR (capable-and-asked, the 444/clipboard precedent). - CursorShape (0x50, control stream): serial + dims + hotspot + straight RGBA, ≤120px/side so the u16 frame always fits (128² would overshoot); client caches by serial — re-showing a known shape costs 14 bytes, not a bitmap (RDP pointer-cache for free). - CursorState (0xD0 datagram): serial + visible/relative_hint flags + position, sent once per encode-loop tick — latest-wins, self-healing under loss, no refresh timer. relative_hint is reserved for M3. - Client core: two new planes (control-task + datagram-task arms) → next_cursor_shape/next_cursor_state; connect() grows client_caps (C ABI passes 0 until the v11 cursor poll fns exist). Host (M2b, Linux portal only): - handshake::cursor_forward is THE predicate (client asked ∧ Linux ∧ compositor ≠ gamescope) — Welcome bit and session wiring both read it. - SessionPlan.cursor_blend goes false for a forwarding session; the encode loop ticks a CursorForwarder every iteration: shape-serial diff → control-task bridge (mirrors probe_result), state datagram → conn. - CursorOverlay/capture CursorState carry the hotspot through (nearest-neighbor downscale backstop for XL cursors, unit-tested). Presenter: - CursorChannel drains both planes per loop iteration; shapes become SDL color cursors (from_surface + hotspot), applied while the desktop mouse model is engaged; visibility follows the host; capture/released hands back the system cursor. Sessions advertise the cap when they START in desktop mode. Verified on .21: fmt + clippy -D warnings (7 crates) + tests green (core 218 incl. new wire roundtrips, host 245 incl. e2e + forwarder downscale tests). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	333c8979e9	fix(vdisplay/gamescope): capture-loss rebuild probes must not steal the box session ... Observed live on a Deck host: the user switched Game Mode → Desktop, KDE came up in 0.8 s — and the capture-loss rebuild's FIRST detection ran inside that gap, still said Gaming, and its gamescope re-acquire restarted gamescope-session.target. On SteamOS that steals the seat: the user was yanked out of the KDE session they had just chosen, the two session managers fought (job canceled / dependency failed), no gamescope node appeared within 30 s, and the stream died at the 40 s rebuild budget. A rebuild probe acting on possibly-stale detection must never stop, relaunch, or take over box sessions. New pf_vdisplay::rebuild_probe_scope (RAII, counted): while held, the gamescope managed/takeover create paths only attach to a live node and fail fast otherwise — no stop_autologin_sessions, no session-plus relaunch, no gamescope-session.target restart. The capture-loss loop holds it for the first 4 s after a loss (the detection-ambiguity window); after that, destructive rebuilds are allowed again, so a genuine switch INTO Game Mode still gets its headless takeover. Probe failures are instant, so the loop now paces itself at ~2 Hz instead of spinning. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 11:00:02 +02:00
enricobuehlerandClaude Opus 4.8	46d09ed973	fix(host/linux): stop burning retry budget on doomed pipeline builds ... Two session-transition stalls found live on a SteamOS Deck host, one cause: the pipeline retry loop couldn't tell a wait-it-out failure from a retry-now-and-it-works one. - Gamescope first-frame race: a PipeWire stream connected while gamescope re-initializes its headless takeover negotiates a format, reaches Streaming, and never receives a buffer — while a fresh connect delivers within ~0.5 s. Every gamescope bring-up ate the full 10 s first-frame budget on attempt 1 (17 s bring-ups; KWin: 1.2 s). The retry loop's FIRST attempt now waits 2.5 s (Capturer::next_frame_within), so the reconnect that fixes the race happens at ~3 s. Later attempts keep the patient 10 s — the documented 30-60 s Big Picture cold start still fits the budget. - Capture-loss rebuild vs session switch: the rebuild loop re-detects the active session between build_pipeline_with_retry calls, but each call burned 8 attempts (~13 s) against a compositor that no longer exists (a Desktop→Gaming switch spent 13 of its 27 s retrying gone-KWin). The capture-loss path now passes max_attempts=2, turning the outer loop into ~1 s detect-and-retry cycles that follow the box to the new session. The resize path's direct build_pipeline call keeps the default budget (no retry wrapper there to absorb an early bail). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-21 10:34:49 +02:00
enricobuehlerandClaude Opus 4.8	c6caeca5bc	feat(encode): RGB-direct (EFC) is now the DEFAULT on capable hosts — gated by a session cursor-blend hint ... B2 default-on (design/vulkan-rgb-direct-encode.md): wherever the probe passes, Vulkan Video sessions now take the EFC RGB source by default — direct import on aligned modes, padded-copy staging on unaligned ones (1080p). PUNKTFUNK_VULKAN_RGB_DIRECT becomes the override: =0 disables, =1 forces, unset = the default below. The one session class that must NOT default on: cursor-as-metadata captures (every non-gamescope compositor), where the CSC shader's blend IS the visible pointer — the EFC cannot composite, and defaulting there would silently drop the cursor from the stream. The hint rides the existing plumbing: - SessionPlan gains cursor_blend, resolved once where the compositor is known (gamescope embeds the pointer itself → false; kwin/mutter/ wlroots/hyprland → true), and shows up in the logged plan line. - open_video/open_video_backend thread it through (native pump: all three encoder-open sites read plan.cursor_blend; GameStream monitor capture: true — it negotiates metadata cursor; spike: false). - VulkanVideoEncoder::open resolves: env override, else ON iff the session never hands us cursor bitmaps. The warn-once for a cursor on an RGB session (forced via =1) stays. Verified on-hw box (Linux): pf-encode + punktfunk-host compile, clippy clean, unit suite green. The GPU paths themselves are unchanged from the smoke-validated 96e19986 — this commit only changes which sessions select them by default. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 23:24:46 +02:00
enricobuehlerandClaude Fable 5	c5402cb1f7	feat(core+host): LN1 phase-2 — VIDEO_CAP_STREAMED_AU streamed access units ... The wire half of sub-frame slice output (latency §7 LN1, planning design/nvenc-subframe-slice-output.md Phase 2): toward a client that advertises the new cap bit (0x20), a chunked-poll encoder session ships each AU's completed FEC blocks while the tail of the frame is still encoding — the AU's last packet leaves the host as the encode finishes instead of after it. Wire semantics (negotiated; zero change for anyone else): - Non-final blocks ride SENTINEL headers: block_count = 0 (a value no legacy sender emits) + frame_bytes = 0 + exactly max_data_per_block data shards, so the receiver's shard-offset formula needs no total. - The final block's headers carry the real frame_bytes/block_count (+ FLAG_EOF) and RETRO-VALIDATE the whole frame: totals under which a received sentinel block is out of range or not full-K kill the frame wholesale (no spliced delivery) and the index can't be resurrected. - Firewall: sentinels are bounded by the negotiated limits (full-K exactly, never the last block the limits allow, no total to lie about); the exact derived-geometry check runs unchanged on every non-sentinel packet and retroactively at pinning. Sentinel opens commit a max_frame_bytes buffer, bounded by the existing IN_FLIGHT_BUF_FACTOR budget (amplification test). - Order-agnostic like legacy: a reversed frame (final block first) opens legacy-shaped and still accepts its sentinels against the pinned totals. - Small/empty streamed AUs degenerate to byte-identical legacy headers. Host: Packetizer::{begin,push,finish}_streamed seal full-K blocks (data + parity per block) as chunks arrive; Session::seal_streamed_* share the pooled-wire + two-lane seal machinery via the new seal_run; the send thread paces each flush under the frame's existing deadline (pace_sealed split out of paced_submit) and runs the whole-AU accounting at the last chunk; the encode pump forwards poll_chunk output as ChunkMsg when the client has the cap AND the encoder chunks (re-queried per AU — an escalation falls back seamlessly). Probes never run mid-AU. PUNKTFUNK_STREAMED_AU=0 = host escape hatch. Client core ORs the cap into Hello (the shared reassembler carries the support). Sampled first_slice_us vs encode_us PERF log measures the overlap; the 0xCF stage-field extension stays a follow-up. Core tests: streamed round-trip (clean/loss/reorder/duplicate, both orders), sentinel firewall bounds, lying-final wholesale kill + no-resurrect, open-amplification budget, header-shape pins. Gates still owed before default-on: security review pass, loss-harness curve, GameStream smoke (plane untouched structurally), bitrate A/B. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 22:53:53 +02:00
enricobuehlerandClaude Fable 5	ae67315804	perf(encode/nvenc-linux): LN3 — pipelined-retrieve escalation replaces the depth-1 async foot-gun ... PUNKTFUNK_NVENC_ASYNC gains a real tri-state: 1 = always (as before, now documented as ~+1 tick at depth-1), 0 = never (vetoes escalation), unset = ADAPTIVE — off until the session loop's cadence-overrun detector escalates. The host loop's adaptive-depth leaky bucket grows a second stage: once the capturer's depth is maxed (Linux portal is permanently depth-1), it asks the encoder for pipelined retrieve via the new Encoder::set_pipelined hook (asked exactly once; default impl declines, Windows untouched). nvenc_cuda engages at a safe point via a clean session rebuild WITHOUT the IO-stream binding: with input==output stream bound, later stream work waits on prior encode completions and would serialize a pipelined session — stream-ordered submit and two-thread retrieve are mutually exclusive. The ordered gate now also requires async_rt absence (belt-and-braces for the runtime switch). Re-open's first frame is the standard session IDR. On-hardware test: escalate mid-session → retrieve thread live, binding gone, all AUs deliver, first post-escalation AU is the IDR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-20 20:10:24 +02:00
enricobuehlerandClaude Opus 4.8	6f52397342	fix(encode): bound NVENC async pipelining by the capturer's texture ring ... The Windows direct-NVENC backend registers and encodes the capturer's textures IN PLACE (no CopyResource), so how deep it may pipeline is a property of the CAPTURER, not of the encoder. It was bounded only by `async_inflight_cap()` — `PUNKTFUNK_NVENC_ASYNC_DEPTH`, default 4, clamped to the output-bitstream pool — which consults nothing about the capturer, while the comment at the backpressure loop claimed it "keep[s] in-flight depth within the capturer's texture ring". It never did. The IDD-push capturer rotates `OUT_RING = 3` per delivered frame with no regard for encode completion (its own invariant note says OUT_RING(3) > max pipeline_depth(2)). With the default async depth of 4 the encoder can therefore still be reading a texture the capturer has already handed out again and overwritten: torn or mixed frames. It is visual corruption rather than UB, so it fails silently and intermittently — the worst shape to diagnose from a field report. Adds `Encoder::set_input_ring_depth`, reported from `Capturer::pipeline_depth`, and bounds the async backpressure loop by `min(async_inflight_cap(), depth)`. For IDD-push that yields 2, matching the capturer's stated contract; backends that copy their input, or are synchronous, ignore it. Wired at ALL THREE encoder-creation sites (initial open, stall/resize rebuild, ABR rebuild) and forwarded through `TrackedEncoder` — this crate has a documented trap where an unforwarded defaulted trait method silently no-ops through that wrapper, which has already bitten the direct-NVENC work once and the wire-chunking probe once. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:42:53 +02:00
enricobuehlerandClaude Opus 4.8	fecbec2daf	fix(encode): make LTR-RFI loss recovery sound under sustained loss ... Field report (lid-closed Intel laptop, ~6-19% sustained loss): the stream never healed — permanent macroblock soup. Three stacked bugs: - QSV answered RFI with PreferredRefList only, a reorder HINT per the VPL spec — the recovery frame could keep predicting from tainted short-term refs. Now rejects every other DPB candidate (RejectedRefList) and caps L0 at one active entry (AVC/HEVC), matching AMF's hard ForceLTRReferenceBitfield / NVENC invalidation semantics. - Neither QSV nor AMF taint-swept LTR slots across losses: a slot marked inside the client's corrupt window became the "known-good" anchor of the NEXT loss, propagating corruption through every recovery. Both now drop slots at-or-after the loss start before picking an anchor, and guard a queued force whose slot the sweep emptied (no false recovery_anchor tag). - The native plane re-anchored the FULL IDR cooldown on every successful RFI, so under sustained loss the client's escalating keyframe requests were coalesced away indefinitely (field log: dozens swallowed, one IDR per ~8 s). RFI now anchors a 300 ms echo window with a 2-swallow budget per loss episode; a client still asking past that gets its IDR. Live-validated on Arc (qsv feature): 6/6 including the new qsv_live_ltr_rfi_taint_sweep_declines (a loss covering every live mark declines the RFI and falls back to IDR recovery). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:48 +02:00
enricobuehlerandClaude Fable 5	dc20e4452e	fix(pyrowave): anchor frame-driven pacing to arrival, hold full framerate ... The frame-driven capture loop set its rate-limit floor (`earliest`) relative to `next`, which is re-based to the instant AFTER submit(). For an async encoder (NVENC) submit() returns in ~0, so that anchor is ~frame-arrival and the loop correctly waits for the next vsync — full framerate. But PyroWave's encode is SYNCHRONOUS (~2 ms inline in submit()), so the anchor lands ~2 ms late every frame: the loop misses the next arrival and samples one interval behind, making the period `interval + encode`. That capped a 240 Hz source at ~158 fps (and a 360 Hz request at ~200) with the link and the encoder both idle — no drops. Anchor the floor to this frame's arrival (`t_cap`) instead. The synchronous encode now overlaps the interval rather than stacking onto it; the ≥0.9×interval spacing from the last grab still caps the rate at ~1.11× target. No-op for async NVENC (t_cap ≈ post-submit there), which is why H.26x already held full rate. Measured on-glass (5120x1440@240, RTX 4090 host, macOS client): desktop now holds 240 fps. Also reduces latency (samples fresher frames). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-19 01:01:59 +02:00
enricobuehlerandClaude Opus 4.8	b89dbfa979	feat(gamescope): end dedicated stream on Steam game exit + auto --steam ... Dedicated single-game sessions now end cleanly when the launched game quits, and Steam launches get gamescope's Steam integration without an operator env knob. End-on-exit: the existing APP_EXITED close only fired when gamescope's PipeWire node vanished, which never happens for Steam — the nested `steam` is the resident singleton client and stays up after a game quits, so gamescope (and its node) never die and the stream sat on a hidden Steam session forever. Add a Steam AppId reaper watcher (pf-vdisplay .../gamescope/discovery.rs): steam_appid_from_launch() parses steam://rungameid/<id>; wait_for_steam_game_exit() waits for the game to start (<=300s grace) then exit (3s confirm); steam_game_running() scans same-uid /proc for Steam's launch reaper matching both the `SteamLaunch` and `AppId=<id>` argv tokens (exact-match; reaper lifetime == game lifetime, so shader precompile can't false-trigger). The host spawns a pf1-gamewatch thread for nested Steam launches that closes the connection with APP_EXITED (launcher clients return to their library) and sets quit/stop; cancelled via stop if the session ends first. Non-Steam nested launches keep the node-death path (gamescope's child IS the game). Flags: auto-enable `--steam` whenever the launch is a Steam launch (was only the global PUNKTFUNK_GAMESCOPE_STEAM knob, default-off) — in-game overlay / Steam+X / gamepad-UI nav for Steam titles with no operator config. New opt-in PUNKTFUNK_GAMESCOPE_GRAB_CURSOR adds `--force-grab-cursor` for a real game launch (FPS mouselook); default OFF because it forces relative mode, which breaks absolute-pointer games/menus. Verified: fmt clean; clippy -D warnings clean on the three crates; pf-vdisplay 64/0 (incl. new steam-appid parse test); punktfunk-host builds + 186/0; reaper /proc detection smoke-tested (detect, exact non-match, gone-after-exit). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 16:24:34 +02:00
enricobuehlerandClaude Fable 5	5eb930e71d	feat(pyrowave): negotiation plumbing for 4:4:4 + HDR — thread chroma/depth/ColorInfo end to end ... Phase 1 of design/pyrowave-444-hdr.md. No behavior change yet: the handshake's 4:4:4 gate now admits PyroWave (probe = can_encode_444(codec), capture gate inherently satisfied — the wavelet path always ingests an RGB source and does its own CSC), but can_encode_444 stays false for PyroWave until the per-OS full-res-chroma CSC variants land (Phase 2 Linux, Phase 3 Windows), so every session still resolves 4:2:0/8-bit. - Both host encoders take the negotiated ChromaFormat (bail on 444 for now); the PUNKTFUNK_ENCODER=pyrowave lab override pins 4:2:0. - Bitrate: the automatic ~1.6 bpp pin resolves AFTER depth+chroma and scales x1.625 for 4:4:4 / x1.15 for 10-bit (factors from the Phase-0 fixture matrix); the mid-stream mode-switch re-resolve threads the session's values. - Client: PyroWaveDecoder builds its plane ring (full-res chroma when 444) and creates the upstream decoder from the negotiated chroma, keeps chroma fixed across mid-stream resizes, drops the even-dims requirement for 444, and returns the negotiated Welcome ColorInfo as the frame colour contract instead of hardcoded BT.709 (the wavelet bitstream has no VUI). Verified on .21 (RTX 5070 Ti): clippy -D warnings (host+client+encode), host 186 tests, client + pf-encode tests, fmt, and the pyrowave_smoke GPU round-trip through the patched vendored lib (97cf15e3). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-18 12:37:12 +02:00
enricobuehlerandClaude Fable 5	8e75f3d8bf	perf(latency): adaptive IDD pipeline depth — depth-1 default, escalate on contention ... From the 2026-07-17 on-glass finding (.173 RTX 4090): the IDD-push capturer's depth-2 pipeline measured ~13ms of glass-to-glass latency over depth-1 at 60fps (17ms → 4ms) — the AU is ready in µs but depth-2 holds it a whole frame interval unpolled while N+1 is submitted. Depth-2 only earns its keep under GPU contention (it overlaps the convert of N+1 with the encode of N, avoiding the depth-1 ~50fps collapse). So the native encode loop now runs depth-1 by default and escalates to the capturer's max ONLY when it can't hold cadence at depth-1 (a leaky-bucket over 'the frame's work overran its pacing deadline', with a startup warmup skip), then holds there for the session (no oscillation; de-escalation is a v2 item). PUNKTFUNK_IDD_ADAPTIVE=0 pins the capturer's full depth (pre-adaptive behaviour); no effect where the capturer's max is already 1 (every non-IDD backend). GameStream plane untouched. Pairs with the shipped REALTIME auto-gate (1bc156aa): uncontended sessions get the ~13ms latency cut, genuinely GPU-bound ones keep the depth-2 overlap AND the REALTIME priority. Validated: .21 clippy -D warnings (host --features nvenc). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 20:48:55 +02:00
enricobuehlerandClaude Fable 5	bbe4380b41	perf(latency): T1.1 frame-driven encode trigger + T1.4 time-based flush thresholds ... design/latency-reduction-2026-07.md tier 1, remaining halves: - T1.1: the native encode loop wakes on the capture's ACTUAL arrival instead of sampling at a free-running tick — deletes the sample-and-hold (~half a frame interval on average, a full one worst-case: ~8ms avg @60fps). New Capturer::supports_arrival_wait/wait_arrival pair (IDD-push waits its frame-ready event against the shared-header token; the PipeWire portal blocks its channel with a pending stash); backends without an arrival signal — and PUNKTFUNK_FRAME_DRIVEN=0 — keep the legacy tick bit-identically. A 0.9x-interval rate floor caps encode at ~1.11x target when the compositor outruns the session; a +0.5x-interval keepalive keeps static desktops re-encoding at 1.5x-interval cadence. Pacing deadlines re-anchor to the actual submit so they can't drift against the arrival clock. GameStream plane untouched. - T1.4: the jump-to-live detectors run on WALL-CLOCK now (STANDING_TIME / FLUSH_AFTER = 250ms) instead of 30-frame counts whose meaning scaled with fps (500ms @60 but 125ms @240 — and stretching further under T1.1's slower static-scene repeats). The queue trip also requires depth still >= high, so a hysteresis-band hover can't fire on elapsed time alone. Validated: .21 Linux 185 core + 177 host + pf-capture tests, clippy -D warnings; .133 Windows cargo check of pf-capture + punktfunk-host green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:31:49 +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	09849906e9	Merge perf/first-frame-latency: driver proto v4 + first-frame/resize latency (P0-P2) ... Brings the first-frame-latency branch (P0.1 transition tracing, P1.1/P1.2 Welcome-time display prep, P2 in-place resize; pf-driver-proto v3 -> v4 with IOCTL_UPDATE_MODES) onto current main. The branch predates the W6.2/W7 splits, so git's rename detection carried most of it into the moved crates (pf-capture idd_push, pf-vdisplay manager/pf_vdisplay, pf-win-display, pf-driver-proto, the driver workspace) and the punktfunk1.rs remainder was re-homed by hand: - native/handshake.rs: welcome/start trace marks + the Welcome-time display prep spawn (the prep thread BECOMES the stream thread; hand-off via a SyncSender<SessionContext>). negotiate() gains bringup/quit/stop and returns the PrepHandle. - native.rs: bringup/resize_ms creation + the stop/quit flags hoisted BEFORE the handshake (the close watcher splits: flags pre-handshake, lifecycle events post-handshake where `hello` exists); punch_done stamp; the data plane adopts the prep thread's result or builds inline. - native/stream.rs: SessionContext/SendStats carry the trace; send_loop finishes it on the first video packet; the resize path gains the in-place fast path (try_inplace_resize) with the full rebuild as fallback, restructured so both share the post-rebuild bookkeeping; prepare_display/PreparedDisplay/ PrepHandle; build_pipeline(+retry) thread the stage marks. - session_status/mgmt: ttff_ms + last_resize_ms per session (union with the lifecycle-events fields main added to the same spots). - pf-capture: Capturer gains capture_target_id() + resize_output() defaults. - pf-vdisplay manager: perf's faster activation poll (60x50ms) + the settle floor before the PnP sweep, on main's knobs/no-trait shape. Also: packaging/windows/build-gamepad-drivers.ps1 is ASCII again (an em-dash from the pf-mouse work tripped windows-host.yml's locale-safety gate on main). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:08:16 +02:00
enricobuehlerandClaude Opus 4.8	b168790e0a	refactor(host/W6.2): extract the shared frame/format vocabulary into the pf-frame leaf crate ... The captured-frame types both capture (producer) and encode (consumer) speak — PixelFormat, OutputFormat, CursorOverlay, CapturedFrame, FramePayload, DmabufFrame, drm_fourcc — move into crates/pf-frame, alongside the small pure helpers that ride the same seam: hdr (HDR static metadata / in-band SEI), metronome (the metronomic-stall detector), thread_qos (per-thread scheduling QoS), session_tuning (Windows process tuning), and the Windows DXGI capture IDENTITY (WinCaptureTarget, D3d11Frame, pack_luid, make_device + the GPU scheduling-priority hardening it applies) (plan §W6). This is the crate that breaks the capture<->encode cycle: FramePayload's GPU variants own their backends from BELOW (Cuda -> pf_zerocopy::DeviceBuffer, D3d11 -> dxgi::D3d11Frame), so encode can speak the vocabulary without a path to capture, and vice versa. The Windows DXGI identity moving here lets capture, encode, and pf-vdisplay share ONE WinCaptureTarget/device factory instead of the old capture<->encode<->vdisplay reach-in. The host keeps thin facades: capture.rs re-exports the vocabulary (crate::capture::{PixelFormat,…} unchanged); capture/windows/dxgi.rs keeps the win32u GPU-preference hook + HDR/video-engine converters + self-test and re-exports the identity; native.rs re-exports boost_thread_priority from pf_frame. crate::hdr/metronome/session_tuning callers rewired to pf_frame::*. metronome's Metronome::new gained a Default impl (new_without_default fires once the type is public across the crate boundary). Verified: Linux clippy -D warnings (pf-frame --all-targets + host nvenc,vulkan-encode,pyrowave --all-targets) + 9/9 pf-frame tests; Windows clippy nvenc,amf-qsv --all-targets Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 10:03:56 +02:00
enricobuehlerandClaude Opus 4.8	3495d189e1	refactor(host/W6.1): extract the config() global into the pf-host-config leaf crate ... Third de-coupling for the host crate carve (plan §W6.1 leaf). HostConfig + the config() OnceLock (config.rs, pure std, zero deps) move to a new pf-host-config leaf so every subsystem crate (pf-encode/pf-capture/pf-vdisplay/pf-gpu) can read process config WITHOUT depending on the orchestrator. 34 crate::config::config() call sites across 19 files repoint to pf_host_config::config(). thread_qos stays in the host for now (it calls session_tuning::on_hot_thread — its own leaf-ification rides the encode carve). Granular-crate decision (supersedes the plan's single pf-media): split capture/encode/ vdisplay into separate crates rather than one broad crate — the capture↔encode cycle is broken by a shared frame-types leaf, and vdisplay→encode (can_open_another_session) is a legal one-way edge since encode never references vdisplay. Verified: Linux (home-worker-5) clippy -p pf-host-config -p punktfunk-host --all-targets -D warnings; Windows (192.168.1.158) clippy --features nvenc,amf-qsv --all-targets green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 08:54:47 +02:00
enricobuehlerandClaude Opus 4.8	68bcfdac3e	refactor(host/W1): split native.rs control task + data plane into submodules ... Continue the W1 native-host restructure (plan §W1, steps 4+5). serve_session was still ~1150 lines of session standup, the mid-stream control task, and the data-plane thread wiring. - native/control.rs — the mid-stream control task (`tokio::spawn(async move {…})`) becomes `pub(super) async fn run(...)`: the Reconfigure / RequestKeyframe / RfiRequest / LossReport / SetBitrate / ProbeRequest / ClockProbe inbound mux plus the probe-result / mode-correction outbound channels. Call site is now `tokio::spawn(control::run(...))`. - native/stream.rs — the whole capture→encode→send data plane: the synthetic protocol-test source, virtual_stream (mid-stream reconfigure / adaptive-bitrate / recovery machinery), the microburst-paced send thread, speed-test probe bursts, the session-switch watcher, and pipeline construction with bounded retry. Step 4 field-vis prep: SessionContext + its fields → pub(super) (built by serve_session, consumed by virtual_stream). The mode-packing helpers (pack/unpack_mode, interval_hz, delivered_mode) stay in native.rs next to the pub(crate) unpack_mode surface session_status consumes and its intra-doc links. native.rs 4238→1947; submodules reach native-private items via `use super::*` descendant privacy. Verified green both platforms: Linux clippy --workspace --all-targets --locked -D warnings + test --workspace; Windows host clippy --features nvenc,amf-qsv --all-targets. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 20:45:22 +02:00