642 Commits

Author	SHA1	Message	Date
enricobuehler	767f028bdf	feat(host): PyroWave encoder — Phase 1 of the LAN low-latency codec plan ... PyroWaveEncoder behind --features pyrowave + an explicit PUNKTFUNK_ENCODER=pyrowave (loud EXPERIMENTAL warning: no client can decode the stream until CODEC_PYROWAVE negotiation lands, plan Phase 2). Design (plan §4.3): a private ash Vulkan-1.3 device shared with pyrowave via pyrowave_create_device — DeviceHold pins the instance/device create-infos the 0.4.0 API requires alive for the device's lifetime. Capture dmabufs pass straight through on ANY vendor (linux_zero_copy_is_vaapi → true for pyrowave; NVIDIA dmabuf→Vulkan import validated by upstream's interop test on .21) with the same per-buffer import cache as the Vulkan Video backend; the shared rgb2yuv.comp BT.709-limited CSC writes R8+RG8 images pyrowave samples directly (R/G view swizzles synthesize Cb/Cr — no NV12 copy). Encode records into OUR command buffer (pyrowave_device_set_command_buffer), so ingest + CSC + encode are one submission with a sub-ms fence wait; the AU is exactly one pyrowave packet, keyframe=true on every frame. reconfigure_bitrate is a free in-place budget change (Phase 3 pins the session rate); reset() recreates only the pyrowave encoder object. Shared ash leaf helpers (dmabuf import, image/memory utils) extracted from vulkan_video.rs into encode/linux/vk_util.rs — vulkan-encode builds unchanged. Validated on .21 (RTX 5070 Ti): pyrowave_smoke green — encodes CPU fills through the full open→CSC→GPU-encode→packetize path, decodes every AU with upstream's own decoder, checks BT.709 plane means ±3; rate retarget + rebuild covered. clippy clean, 308 host tests green with the feature on. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 00:58:02 +02:00
enricobuehler	4c3b11445c	feat(host): vendor PyroWave + minimal Granite subset as crates/pyrowave-sys ... Phase 0 of design/pyrowave-codec-plan.md — the opt-in wired-LAN ultra-low- latency codec. Vendored at upstream 509e4f88 (API 0.4.0, Granite 44362775, volk + vulkan-headers pins in PUNKTFUNK-VENDOR.txt), pruned to the 6.6 MB the standalone no-renderer build needs; scripts/vendor-pyrowave.sh reproduces the tree (a pin bump is protocol-affecting, plan §4.2). build.rs drives the wrapper CMakeLists (static archives incl. a static C-API lib upstream only ships shared) + bindgen over pyrowave.h; Linux and Windows only, empty stub elsewhere (Apple gets a native Metal port, §4.7). Offline-safe by construction: no network, no system lib, vendored Vulkan headers — same model as the opus dep (flatpak builder has no network). Phase-0 validation on .21 (RTX 5070 Ti, driver 610.43.03): - upstream pyrowave-c-test + interop test (incl. dmabuf/DRM-modifier Vulkan<->Vulkan) pass, from the pristine AND the pruned tree - GPU kernel times at ~1.6 bpp noise: encode/decode 0.090/0.042 ms @800p, 0.146/0.067 @1080p, 0.226/0.103 @1440p, 0.477/0.201 @4K — order of magnitude under NVENC's 1-2 ms retrieve, CBR lands within ~100 B of target - cargo test -p pyrowave-sys green (static link + API-version pin check) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 00:35:10 +02:00
enricobuehler	d2b4e3d71c	fix(host): warn loudly when a CUDA session runs a build without direct-SDK NVENC ... The nvenc feature is off by default, and a Linux host built without --features punktfunk-host/nvenc silently compiles the direct-SDK path out: a CUDA session degrades to libav hevc_nvenc — no RFI loss recovery, an encoder rebuild + IDR on every adaptive-bitrate step, and the libav bitrate clamp — with nothing in the logs saying why. This bit the Linux packagers once (fixed in e89b2f60) and an ad-hoc host deploy again on 2026-07-14, where the on-glass Automatic-climb session showed rebuild-per-step behavior that read as a pipeline gap (it wasn't: the Portal/PipeWire path delivers EGL-imported CUDA NV12 frames and goes direct whenever the feature is in the build). One WARN per process, skipped under an explicit PUNKTFUNK_NVENC_DIRECT=0. Validated on .21 (GNOME/Mutter Portal capture, feature build): probe session logs `Linux direct-SDK NVENC`, and probe --rebitrate lands as `encoder bitrate reconfigured in place (adaptive bitrate — no IDR)`. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-15 00:03:26 +02:00
enricobuehler	0bca67f73e	fix(client): Linux auto decoder prefers Vulkan Video on ALL AMD, not just VanGogh ... VAAPI-first on desktop RADV (46b7ffc0) was a regression: Vulkan Video decode outperforms VAAPI on AMD (on-glass verdict). Vulkan-first is safe there since the same commit's failure-streak demotion lands on VAAPI, not software — a broken Mesa Vulkan path still ends up on the working driver. Auto's order is now: Vulkan first on NVIDIA (no usable VAAPI) + all AMD (perf; VanGogh additionally chroma-fringes over VAAPI); VAAPI first stays on Intel/unknown (ANV's Vulkan Video is the least-proven Mesa path). Policy test updated; 26 pf-client-core tests + clippy green on Linux. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 23:51:54 +02:00
enricobuehler	9d67dc18aa	perf(core): two-lane AES-GCM seal for large frames + send-thread stage split ... Phase 0.4 host half: PUNKTFUNK_PERF now splits the send thread per window into fec/seal/sock (SealPerf via Session::take_seal_perf; the paced video path folds its chunk-send time in through note_sock_ns), logged with per-packet ns in the send loop's perf line. Measured on .21 at 2.5 Gbps offered: fec ~100 ns/pkt (Phase 1.4 landed), seal ~1000 ns/pkt = 21.5% of a core, sock ~1400 ns/pkt — the Phase 1.5 gate (seal > ~15% of the thread at 2 Gbps) trips. Phase 1.5: seal_frame_inner is now write-then-seal — packetize writes every packet's plaintext at its final wire offset, then a frame of >= 256 wire packets (~300 KB) splits the AES-GCM pass across two lanes: a persistent punktfunk-seal2 worker (lazy-spawned, rendezvous channels, no per-frame spawn, zero steady-state allocs via a reused hand-off Vec) seals the back half under nonces seq_base+i while the send thread seals the front. Nonce order is deterministic per shard index, so the wire is byte-identical to the sequential pass — pinned by the wire-equivalence test, now including a 469-packet frame plus an assertion that the lane actually spawned. Small frames and the probe's ~17-packet AUs stay single-lane; PUNKTFUNK_SEAL_LANES=1 forces single-lane. Validated: 84 core tests + workspace suites + clippy -D warnings on .21. Halves the seal wall-clock on big frames — headroom for the 10G pair's ~4.8 Gbps ceiling (seal alone would be ~47% of a core there) and PyroWave 4K rates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 23:47:33 +02:00
enricobuehler	f4f6c5556f	perf(core): FEC encoder reuse — cached codecs + pooled parity, no per-block setup ... Phase 1.4 (throughput-beyond-1gbps.md): the send path built a fresh erasure codec and allocated fresh parity Vecs for every FEC block. New trait method ErasureCoder::encode_into generates parity into caller-pooled buffers; the packetizer keeps one parity pool that grows once to the session's high-water recovery count. - gf16: one cached reed_solomon_simd::ReedSolomonEncoder per coder, re-shaped per block via reset() (reuses its working space) — the old encode() convenience call paid engine CPU-feature detection, FFT planning, and work-buffer allocation per block. - gf8: last-used (k, m) Cauchy codec cached, so the generator-matrix build drops out of steady-state frames; parity buffers shaped without re-zeroing (encode_sep's first-input pass overwrites every row). The GameStream VideoPacketizer now owns a persistent coder so the cache survives frames. - encode() delegates to encode_into — one code path, and the nanors byte-exact parity vector keeps pinning Moonlight wire compatibility. Validated: 145 core + 308 host tests + clippy -D warnings on .21, loss-harness recovery curve identical, pipeline bench +0.6-2.4% thrpt (all configs, p<0.05; the loopback bench is encoder-dominated so the alloc savings mostly land outside it). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 23:19:21 +02:00
enricobuehler	5c7e0afa99	fix(host): Linux virtual-pad feedback access — hidraw udev rules, per-pad DS MAC, SET_REPORT acks ... Root-cause fixes for "rumble + adaptive triggers never work with Linux hosts" (the capture code itself was proven good on-hardware — see the new tests): * 60-punktfunk.rules now grants the `input` group the VIRTUAL pads' hidraw nodes (DS/Edge/DS4/Switch/Deck/SC). Steam/SDL drive DualSense adaptive triggers, lightbar, and player LEDs exclusively over hidraw — and Steam without hidraw demotes a PlayStation pad to a generic evdev device, losing its rumble handling too. Coverage no longer depends on the distro's steam-devices rules + logind's active-seat uaccess ACL (which a headless/ dedicated streaming session never gets). Verified live: nodes now come up root:input 0660. * Per-pad MAC in the DualSense (0x09) and DS4 (0x12) pairing feature replies: hid-playstation adopts the MAC as the HID uniq and SDL/Steam dedup controllers by that serial — identical MACs made a second virtual pad read as the first one re-connecting over another transport. * DualSense/DS4 UHID backends now ack UHID_SET_REPORT (err=0) instead of ignoring it, so a SET_REPORT writer no longer blocks on the kernel's 5 s timeout. * New #[ignore] on-box tests play the GAME's role against a real kernel and pin the full feedback surface (all green on real hw): DualSense evdev-FF + raw hidraw output report (rumble/lightbar/LEDs/both trigger blocks verbatim, per-pad uniq), uinput X-Box FF upload→pump→stop-on-erase, and usbip Deck 0xEB rumble via the controller interface (idle interfaces ACK silently, like real hardware). Windows note: the UMDF driver keeps its own pairing blob copies — the shared- MAC dedup hazard exists there too and needs a driver-side follow-up. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 21:47:13 +02:00
enricobuehler	5a384fe788	feat(host): pace-aware send chunking — high-rate frames pace honestly instead of blasting ... Phase 1.2: the native plane's pace chunks are rate-adaptive — 16 packets at today's rates, coarsening until the per-chunk interval clears the 500 µs sleep floor, capped at 64 (the GSO segment limit). Decouples the syscall batch from the pace step, so a ≥1 Gbps frame's overflow keeps real sleeps between chunks (and costs 4× fewer syscalls) instead of collapsing into an unpaced blast. Phase 1.3: the auto microburst cap scales with the frame — max(128 KB, the AU's wire bytes / 4) — so high-rate frames burst a bounded quarter and pace the rest; PUNKTFUNK_PACE_BURST_KB now pins an absolute override. GameStream plane untouched (its schedule stays pinned by the deterministic tests, now also asserting budget-independence). Linux GSO latch-off warns once (was silent; USO already warned). Linux GSO default stays OPT-IN: the post-1.2/1.3 A/B on the 2.5GbE-hop pair (.21 → M3 Ultra) reproduced the regression bit-for-bit — 2452 Mbps sendmmsg vs 1909 GSO peak, 0.4% loss at 1500 where sendmmsg is clean. The super-buffer trains lose on the constrained hop in the transport path itself (per-AU probe sends, no video pacer involved), so the block is fabric evidence, not pacing readiness. Control sweep on this build matched the sendmmsg baseline exactly (2452); loss-harness recovery curve identical; workspace clippy + tests green on .21. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 21:38:06 +02:00
enricobuehler	a2433d77cf	fix(core): reordering no longer reads as packet loss — net late shards out of the loss estimate ... Reversed/reordered delivery lets a FEC block reconstruct EARLY (data + recovery >= k), counting still-in-flight shards into fec_recovered_shards; window_loss_ppm then reported pure reordering as loss, inflating LossReports — which size adaptive FEC and, since the Automatic overhaul, feed the ABR controller (one severe window ends slow start FOR GOOD, so a reorder burst could permanently kneecap a session's climb). Early reconstruct stays (it's the latency-right choice); the accounting now nets it out. The reassembler counts a new fec_late_shards stat when a parity-restored data shard ARRIVES after all — matched exactly: the completed/abandoned-frame memory (ReassemblyWindow::completed, now a map) remembers which shards each terminal frame reconstructed, and a late arrival must match one (removed on hit), so wire duplicates of delivered shards and stragglers of failed blocks count nothing. In-flight blocks dedup via have_data. window_loss_ppm takes the late delta and estimates from (recovered - late), saturating across window boundaries; both callers (client core + probe) pass it. The e2e reorder tests now assert the NET equals the true kill count in both delivery orders, dup included (previously documented as a known inflation). Not mirrored into the C-ABI PunktfunkStats — the loss windows run in-core on every platform. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 20:59:17 +02:00
enricobuehler	a87b279c2b	test(host): Windows on-hardware NVENC reconfigure smoke — 20→60→10 Mbps in place, zero IDRs ... The Windows twin of nvenc_cuda_reconfigure_no_idr, green on the .173 RTX box (release profile — the dev-profile test binary trips a pre-existing LNK2019 on the sdk crate's unused safe EncodeAPI statics, which release LTO strips). Chasing this also uncovered why the live A/B kept rebuilding: the PunktfunkHost service runs C:\Users\Public\punktfunk-native's exe, not the Developer clone deploy-host.ps1 had been rebuilding. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 20:20:29 +02:00
enricobuehler	9bf72cdfb5	fix(host): forward reconfigure_bitrate through TrackedEncoder + probe --rebitrate validator ... The gpu-session TrackedEncoder wrapper delegates every Encoder method by hand, so the new reconfigure_bitrate fell through to the trait's false default and EVERY bitrate change silently took the rebuild+IDR path — the live .21 A/B caught it (host log said 'rebuilt', never 'in place'). Also: - punktfunk-probe --rebitrate KBPS:SECS — headless mid-stream SetBitrate validator (cursor-wiggles so a damage-driven idle desktop keeps publishing frames through the switch). Live-verified on .21: one NVENC session open, then 'encoder bitrate reconfigured in place (adaptive bitrate — no IDR)' at 20→60 Mbps. - on-hardware nvenc_cuda reconfigure smoke test (20→60→10 Mbps in place, zero IDRs — green on the RTX 5070 Ti). - BitrateChanged doc no longer claims the switch costs an IDR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 20:06:56 +02:00
enricobuehler	a1af916e38	feat(host): in-place encoder rate reconfigure — ABR steps no longer cost an IDR ... Every adaptive-bitrate step used to tear the encoder down and rebuild it, opening on a full IDR (a 20-40x frame-size spike, in-flight AU forfeit and an IDR-cooldown anchor) — exactly when the Automatic controller is climbing. Encoder::reconfigure_bitrate(bps) retargets the LIVE encoder instead (default false, so libavcodec/software paths keep the rebuild fallback, which also still owns the bitrate clamping): - Linux + Windows direct NVENC: nvEncReconfigureEncoder (added to the hand-rolled runtime EncodeApi tables) with resetEncoder=0 / forceIDR=0; the same init/config is re-authored via the new shared build_config/ build_init_params with only avg/max bitrate + VBV (PUNKTFUNK_VBV_FRAMES) moved. On-hardware test: 20→60→10 Mbps in place, zero IDRs (RTX 5070 Ti). - Native AMF: TargetBitrate/PeakBitrate/VBVBufferSize are dynamic properties — SetProperty on the live component, no Terminate/re-Init. - Vulkan Video (HEVC + AV1): stage the rate and emit an ENCODE_RATE_CONTROL control command on the next recorded frame (begin keeps declaring the session's current state, as the spec requires). The session glue tries the in-place retarget first and skips the rebuild/ inflight-clear/IDR-cooldown bookkeeping when it succeeds — the reference chain and the wire-index prediction survive, so RFI keeps working across rate steps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:53:18 +02:00
enricobuehler	46b7ffc001	fix(client): Linux auto decoder tries VAAPI before FFmpeg-Vulkan on desktop Mesa ... Mesa now exposes Vulkan Video decode queues by default (and the session binary opts RADV in for the Deck's sake), which silently moved every desktop AMD/Intel box onto FFmpeg-Vulkan-on-Mesa under `auto` — user-reported (CachyOS/KDE) to judder or error-streak into the software demotion while an explicit VAAPI pick streams perfectly. Auto's hardware order is now device-aware (`VulkanDecodeDevice::prefer_vulkan_over_vaapi`, fed vendor id + device name by the presenter): Vulkan-first stays only where it is the established right answer — NVIDIA (no usable VAAPI) and the Deck's VanGogh (VAAPI dmabuf import chroma-fringes) — and everything else gets the battle-tested zero-copy VAAPI first, with Vulkan as its fallback. A mid-session Vulkan failure streak now also demotes to VAAPI before software, so a broken Mesa Vulkan path can never strand a box with a perfectly good VAAPI driver on CPU decode. The GTK shell's decoder setting gains the missing "Vulkan Video" option (values now mirror the console UI's auto/vulkan/vaapi/software) and drops its pre-Vulkan "Automatic (VAAPI → software)" label. Verified on the RTX 5070 Ti box (loopback session, auto → "Vulkan Video hardware decode active", 60 fps); policy locked by unit test; clippy -D warnings + pf-client-core/pf-presenter tests green on Linux. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:41:37 +02:00
enricobuehler	9b7fc127ef	feat(core): Automatic bitrate scales to measured link capacity — probe ceiling + slow start ... The ABR ceiling was the negotiated start rate, so an 'Automatic' session was permanently boxed at the 20 Mbps default no matter the link — the most user-visible cap left after the transport work lifted the client receive ceiling to ~4.8 Gbps wire. - Startup link-capacity probe: ~2 s into an Automatic session the pump fires one speed-test burst (2 Gbps target, 800 ms) over the existing ProbeRequest machinery; delivered wire throughput x0.7 (FEC + variance headroom) becomes the controller's climb ceiling via set_ceiling(). Old hosts decline (all-zero reply) or never answer (a 6 s timeout clears the stuck probe state so LossReports resume) — the ceiling then stays negotiated, exactly the old behavior. PUNKTFUNK_ABR_PROBE=0 opts out. - Slow start: until the first congestion signal, every cooled clean window DOUBLES the rate toward the ceiling (20 Mbps -> 640 Mbps in ~10 s) instead of +6% per ~10 s (which would have taken ~10 minutes). Any congestion signal ends it for good; classic AIMD takes over. - Faster, severity-aware AIMD: a SEVERE window (unrecoverable frame, jump-to-live flush, or >=6% loss) backs off x0.7 immediately instead of waiting two windows; ordinary congestion (2-6% loss, OWD rise) keeps the two-window fuse. Additive climbs need 6 clean windows (~4.5 s, was ~10 s); the change cooldown drops 3 s -> 1.5 s. - PUNKTFUNK_VBV_FRAMES now also scales the direct-NVENC VBV (Windows + Linux, previously hardwired to 1 frame) — parity with AMF/VAAPI/QSV. Each accepted step still costs an encoder rebuild + IDR on the host; in-place rate reconfigure (NvEncReconfigureEncoder / AMF dynamic properties / Vulkan per-frame RC) is the planned follow-up that makes stepping free. Controller tests rewritten to the new policy (severity classes, slow-start climb, ceiling semantics; 144 green). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:28:11 +02:00
enricobuehler	1a559e8d5e	feat(core): scale the receive path to the new multi-Gbps ceiling ... - REPLAY_WINDOW 32768 -> 131072: the anti-replay bitmap covered the 120 ms loss window only to ~2 Gbps; the client now delivers ~4.8 Gbps wire, where a late-but-valid Wi-Fi-retried datagram would have been dropped as 'older than the window' — false loss. 16 KiB/session covers ~12 Gbps. - RECV_BATCH 32 -> 128: syscall rate stays ~3.4k/s at 430k pkt/s and each pump iteration drains the kernel buffer deeper (ring 64->256 KB, client sessions only). flush_backlog's iteration cap rescaled to keep its ~190 MB guard equivalent. - PUNKTFUNK_GSO gate is now value-aware: '=0' used to ENABLE GSO on Linux (presence check) while disabling Windows USO. GSO stays OPT-IN, deliberately: A/B'd twice today — it cuts send-thread CPU ~30% but its 16-packet line-rate trains cost delivered throughput on a constrained fabric (2.5GbE-hop pair: peak 2453 -> 1908 Mbps and 0.4% loss at a rate sendmmsg carries clean). Flipping the default belongs with pace-aware chunk spacing (plan Phase 1.2/1.3). docs-site row corrected to match. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:22:40 +02:00
enricobuehler	ed0ce5dc6d	feat(core): zero-copy pooled reassembly — shards land at their final AU offset ... Rewrite the client Reassembler around one whole-frame buffer per frame: frame_bytes rides in every header and packetize geometry is deterministic (every non-final block is exactly max_data_per_block data shards), so a data shard's final AU offset is computable on arrival — copy it there once, straight from the decrypt ring. New ErasureCoder::reconstruct_into decodes ONLY the missing shards directly into the frame buffer's holes (gf16 native; gf8 legacy shim); received recovery shards ride pooled shard-sized buffers. The completed buffer IS Frame::data. Deletes the per-shard to_vec + per-block concat + final AU concat (~178k allocs and a double copy of every byte per second at 2 Gbps — the pump wall the 2026-07-14 sweeps measured at 98.9% of an M3 Ultra core). Reassembly now costs ~0.4 µs/packet in-stream. The eager buffer changes the hostile-header exposure, so two new firewalls: derived-geometry validation (a header lying about its data_shards/block_count vs its own frame_bytes is dropped before it can scribble across another shard's range) and an in-flight allocation budget (IN_FLIGHT_BUF_FACTOR × max_frame_bytes) so a window of tiny first-shards can't commit gigabytes. Behavior parity pinned by the existing suite (all green unchanged) plus new end-to-end roundtrips through the real Packetizer (multi-block + partial tail, loss within budget, reversed delivery, duplicates, empty frame, unrecoverable block ages out, budget enforcement). loss-harness recovery curve identical; pipeline bench: gf8/1MB +42%, gf16 neutral (host-encode dominated). Known pre-existing quirk kept as-is: reversed delivery reconstructs early (data+recovery ≥ k) and counts late-not-lost shards into fec_recovered_shards. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:08:15 +02:00
enricobuehler	85513d1697	fix(host/linux): headless gamescope must not inherit a desktop DISPLAY/WAYLAND_DISPLAY ... A host (re)started after a desktop login inherits the user manager's compositor env; a stale WAYLAND_DISPLAY makes headless gamescope 3.16 exit at startup ('Failed to connect to wayland socket') before its PipeWire node appears. Unset both on the systemd-run transient unit (UnsetEnvironment=) and the direct spawn (env_remove) — gamescope exports its own DISPLAY/GAMESCOPE_WAYLAND_DISPLAY to the nested app. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:07:41 +02:00
enricobuehler	0058f624a2	feat(core): receive-path stage timing + frame-jitter observability (PUNKTFUNK_PERF) ... Session::poll_frame accumulates per-stage ns (recv_batch syscall, AES-GCM open, Reassembler::push incl. FEC) into a PumpPerf drained via take_pump_perf(); the client pump logs the split plus completed-AU inter-arrival jitter (p50/p95/max + late count) every report window. Gated on PUNKTFUNK_PERF — one branch per stage when off. Smoothness previously had no metric at all (jump-to-live counters fire seconds late), and the receive core had no attribution. First live use pinned the 1.57 Gbps client wall on software AES-GCM (7 µs/pkt) vs 0.4 µs reassembly — see punktfunk-planning/design/throughput-beyond-1gbps.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 19:07:10 +02:00
enricobuehler	840e5d590e	fix(host/linux): free a desktop-session Steam before a dedicated gamescope launch ... B1b: a Steam running in a plain GNOME/KDE desktop session holds Steam's single instance, so a dedicated gamescope launch's own Steam exits at birth — the game-library launch goes to a black screen. Release the desktop instance (free_desktop_steam) on Steam launches before creating the managed session. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:32:29 +02:00
enricobuehler	6db91cbf40	feat(client): 3-finger swipe toggles the on-screen keyboard mid-stream ... iOS + Android: a three-finger vertical swipe up/down summons/dismisses the device soft keyboard while streaming (trackpad + pointer modes). Mobile scroll is now exactly two fingers so it never collides with the 3+-finger gesture (3+ only fell into the old `>= 2` scroll path by accident). Android: a TYPE_NULL KeyCaptureView plus IME meta-shift wrapping feeds key events through. iOS: UIKeyInput plus a SoftKeyMap char->VK table with a GCKeyboard dup gate so a hardware keyboard and the soft keyboard don't double-emit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:32:01 +02:00
enricobuehler	927a571414	feat(console): touch-mode setting + request-access pairing + polish ... Extend the gamepad/console shell (pf-console-ui) to parity with the other clients: - Settings gain a Touchscreen → Touch mode row (Trackpad / Direct pointer / Touch passthrough), the one couch-relevant Settings field the screen lacked. - The pair screen adds the no-PIN delegated-approval path: a "Request access" action (only when the host advertises a fingerprint to pin) opens a connect the host PARKS until the operator approves this device, then persists it as paired. A role-based row model keeps the cursor off stale indices; manual hosts stay PIN-only, matching the desktop shells. - Threads request_access through OverlayAction::Launch and ConnectIntent; the shell shows a "Waiting for approval…" takeover, and the session binary parks on a 185 s budget (PendingApproval → persist-as-paired via on_connected). Auto-wake (WoL) was already implemented end-to-end and is left as-is. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:31:25 +02:00
enricobuehler	f3b6ccaa7f	fix(gamepad/windows): Steam-accepted Deck unit serial un-mangles the controller name ... Steam validates the Deck unit serial's format before accepting it. Our "PFDK..." serial was REJECTED ("Invalid or missing unit serial number"), so Steam substituted a hash identity and mangled the displayed name to "Steam Deck Controllerggg" on every host tested. An 'F'-leading serial passes, so switch to "FVPF..." — keeps the PunktFunk marker one slot in, still distinct from a real Deck's "FVZZ..." for the Linux self-detection in physical_steam_controller_present(). The name now shows a clean "Steam Deck Controller" with a serial-derived handle (verified on .173). Also fix the UMDF driver's 0xAE GET_STRING_ATTRIBUTE handler to echo the requested attribute id faithfully instead of collapsing board-serial (0x00) requests to unit-serial (0x01). Steam still logs a benign "Deck Controller PCB Serial# invalid" for the board serial — it validates that against a Valve-internal format for ANY value, including an empty one (verified) — but that line does not mangle the name, change the handle, or block promotion. Applied to both transports: host inject/proto/steam_proto.rs::deck_serial (Linux gadget/usbip) and the pf-dualsense UMDF driver (Windows), which mirror each other's serial format. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:31:07 +02:00
enricobuehler	d8e8529cd7	feat(gamepad): Windows Steam Deck backend — Steam-Input-promoted UMDF virtual Deck ... The N4 GO verdict, productized. GamepadPref::SteamDeck on a Windows host now builds a real virtual Deck instead of folding to DualSense: games get native Deck glyphs + both trackpads + gyro + all four back grips through Steam Input's own remapping. - steam_deck_windows.rs: DeckWinPad/DeckWinProto/SteamDeckWindowsManager over the sealed shm channel, sharing the whole Linux Deck codec (steam_proto now compiles on Windows too — it was already pure). The SwDevice identity carries usb_mi: Some(2): the &MI_02 hardware-id token hidclass mirrors into the HID child and Steam parses as the wired controller interface — the promotion gate. - Driver: DEVTYPE_STEAMDECK (3) graduates from the spike — SET_FEATURE 0xEB rumble / 0x8F haptic pulses are republished to the host through the output slot (report-id-0 prefixed, so parse_steam_output sees the Linux wire shape), and the 0xAE/GET_STRING serial + 0x83 unit id are per-pad (read from the section's pad_index; PFDK<unit-id> matches steam_proto::deck_serial). - Router: SteamDeck arms in the Windows Pads paths; pick_gamepad flips SteamDeck-if-windows -> SteamDeck (the DualSense fold retires); dualsense-windows-test grows --deck. ON-GLASS VALIDATED on .173 (rebuilt signed driver 9.9.0714.12xx installed, Steam live): the manager-created pad (index 1) enumerates with per-pad serial PFDK50460001, Steam logs Interface: 2 -> '!! Steam controller device opened' -> 'Steam Controller reserving XInput slot 0' -> PollState 2 (actively polling our cycling input frames) -> mapping activated; clean teardown on exit. Rumble round-trip through a real game remains an on-glass debt (nothing sent 0xEB during the idle hold). Known gap vs Linux: no physical-Steam-controller conflict degrade on Windows yet (degrade_steam_on_conflict is Linux-only — /sys scan); a Windows equivalent needs SetupDi enumeration and is deferred. Verified: .21 clippy -D warnings + 304/0 tests + fmt --all; .133 clippy -D warnings + the WDK driver-workspace check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 12:36:26 +02:00
enricobuehler	4201851c7f	fix(fmt) + feat(gamepad): CI-matching rustfmt everywhere, enforced by repo git hooks; N4 spike flips to GO via MI_02 ... Three things that belong together: 1. rustfmt the gamepad-new-types host files ci.yml's `cargo fmt --all --check` gate flags (the .21/.133 verify recipes ran clippy+tests but never fmt — the same class of miss as 69f30f30). 2. Enforce it at the source: scripts/git-hooks/{pre-commit,pre-push} run the exact CI fmt gates (main workspace + the shipped-driver crates of the UMDF workspace); CONTRIBUTING documents the one-time `git config core.hooksPath scripts/git-hooks`. pre-push is the enforcement point (plumbing commits bypass pre-commit). 3. N4 follow-up — the spike verdict FLIPS TO GO: SwDeviceProfile grows `usb_mi`, synthesizing `&MI_02` into the Deck spike's USB hardware ids. hidclass mirrors the parent's USB tokens into the HID child's hardware ids, and hidapi/SDL/Steam parse `MI_` as bInterfaceNumber (defaulting to 0 when absent — the exact gate the first run hit: Steam wants the Deck controller on interface 2). Re-run live on .173: Steam logs `Interface: 2`, then `!! Steam controller device opened`, `Steam Controller reserving XInput slot 0`, and activates a mapping — full Steam Input promotion of the software-devnode Deck, no driver change needed. The PS identities pass `usb_mi: None` (real single-interface devices carry no MI_ token). A proper Windows-Deck backend phase is now justified; planned separately. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 12:20:33 +02:00
enricobuehler	ea2e3578e2	feat(gamepad): dualsense-windows-test grows --edge (drives device_type 2, cycles R4/L4) ... Used for the .173 on-glass verify: the Edge devnode enumerates (SWD\PUNKTFUNK\PF_EDGE_1, driver pf_dualsenseedge attaches, proto 2), and Steam's live controller.txt confirms the identity end to end — 'type: 054c 0df2', 'Product: DualSense Edge Wireless Controller', 'Controller using HIDAPI driver, vid=0x054c, pid=0x0df2' — with probe lightbar/player-LED feedback flowing back on the 0xCD plane. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:50:06 +02:00
enricobuehler	8d8168b0e0	feat(gamepad): N4 spike kit — software-devnode Steam Deck probe for Windows ... The gamepad-new-types §6 go/no-go rig, ready to run the moment .173 is back (the box is currently down, so the observation itself is still owed): does Steam Input on Windows promote a software-devnode HID Deck (28DE:1205), or does it need a real USB bus identity (the documented GameInput instance-path gap — the Linux 'Interface: -1' lesson)? - Driver: scratch device_type=3 serves the Deck identity — the captured 38-byte controller-interface descriptor, 28DE:1205 attributes, Valve strings, the Deck neutral frame, and the Steam 0x83/0xAE feature contract (SET_FEATURE latches the command, GET_FEATURE answers it — attribute blob + unit serial mirroring steam_proto::feature_reply). Never stamped by a session. INF gains pf_steamdeck. - Host: deck_spike_hold() + the `deck-windows-spike` subcommand — stamps devtype 3, spawns the devnode under VID_28DE&PID_1205, streams the neutral frame, prints what to observe (Steam logs/controller.txt, controller settings) and logs any output reports Steam writes. Run recipe (on .173, once the updated signed driver is staged): install driver, start Steam, `punktfunk-host.exe deck-windows-spike`, watch controller.txt. GO -> plan a proper N4 phase (the Deck codec is already shared); NO-GO -> document next to the Linux Interface:-1 note and keep the SteamDeck->DualSense Windows fold. Verified: .133 clippy -D warnings + the driver workspace cargo check (WDK) both green; .21 clippy + 304/0 tests unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:44:59 +02:00
enricobuehler	8c854e0a19	feat(gamepad): classic Steam Controller backend — Linux UHID via hid-steam (N3) ... The reserved GamepadPref::SteamController = 5 slot goes live: the same hid-steam driver under the wired-SC identity (28DE:1102, ID_CONTROLLER_STATE), UHID-only in v1 (no captured SC USB interface layout, so no Steam-Input promotion — the pre-usbip Deck state; acceptable for discontinued hardware). Layout pinned against the kernel's ID_CONTROLLER_STATE table: 24-bit buttons at 8..11 (low bits shared with the Deck; grips at 9.7/10.0 = the Deck's L5/R5 positions; right-pad click 10.2; joystick click 10.6), u8 triggers at 11/12, the joystick/left-pad MULTIPLEX at 16..20 (a left-pad contact shadows the stick, like real hardware's lpad_touched flag), right pad at 20..24. Mapping: wire left stick -> SC stick; wire right stick -> right-pad coords + touched bit (the SC's camera surface — the second-stick loss is inherent); PADDLE1/2 -> the two grips (natively, masked out of the fold input); PADDLE3/4 + MISC1 -> the remap policy. The SC parser has NO gamepad_mode gate, so no mode-entry pulse. SteamDeckPad grew a SteamModel (open_model); ScProto/SteamCtrlManager; pick_gamepad flips SteamController -> itself on Linux (replacing the Xbox360 fold); SDL picker splits Valve PIDs (Deck 1205 stays SteamDeck, SC 1102/1142 now declare SteamController). Verified: .21 clippy -D warnings + 304/0 tests + on-box UHID smoke (hid-steam binds 1102, BTN_A + right-pad ABS_RX land on evdev, no mode pulse); .133 clippy -D warnings green. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:15:54 +02:00
enricobuehler	70a74b0d7c	feat(gamepad): Switch Pro backend — Linux UHID via hid-nintendo (N2) ... A virtual Pro Controller (057E:2009, BUS_USB, verbatim 203-byte USB descriptor triple-cross-checked from real-device captures) bound by hid-nintendo (>= 5.16): Nintendo-family client pads get correct glyphs + POSITIONAL layout (wire south/east/west/north -> Switch B/A/Y/X, so the physical-position <-> glyph relationship survives), live gyro/accel, and HD-rumble feedback — instead of folding to Xbox360 (mirrored A/B + X/Y, no motion). - switch_proto: report-0x30/0x21/0x81 codec + the entire canned probe conversation, pinned line-by-line against hid-nintendo.c: 0x80-family USB acks, device info (type 0x03 + per-pad MAC), SPI-flash calibration blobs (user magics ABSENT -> factory path; sticks 2048 +/- 1400 with the left/right byte-order difference; IMU offsets 0 + the driver's own default scales so raw units pass 1:1), rumble amplitude decode through the driver's inverted joycon_rumble_amplitudes table, player lights -> 0xCD PlayerLeds. 11 new pin tests. - switch_pro: UHID backend answering the probe from the manager's service pass; SwitchProManager = UhidManager<SwitchProProto> (the 8 ms heartbeat doubles as the steady 0x30 stream the driver's post-probe rate limiter wants). switchpro-test CLI smoke. - Router/fold: SwitchPro arms; pick_gamepad SwitchPro -> itself on Linux; degrade_if_no_uhid covers it. SDL picker: NintendoSwitchPro + JoyconPair declare SwitchPro. Headless-validated on .21 (hid-nintendo 7.1): probe completes ('using factory cal' for sticks + IMU, player-1 LED round-trips to the 0xCD plane), gamepad + IMU input devices created, and an evdev capture pins the positional swap (wire A/B -> BTN_SOUTH/BTN_EAST) + full-range stick scaling. .21 clippy -D warnings + 303/0 tests; .133 clippy -D warnings. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:05:28 +02:00
enricobuehler	1830e095f8	feat(gamepad): DualSense Edge backend — Linux UHID + Windows UMDF (N1) ... The plain-DualSense transport + report codec under the Edge USB identity (054C:0DF2, verbatim 389-byte real-device descriptor cross-checked against the raw usbmon capture + hhd's production virtual Edge), so the wire back grips (BTN_PADDLE1..4: Deck L4/L5/R4/R5, Elite P1-P4) land on the Edge's NATIVE buttons[2] bits instead of the fold/drop policy: PADDLE1/2 -> the right/left back buttons, PADDLE3/4 -> the right/left Fn buttons (kernel BTN_TRIGGER_HAPPY1..4 on >= 7.2; SDL/Steam read hidraw on any kernel). - proto: Edge descriptor + btn2 bits + edge_paddle_bits(), pinned against hid-playstation DS_EDGE_BUTTONS_* and SDL_hidapi_ps5 (tests). - Linux: DsUhidIdentity parameterizes the UHID create; DsEdgeLinuxProto / DualSenseEdgeManager. Headless-validated on .21 (7.1): driver=playstation binds 0DF2, all 4 input devices created, probe lightbar/player-LED feedback round-trips; dualsense-test grew --edge (cycles all 4 paddles). - Windows: UMDF driver serves device_type=2 (Edge descriptor/attrs/strings, DS feature blobs); WinDsIdentity parameterizes the SwDevice profile + devtype stamp; DsEdgeWinProto / DualSenseEdgeWindowsManager; INF gains pf_dualsenseedge. Driver change => resign + reinstall before on-glass. - Router: DualSenseEdge arms in route_handle/apply_rich/pump/heartbeat; pick_gamepad folds Edge -> itself on linux||windows; degrade_if_no_uhid covers it. - Client (SDL): 054C:0DF2 declares DualSenseEdge (no distinct SDL type); Edge physical pads take the raw DS5 effects path; console-UI glyphs = Shapes. Apple/Android pickers follow separately. Verified: .21 clippy -D warnings + 292/0 host tests + on-box UHID bind smoke; .133 clippy pending in this push. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 10:49:31 +02:00
enricobuehler	45bde370e2	feat(gamepad): GamepadPref wire bytes for DualSense Edge (7) + Switch Pro (8) ... Phase 0 of gamepad-new-types: the two new kinds exist on the wire (enum, to_u8/from_u8/from_name/as_str, C-ABI constants + header), and pick_gamepad folds them to the closest EXISTING backend until their own backends land — DualSenseEdge -> DualSense (keeps the rich planes; only the paddles go through the fold policy), SwitchPro -> Xbox360. Wire round-trip pinned 0..=8 + unknown->Auto; fold table extended. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 10:20:24 +02:00
enricobuehler	650acda334	chore(inject): post-extraction sweep (3.3) ... Drop the vestigial Ds4Feedback.hidout field (parse_ds4_output never filled it and neither DS4 manager read it — the lightbar rides the led field, now converted to a HidOutput::Led by the protos) and its now-unused HidOutput import; refresh the pad_gate module doc (managers now drive it via pad_slots). Verified: .21 clippy --all-targets -D warnings + full suite 290 pass / 0 fail + cargo fmt --check clean; .133 clippy --all-targets -D warnings EXITCODE 0. Part of G12/3.3 (§3a.4 commit 10) — extraction complete. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 02:04:51 +02:00
enricobuehler	89aa52bc58	refactor(inject): uinput + XUSB managers onto PadSlots (3.3) ... The two stateless backends keep their structs and special pumps (uinput FF-effect mixing via pump_ff/last_mix; the XUSB stale-residual RUMBLE_IDLE_TIMEOUT force-off) but delegate slot lifecycle — table, unplug sweep, gate-checked create — to the shared PadSlots. XUSB resets last_rumble/last_active on the swept indices and on fresh create exactly as before (the G10/G16-adjacent semantics untouched). Two accepted deltas, both flagged in the plan (§3a): the uinput arrival/unplug log lines gain the pad-identity label every other backend already has ("controller arrival (X-Box 360 pad)"), and XUSB's f.index.max(0) clamp is replaced by the bounds check every other manager uses — a negative wire index is now dropped instead of being treated as pad 0. Verified: .21 clippy --all-targets -D warnings clean + full suite 290 pass / 0 fail (uinput); .133 clippy --all-targets -D warnings EXITCODE 0 (XUSB). Part of G12/3.3 (§3a.4 commit 9) — all seven managers now share the PadSlots lifecycle. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:57:00 +02:00
enricobuehler	384fc30833	refactor(inject/linux/steam_controller): convert to UhidManager<SteamProto> (3.3) ... The most hook-laden conversion: SteamControllerManager becomes a pub type alias of UhidManager<SteamProto>. The Steam-specific pieces map cleanly onto the trait — open() delegates to open_transport (usbip → gadget → UHID fallback, which keeps its own per-transport logging, so no extra success line, matching the old ensure), merge_frame preserves the trackpad coords/touch-bits/clicks + motion across button-only frames (the G2 fix, verbatim), and the gamepad-mode-entry pulse rides the force_heartbeat hook. DeckTransport goes pub (type Pad in a public-trait impl). Also un-fuses a doc-comment glitch where the manager's doc had been merged onto the DeckTransport enum. Verified on .21: clippy --all-targets -D warnings clean; full suite 290 pass / 0 fail. Part of G12/3.3 (§3a.4 commit 8) — all five stateful managers now share one skeleton. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:41:21 +02:00
enricobuehler	365d4bb8f1	refactor(inject/linux/dualshock4): convert to UhidManager<Ds4LinuxProto> (3.3) ... DualShock4Manager becomes a pub type alias of UhidManager<Ds4LinuxProto> (the same shape as the other three DS-family conversions); the bespoke last_led lightbar dedup folds into the shared HidoutDedup exactly as the Windows DS4 conversion did. With 3.3.0 already applied, the proto half is byte-identical to Ds4WinProto except the transport open — the codec, the mappers, and now the manager all shared. Verified on .21: clippy --all-targets -D warnings clean; full suite 290 pass / 0 fail. Part of G12/3.3 (§3a.4 commit 7). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:38:45 +02:00
enricobuehler	f1efd3091e	refactor(inject/windows/dualshock4): convert to UhidManager<Ds4WinProto> (3.3) ... DualShock4WindowsManager becomes a pub type alias of UhidManager<Ds4WinProto>. The bespoke last_led lightbar dedup folds into the shared HidoutDedup: the proto's service() converts Ds4Feedback.led into a HidOutput::Led, and HidoutDedup compares it against the last-forwarded value with the same reset-on-create/unplug semantics the Option<(u8,u8,u8)> vec had. Everything else mirrors the DualSense conversion (same DsState mappers as linux/dualshock4.rs). Ds4WinPad goes pub (type Pad in a public-trait impl, E0446 otherwise). Verified on the Windows CI VM .133: cargo clippy -p punktfunk-host --all-targets -- -D warnings EXITCODE 0 at this tip. Part of G12/3.3 (§3a.4 commit 6). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:36:45 +02:00
enricobuehler	446818eea6	refactor(inject/windows/dualsense): convert to UhidManager<DsWinProto> (3.3) ... DualSenseWindowsManager becomes a pub type alias of UhidManager<DsWinProto>; the proto supplies the UMDF sealed-channel open (+ success log), the DsState mappers (identical to linux/dualsense.rs, paddle fold included), and the section feedback poll. Lifecycle, dedup, and heartbeat come from the shared skeleton — behavior-identical, same log lines (LABEL DualSense/Windows + the driver-install hint). DsWinPad goes pub (it appears as type Pad in the impl of the public PadProto trait — E0446 otherwise; the Linux pads were already pub). Verified on the Windows CI VM .133 (same pinned 1.96.0 MSVC toolchain + Public-path FFmpeg/LLVM the runner uses): cargo clippy -p punktfunk-host --all-targets -- -D warnings EXITCODE 0 at the DS4-conversion tip (.173 was down; .133 carries the identical toolchain). Part of G12/3.3 (§3a.4 commit 5). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:36:45 +02:00
enricobuehler	4d6c2394dc	refactor(inject/linux/dualsense): convert to UhidManager<DsLinuxProto> (3.3) ... The first backend onto the shared skeleton: DualSenseManager becomes pub type DualSenseManager = UhidManager<DsLinuxProto>, where DsLinuxProto supplies only the protocol half (UHID open + success log, DsState neutral/merge/apply_rich with the paddle fold, best-effort write, the GET_REPORT-answering service pass). handle/apply_rich/heartbeat/pump and the unplug sweep now come from uhid_manager — behavior-identical (same log lines, same dedup + reset semantics), zero Pads-router edits. Verified on .21: clippy --all-targets -D warnings clean; full suite 290 pass / 0 fail. Part of G12/3.3 (§3a.4 commit 4). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:10:42 +02:00
enricobuehler	2bea02b0ea	feat(inject): generic PadProto + UhidManager<B> stateful manager (3.3 layer 2) ... The shared skeleton of the five stateful UHID/UMDF managers (Linux DualSense / DualShock 4 / Steam Deck, Windows DualSense / DualShock 4), written once over PadSlots: event routing with the unplug sweep and was-the-unplug early return, the merge-preserving frame fold, rich-input application, the silence heartbeat (with a backend force hook for the Steam mode-entry pulse), and the feedback pump with rumble dedup + HidoutDedup. A backend supplies only its per-controller half via PadProto: open / neutral / merge_frame / apply_rich / write_state / service — exactly where the real protocol differences live. Method surface (new/handle/apply_rich/pump/heartbeat) matches what the punktfunk1.rs Pads router already drives, so each backend will convert as a pub type alias with zero router edits. Additive only — no backend converted yet. 8 mock-backend tests make the manager lifecycle unit-testable for the first time; G2 (rich fields survive a button-only frame) and G10 (Arrival eager-creates) are now generic regression tests, plus removal-frame no-recreate, absent-pad rich drop, create-backoff state tracking, rumble/hidout dedup + re-arm on recreate, and heartbeat gap/force semantics. Verified on .21: clippy --all-targets -D warnings clean; suite 293 pass / 0 fail (285 prior + 8 new). Part of G12/3.3 (gamepad-review-cleanup.md §3a.3, commit 3 of the §3a.4 sequence). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:08:25 +02:00
enricobuehler	528a51d75c	feat(inject): shared PadSlots<P> slot table + lifecycle (3.3 layer 1) ... The Vec<Option<Pad>> slot table, active_mask unplug sweep, and PadGate- checked create that all seven backend managers copy-paste, extracted into one unit-tested inject/pad_slots.rs (cfg any(linux,windows), like pad_gate). sweep() returns the swept indices as a bitmask and ensure() returns fresh-create, so managers reset their per-index sibling state (state / last_rumble / dedup / clocks) without closure gymnastics. Lifecycle log lines are label/device/hint-parameterized to stay byte-identical per backend; open() keeps the success line (it knows the transport detail). Additive only — no manager converted yet; first unit coverage for the sweep/create lifecycle (5 tests: freshness, sweep-once semantics, gate integration, recreate, pump iteration). Verified on .21: clippy --all-targets -D warnings clean; suite 285 pass / 0 fail (280 prior + 5 new). Part of G12/3.3 (gamepad-review-cleanup.md §3a.3, commit 2 of the §3a.4 sequence). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:04:22 +02:00
enricobuehler	b597bb74bd	fix(inject/linux/ds4): fold the Linux DS4 backend onto the shared proto codec (3.3.0) ... The Linux DualShock 4 backend missed the G2-era shared-mapping work and drifted from dualshock4_proto three ways, leaving two user-visible gaps on the DS4 kind (Windows, written later against the proto, is correct): - its serialize_state duplicated the proto's byte-for-byte EXCEPT byte 7: raw st.buttons[2] instead of buttons2_with_click(), so a rich-plane pad click never reached the report; - its inline apply_rich never set touch_click and dropped the Steam LEFT pad entirely (surface 1 skipped), where the shared dualsense_proto::DsState::apply_rich splits the one touchpad left/right; - handle() didn't preserve touch_click across button-only frames. Net effect: Deck client -> Linux host on the DS4 kind = pad clicks and the left pad dead. Delete the local serialize_state/parse_ds4_output/Ds4Feedback/pack_touch and touch-dim consts in favor of dualshock4_proto (dropping the proto's keep-in-sync FIXME), route rich events through the shared DsState::apply_rich, and preserve touch_click in the frame merge exactly like the other three DS-family managers. The proto's serialize_offsets test gains a touch_click case pinning byte 7 bit 1. Verified on .21: cargo clippy -p punktfunk-host --all-targets -D warnings clean; full suite 277 pass / 0 fail. Pre-step 3.3.0 of the G12 skeleton extraction (gamepad-review-cleanup.md §3a.2) — the behavior fix lands before the mechanical dedup. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 01:01:37 +02:00
enricobuehler	49533ff90a	style(touch): rustfmt the presenter finger dispatch + gesture engine ... Wrap the long dispatch_finger call args, Abs struct literals, and Act::Button/ Scroll/MoveRel pushes per rustfmt (the CI fmt check on pf-presenter). No behavior change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-14 00:01:05 +02:00
enricobuehler	f88d0ae4dc	feat(touch): cross-client touch-input modes on Linux + Windows ... Bring the SDL presenter (Linux/Deck + Windows) to parity with the Android and Apple clients: a persisted TouchMode selects how a touchscreen drives the host — * Trackpad (default): relative cursor with pointer ballistics + the shared gesture vocabulary (tap = left click, two-finger tap = right click, two-finger drag = scroll, tap-then-drag = held left drag, three-finger tap = cycle the stats overlay). * Direct pointer: the cursor jumps to and follows the finger (absolute). * Touch passthrough: every finger is a real host touchscreen contact. Previously the presenter had no finger handling, so SDL synthesized mouse events from touch and — under the stream's relative-mouse lock — walked the host cursor into the corner (the reported Deck bug). SDL touch->mouse synthesis is now off; DIRECT touchscreens route through a new incremental gesture engine (a port of Android TouchInput.kt / Apple TouchMouse.swift), while INDIRECT trackpads keep driving the mouse. Fingers map through the aspect-fit letterbox onto the content rect. TouchMode lives in the shared trust::Settings (default trackpad, so passthrough is opt-in like the other clients); the GTK and WinUI settings screens both gained a "Touch input" picker. Gesture engine, letterbox mapping, and settings back-compat are unit-tested (28 tests green); clippy -D warnings clean; full Linux client + session build verified on-host. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 23:51:29 +02:00
enricobuehler	94802795e7	Merge branch 'gamepad-apple-cleanup': cross-client + host gamepad review cleanup (G1–G25) ... 48-finding cross-client + host gamepad audit (2026-07-13). Apple/Android/SDL-core capture + feedback and the Linux/Windows host injectors: held-guide release, the permanent broken-latch cliff (PadGate), Steam Deck trackpad clicks, DualSense mute, Windows DS/DS4 paddle fold, uinput button re-sync, gamestream BTN_* dedup, the dead Windows shell fork, legacy-Deck rumble ceiling, XUSB arrival, ARM64 fences, the truncate-everywhere value convention, and more. See punktfunk-planning/design/gamepad-review-cleanup.md.	2026-07-13 22:29:41 +02:00
enricobuehler	1af11cc64d	fix(inject/host/windows): order the pad change-detect fields with Release/Acquire (G21) ... The XUSB `packet` publish and the XUSB `rumble_seq` / DualSense `out_seq` reads used plain unaligned accesses with no fence, so a driver could observe a bumped change-detect field over a torn body on a weakly-ordered core (ARM64). Publish `packet` via a Release AtomicU32 store behind a Release fence, and Acquire-load the seq fields, mirroring the gamepad_raii PadChannel seq-fence precedent. The DualSense input report embeds its seq mid-report with no driver-gated change-detect field, so it gets a Release fence after the copy and a documented residual (a per-frame input generation is deferred). No-op on x86-TSO. Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	2f214532d9	fix(inject/host/windows): eager-create the XUSB pad on Arrival + refresh last_active (G10) ... The XUSB manager's `handle` dropped `GamepadEvent::Arrival` via a `let else`, so the GameStream path never created the pad until the first `State` and missed the first XInput poll. Match on the event and `ensure` eagerly on Arrival, mirroring the DualSense backend. Also refresh `last_active` on create and unplug so a freshly-created pad's residual-rumble idle clock starts fresh rather than inheriting a stale Instant (which could force off a legitimate rumble at once). Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	31bc863084	fix(inject/host/windows): free the per-section security descriptor (G19) ... `sddl_sa` leaked the `LocalAlloc`'d PSECURITY_DESCRIPTOR that ConvertStringSecurityDescriptorToSecurityDescriptorW returns, once per DATA section and once per bootstrap mailbox create (amplifiable under pad-flap via create_named's squat-retry loop). Wrap it in a `SecAttr` RAII owner that `LocalFree`s on drop; it outlives every CreateFileMappingW (the section copies the security info at create time), and create_named builds one and reuses it across retries instead of re-allocating. Verified: Windows .173 `cargo clippy -p punktfunk-host --all-targets -- -D warnings` (green) -- confirms the LocalFree/HLOCAL signature at the pinned windows-rs rev. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	aedffc69dd	fix(gamepad/client): bound legacy Steam Deck rumble on a lost stop-frame (G16) ... Against a legacy (no-TTL) host, a held Deck rumble droned forever if the stop datagram was lost: the 40 ms keep-alive re-kicked the actuator indefinitely and only the v2 lease `deadline` ever bounded it. Add a per-slot `updated_at` clock bumped ONLY by real host datagrams (never by the keep-alive re-kick, unlike `last_at`), and in the legacy branch (`ttl_ms == 0`) issue a single (0, 0) once it is stale past LEGACY_RUMBLE_CEILING_MS (1000 ms = 2x the host's flat 500 ms legacy refresh). A genuinely-held legacy rumble refreshes every 500 ms and never trips; the v2 `deadline` path is untouched and stays authoritative. Verified: Windows .173 `cargo clippy -p pf-client-core -- -D warnings` (green). On-glass owed: real Deck with an induced legacy stop-frame drop. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	26cac9ce20	fix(gamepad): truncate stick/trigger axes uniformly across clients (G25) ... Apple's GamepadCapture rounded axis values (`(v * scale).rounded()`) while SDL-core and Android truncate, so a half-pressed control emitted 128 on Apple vs 127 elsewhere. Drop `.rounded()` so `Int32(Float)` truncates toward zero on Apple too; rails are unchanged (full deflection stays 255 / ±32767). Also clamp SDL-core's LeftX/RightX to a symmetric -32767 like the Y axes and the other clients already do, instead of letting the raw i16 reach -32768. Verified: Apple `swift build` + full PunktfunkKit suite (124 pass); SDL half on Windows .173 `cargo clippy -p pf-client-core -- -D warnings` (green). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 22:05:13 +02:00
enricobuehler	e5166c6e6e	fix(host/steam): load vhci_hcd at boot on sysext hosts so the Deck pad is Steam-Input-promotable ... The virtual Steam Deck pad only appears in the host's Game Mode (and is navigable) when it arrives as a real USB device via the usbip/vhci_hcd transport — Steam Input won't promote the UHID hid-steam fallback (Interface: -1). The host runs as an unprivileged --user service, so it cannot modprobe vhci_hcd itself; the module must be loaded at boot and the vhci attach/detach sysfs files chgrp'd to the `input` group by the udev rule. Packaging ships modules-load.d/punktfunk.conf + 60-punktfunk.rules under the sysext's /usr/lib, but a systemd-sysext image MERGES after systemd-modules-load and early udev have already run, so on a plain reboot of a sysext host (e.g. Bazzite) those files are read too late: vhci_hcd is never loaded, usbip fails, and the pad silently degrades to non-promoted UHID — the controller vanishes from Game Mode. (deb/arch/rpm are unaffected: real /usr is present at early boot.) Fix: sysext post_merge now mirrors BOTH files into real /etc (read at the normal early-boot time, shadowing the /usr copies by filename; refreshed every merge since neither is user config), then reloads udev, modprobes vhci-hcd, and re-triggers the vhci platform device for the live session. Also raise the UHID-fallback log INFO->WARN with an actionable hint. Verified on the .41 sysext host: after the /etc mirror, unloading vhci_hcd and restarting systemd-modules-load (the real reader of /etc/modules-load.d) reloads the module; a udev coldplug trigger makes attach/detach root:input 0660; the unprivileged host user can then write attach — the exact working precondition for the usbip transport, now durable across reboot. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-13 17:41:51 +02:00
enricobuehler	59fc820226	perf(inject/host): dedup the DualSense HID-output feedback plane (G17) ... A game's DualSense output report bundles rumble + lightbar + player-LEDs + adaptive-triggers into one report, so a pad that is merely rumbling re-sends its unchanged lightbar / LED / trigger state on every output report. The managers already dedup rumble, but forwarded every rich `HidOutput` event verbatim — flooding the 0xCD feedback plane to the client during continuous rumble. Add a shared `HidoutDedup` (dualsense_proto, used by both the Linux UHID and Windows UMDF managers) that forwards Led/PlayerLeds/Trigger only on a value change (per side for the two triggers) and always forwards one-shot TrackpadHaptic pulses — mirroring the rumble dedup two lines above and the DS4 backend's lightbar dedup. Reset per pad on create/unplug. Verified on Linux .21 (clippy -D warnings clean, new HidoutDedup unit test + full suite green); Windows .173 with the rest of Phase 3. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-13 14:14:28 +02:00