22 Commits

Author	SHA1	Message	Date
enricobuehler	a81f1304cd	docs(steam): gadget PoC — interface 2 PROVEN (Steam opens + XInput-reserves it) ... On the Deck (which ships dummy_hcd + raw_gadget + configfs f_hid), a pure-shell configfs gadget stood up a real 3-interface USB Deck (kbd=0/mouse=1/controller=2, 28de:1205) on a dummy_hcd loopback UDC. hid-steam bound all 3 interfaces, and crucially Steam PROMOTED the interface-2 controller: "Local Device Found ... Interface: 2 ... Steam controller device opened for index 14 ... Steam Controller reserving XInput slot 1" — exactly where the interface -1 UHID Deck was filtered. It then failed only at feature-report exchange (f_hid can't serve HID GET_REPORT: "steam_send_report: error -32", "couldn't get controller details ... zombie controller"), and no gamepad evdev formed for the same reason. So interface 2 is necessary AND sufficient for Steam to open+XInput-reserve the Deck; the remaining piece is serving feature/output reports, which raw_gadget can (full control, like UHID). Next: a raw_gadget 3-interface Deck emulator. Doc §11. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	c75f39fd8e	docs(steam): VALIDATED — virtual DualSense IS Steam-Input recognized; isolates the Deck wall to interface 2 ... Definitive hardware test (Bazzite running Steam): a virtual DualSense (UHID, 054c:0ce6, Interface: -1) is FULLY promoted by Steam — controller.txt logs "Local Device Found 054c 0ce6 DualSense Wireless Controller", then "Controller using HIDAPI driver vid=0x054c pid=0x0ce6" and loads configset_controller_ps5.vdf (our calibration/pairing/firmware feature blobs read back). The SAME Interface: -1 that the Deck is rejected at is accepted for the DualSense. So the wall is specifically the Deck's MULTI-INTERFACE requirement (Steam must pick interface 2 among kbd/mouse/controller), NOT a UHID limitation. The DualSense path delivers real Steam Input (gyro + touchpad + glyphs + bindings) for a streamed Deck/SC client; it loses only Deck glyphs, the 2nd trackpad, and the 4 back grips as distinct Steam-Input paddles (M5 folds them to buttons). Full Deck-identity Steam Input would need interface 2 -> a USB gadget (dummy_hcd + configfs HID, controller on interface 2). Feasible but heavy/non-portable: dummy_hcd isn't built on Bazzite/Deck/dev-box, so it'd be a per-kernel build + (on immutable SteamOS/Bazzite) a package-layer + reboot per host. Doc-only (design §11). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	37c3e2bed2	docs(steam): criterion-4 RESOLVED — the interface-2 ceiling; recommend dropping M7 ... Hardware finding (a SteamOS Deck @ .253 + a Bazzite host @ .41, both running Steam, via a minimal C UHID probe on Bazzite): a UHID virtual Steam Deck binds the kernel hid-steam and creates the evdevs (so kernel-evdev + SDL-hidapi consumers see the full grips/trackpads/IMU surface), but Steam Input will NOT manage it. Steam's controller.txt enumerates it ("Local Device Found, 28de 1205, Product Punktfunk Steam Deck") but logs Interface: -1 and never promotes it (no 28de:11ff XInput pad). The physical Deck on the same logs is Interface: 2 — a real Deck is a 3-interface USB device (kbd 0 / mouse 1 / controller 2) and Steam binds the controller on interface 2; a single UHID device has no USB interface number, so Steam reads -1 and filters it out. (The feared 0x83/0xA1 attribute probes never fired — it's an interface filter, not a probe-reject.) Consequences (design §11): - The virtual Deck's value is non-Steam / SDL games on Linux (grips + trackpads + gyro via evdev / SDL HIDAPI), NOT Steam Input. - The virtual DualSense stays the Steam-Input path everywhere (Steam recognizes a single-interface DualSense); M5's paddle-fold carries the back grips. - M7 (a Windows UMDF virtual Deck) is NOT recommended: same interface filter, and Windows has no kernel-hid-steam evdev fallback, so nothing would consume it; the existing Windows virtual DualSense already covers that case. - M0-M6 is not wasted: the protocol/wire + client capture feed the DualSense path too, and the virtual Deck is the best option for non-Steam Linux games. Doc-only (design/steam-controller-deck-support.md): added §11, updated the status + pending-validation. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	4f40fa3cb7	feat(host/steam): M6 — Steam-pad conflict gate (hardware-validated) ... Don't present a virtual Steam (28DE) pad on a host that already has a physical Steam controller — the host's own Steam Input would then manage two Decks and confuse player assignment. - physical_steam_controller_present(): scans /sys/bus/hid/devices for a 28DE HID device on a real (non-/virtual/) path. - degrade_steam_on_conflict() in resolve_gamepad: a resolved SteamDeck / SteamController with a physical Steam controller attached degrades to DualSense (then the M5 uhid ladder); PUNKTFUNK_STEAM_FORCE=1 overrides (e.g. a remote-only box with no competing Steam Input). Validated on real hardware (a SteamOS Steam Deck @ .253 + a Bazzite host @ .41, both running Steam): - Conflict confirmed: the Deck-as-host already has its physical 28DE:1205 AND Steam's 28DE:11FF XInput output pad live; a 2nd virtual 28DE = two Decks. - Bind robustness: the virtual Deck binds hid-steam on a SECOND kernel (Bazzite 6.17.7, vs the dev box 7.0) and the kernel accepted our serial (the M1 fix). - Criterion-4 (running-Steam recognition) PARTIAL: a userspace consumer (Steam/ SDL) engaged the virtual Deck (opened the hidraw, ran the lizard-disable + settings sequence the kernel's Deck path skips) but emitted NO 28DE:11FF XInput pad on the desktop — so Steam recognizes it enough to manage lizard mode but did not promote it to a managed XInput controller (likely needs a Big-Picture/game context, or a richer device; the 0x83/0xA1 attribute probes never fired, so it wasn't a probe-reject either). - The heuristic itself checks TRUE on the Deck, FALSE on Bazzite. Workspace clippy/fmt/test green. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	486a292845	feat(host/steam): M5 — fallback remap, motion rescale, degrade ladder ... Keep the rich Steam inputs from silently dropping when the resolved backend isn't the virtual hid-steam device, and fix a cross-device motion-scale bug. - inject/proto/steam_remap.rs (new, pure + unit-tested): * motion_wire_to_deck — the wire carries DualSense-convention units (20 LSB/ deg.s gyro, 10000 LSB/g accel — what every client capture emits), but the Deck's hid-steam report wants 16 LSB/deg.s + 16384 LSB/g. The Deck backend now rescales (gyro x16/20, accel x16384/10000): a real Deck<->Deck gyro/ accel correctness fix (the DualSense/DS4 backends consume the wire 1:1). * fold_paddles + RemapConfig (PUNKTFUNK_STEAM_REMAP=paddles=drop|stickclicks| shoulders, default drop) — the DualSense + DS4 managers fold a client's back grips onto standard buttons rather than dropping them (those pads have no back-button HID slot; the uinput Xbox pad already exposes them as Elite paddles BTN_TRIGGER_HAPPY5-8). - resolve_gamepad: a runtime degrade ladder — a UHID backend (DualSense / DS4 / Steam Deck) on a host where /dev/uhid isn't writable now falls back to the uinput Xbox 360 pad instead of a dead controller (the device-create would just fail). Separate from pick_gamepad's compile-time platform check, so the existing pick_gamepad tests are untouched. - Delete the throwaway M0/M1 spike (src/bin/steam_uhid_spike.rs) — M2's #[ignore]d backend test subsumes its validation, and removing it frees steam_proto to reference steam_remap cleanly. On-box backend test still green; workspace clippy/fmt/test green (incl. the new steam_remap tests). Deferred as optional RemapConfig growth: gyro->mouse / trackpad->stick synthesis on an Xbox target (no slot — documented drop today). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	d8c254281e	feat(steam): M4 complete — C-ABI send path, Decky UX, Apple/Android parity ... Finish the client side of the Steam Controller / Steam Deck pipeline. - C-ABI (core abi.rs): PunktfunkRichInputEx — a size-prefixed superset of PunktfunkRichInput that can express the second trackpad (surface), a distinct click vs touch, signed coords + pressure — plus punktfunk_connection_send_rich_input2 (the struct_size ABI-skew-guard precedent). The only way a C client (Apple/embedders) can emit a TouchpadEx; the legacy struct + send_rich_input stay byte-for-byte. punktfunk_core.h regenerated. - Decky (clients/decky): a "Steam Deck" gamepad type in Settings + an unmissable Disable-Steam-Input instruction shown when it's selected (in Game Mode Steam Input holds 0x1205, so the SDL HIDAPI Steam driver can't open the Deck's controls until the user disables Steam Input for the shortcut). Plus a best-effort, feature-detected disableSteamInputForShortcut() in launchStream — never blocks/throws; the manual toggle is the documented source of truth. - Apple parity (PunktfunkConnection.swift): GamepadType.steamController/steamDeck (wire 5/6) + name parsing, so the resolved type round-trips. Capture is blocked (GameController never surfaces a 0x28DE HID device). - Android parity (Gamepad.kt): PREF_STEAMCONTROLLER/STEAMDECK + the Valve 0x28DE PIDs in prefFor(). Rich-input capture stays out of scope (no rich-input plane yet) — standard buttons/sticks resolve to the host's Steam Deck pad. Rust workspace clippy/fmt/test green; Decky src/ typechecks clean (only a pre-existing @decky/api dep resolution error remains); Swift/Kotlin compile on their CI. The full pipeline is now BUILT; what remains is validation that needs hardware we don't have (a running Steam on the host, a live Deck client, the Moonlight paddle regression). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	ae71e4628d	feat(clients/steam): M4 — desktop SDL clients capture the rich Steam inputs ... The Linux + Windows native clients (clients/{linux,windows}/src/gamepad.rs) now capture and send the Steam Controller / Steam Deck rich inputs, so a real Deck (off Steam Input) or a Steam Controller on a desktop client drives the host's virtual hid-steam pad end-to-end: - Set SDL's HIDAPI Steam hints (SDL_JOYSTICK_HIDAPI_STEAMDECK / _STEAM) before init so SDL opens Valve devices directly (paddles + both trackpads + gyro as first-class SDL gamepad inputs). - Detect the Deck/SC by VID/PID (0x28DE + 0x1205 / 0x1102 / 0x1142) -> GamepadPref::SteamDeck (there is no SDL gamepad type for it), so the host builds the virtual Deck with the right identity. - Map the SDL paddle + Misc1 buttons -> BTN_PADDLE1..4 / BTN_MISC1 (a free win for Xbox Elite paddles too). - Route a SECOND touchpad -> RichInput::TouchpadEx (SDL touchpad 0 = left -> surface 1, 1 = right -> surface 2, signed coords); a single touchpad keeps the legacy Touchpad. New forward_touch() helper centralizes the choice. - Track held touchpad contacts per (surface, finger) and lift them on pad switch/detach so a contact held at that moment can't stick. - Sensor (gyro/accel) capture was already generic across pad types. Linux client builds + clippy clean; the Windows client is a near-verbatim mirror (windows CI compiles it). On a Deck in Game Mode, Steam Input still holds the device — the user disables Steam Input for the client (the Decky UX, next); on a desktop client (or a Deck with Steam Input off) the hints just work. Remaining M4: Decky Disable-Steam-Input UX, Apple/Android parity, and the C-ABI PunktfunkRichInputEx + send_rich_input2 (Apple/embedder send path). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	01c55aed38	feat(proto/steam): M3 — rich Steam wire (back buttons + 2nd trackpad) ... Carry the rich Steam Controller / Steam Deck inputs end-to-end on the wire — strictly additive + forward-compatible (unknown kinds/bits drop on old peers). Core (punktfunk-core): - input.rs: BTN_PADDLE1..4 + BTN_MISC1 in Moonlight's buttonFlags2<<16 namespace (so the GameStream paddle path and native grips share one host injector map; Steam L4/L5/R4/R5 reuse the four Xbox-Elite paddle slots). - quic.rs: RichInput::TouchpadEx (kind 0x03 — surface 0/1/2, touch+click, signed coords, pressure; the second trackpad the single Touchpad can't express) and HidOutput::TrackpadHaptic (kind 0x04 — the SC voice-coil pulse). Round-tripped. - abi.rs: PUNKTFUNK_GAMEPAD_STEAMDECK=6 / _STEAMCONTROLLER=5, the paddle bits, RICH_TOUCHPAD_EX / HIDOUT_TRACKPAD_HAPTIC constants. from_hid packs TrackpadHaptic into the existing which + effect[0..6] — the legacy structs do NOT grow (guarded by new size_of==20/19 asserts); GamepadPref lockstep + paddle-bit lockstep asserts extended. include/punktfunk_core.h regenerated. Host (punktfunk-host): - steam_proto::from_gamepad maps the wire paddles -> the four Deck grips + QAM; apply_rich routes TouchpadEx left/right -> the matching pad. - every DualSense/DS4 manager (Linux + Windows) gained a TouchpadEx arm (surface 0/2 -> its one touchpad; surface 1 ignored) so the variant compiles everywhere and a Steam client streaming to a DS host keeps its right pad. - the xpad BUTTON_MAP finally consumes the GameStream paddle bits (BTN_TRIGGER_HAPPY5-8) — Sunshine/Moonlight paddle clients were silently no-op'd before (design §5.6). - Android feedback: drop TrackpadHaptic (no coils; rumble rides 0xCA). Validated on-box: the ignored backend test now drives the full wire path — from_gamepad (BTN_A + the L4 grip) + apply_rich (a left-pad TouchpadEx) reach the evdev as BTN_A + ABS_HAT0X=-8000. Wire round-trips + paddle/TouchpadEx mapping unit-tested. Workspace clippy/fmt/test green. Not pushed. Deferred to M4: the C-ABI PunktfunkRichInputEx + send_rich_input2 (only the Apple/embedder *send* path needs it; the host decodes TouchpadEx today). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	95308d352b	feat(host/steam): M2 — virtual Steam Deck as a wired PadBackend (Linux) ... Make the virtual hid-steam device a selectable per-session host gamepad, end-to-end on Linux: PUNKTFUNK_GAMEPAD=steamdeck now builds a SteamControllerManager that creates a /dev/uhid 28DE:1205 Deck, enters gamepad_mode, and feeds the byte-exact Deck report (M1). - inject/linux/steam_controller.rs: SteamControllerManager / SteamDeckPad, mirroring dualsense.rs (open/create2, GET/SET_REPORT pump, heartbeat, RAII destroy). Two Steam-specific quirks beyond the DualSense path: * gamepad_mode entry — best-effort `lizard_mode=0` via sysfs, plus a b9.6 creation pulse (MODE_ENTER) so steam_do_deck_input_event stops early-returning, plus an anti-toggle guard (MENU_HOLD_CAP) so a long in-game Start-hold can't flip gamepad_mode back off. * UHID_SET_REPORT answered err=0 (DualSense omits it; the kernel stalls ~5s/cmd otherwise); the 0xEB rumble report parsed onto the 0xCA plane. - core config.rs: GamepadPref::SteamDeck (wire byte 6) + SteamController (byte 5, reserved — folds to Xbox360 until its backend lands); from_u8 / from_name / as_str. Forward-compatible (unknown byte -> Auto); the C-ABI PUNKTFUNK_GAMEPAD_* constants stay M3, so no generated-header drift. - punktfunk1.rs: PadBackend::SteamDeck variant + select / handle / apply_rich / pump / heartbeat arms; pick_gamepad Linux arm. On-box: an #[ignore]d backend test (backend_binds_and_input_flows) drives the real SteamDeckPad — it binds hid-steam (gamepad + IMU evdevs), enters gamepad mode, BTN_A reaches the evdev, and the device tears down on drop. Workspace clippy/fmt/test green. Not pushed. Next: M3 (protocol/ABI wire) + M4 (client capture). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	9ff7d41bfe	feat(host/steam): M1 — byte-exact Deck input serializer, on-box validated ... Flesh out inject/proto/steam_proto.rs into the full Steam Deck HID contract, transcribed verbatim from the kernel steam_do_deck_input_event / steam_do_deck_sensors_event and validated field-for-field against kernel 7.0: - SteamState: the u64 button map (bytes 8..16), sticks/triggers/trackpads/IMU stored as raw little-endian report values; serialize_deck_state is a pure, byte-exact memcpy into the 64-byte unnumbered frame. - from_gamepad (XInput frame -> Deck buttons/sticks/triggers) + apply_rich (RichInput touchpad -> right pad, motion -> IMU). - parse_steam_output: the 0xEB ID_TRIGGER_RUMBLE_CMD feedback -> (low, high) for the universal rumble plane. - serial_reply fixed: prepend the report-id-0 byte the kernel strips (steam_recv_report does memcpy(data, buf+1, ...)); M0's reply lacked it, so the kernel fell back to the "XXXXXXXXXX" serial. - SteamModel (Deck now; classic Controller later), command/feature IDs. The spike is repurposed as the M1 validator: it pulses the b9.6 mode-switch to enter gamepad_mode (steam_do_deck_input_event early-returns under the default lizard_mode otherwise), then holds a known test pattern. Reading both evdevs via EVIOCGABS/EVIOCGKEY, every field matched: ABS_X/Y/RX/RY (incl. the kernel Y-negation), both triggers, the touched right-pad HAT1X/Y, the IMU accel/gyro (with ABS_Z/RZ negations), and the 6 expected buttons incl. the L4/R5 grips. 5 unit tests + workspace clippy/fmt/test green. Next: M2 (SteamControllerManager UHID backend + PadBackend wiring). Not pushed — pipeline not yet shippable. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	2b47d8cc28	feat(host/steam): M0 — virtual hid-steam UHID device binds + parses (Linux) ... Greenfield virtual Steam Deck controller, the Steam analogue of the shipped virtual DualSense. Proves the kernel hid-steam driver binds a /dev/uhid 28DE:1205 device, registers it as a real Steam Deck, and parses our input reports — the go/no-go gate for the full Steam Controller/Deck pipeline. - inject/proto/steam_proto.rs: keeper module — the vendor HID descriptor (one feature report, the sole thing steam_is_valve_interface() checks), the command/feature IDs, serialize_deck_state, and the serial GET_REPORT reply. Unit-tested. - src/bin/steam_uhid_spike.rs: throwaway M0 spike (Linux-only) — opens /dev/uhid, creates the device, services the handshake including UHID_SET_REPORT (which the DualSense backend omits and which hid-steam stalls ~5s/cmd without), and heartbeats a neutral report. - design/steam-controller-deck-support.md: full design + M0–M7 plan; the two walls (Steam Input capture ownership; virtual-Steam recognition) and the fidelity ceiling. Status: M0 GREEN. On-box (headless Ubuntu 26.04, kernel 7.0, no Steam): journalctl -k shows hid-steam binding the device (rebind off hid-generic), "Steam Controller connected", and the kernel creating BOTH a "Steam Deck" gamepad evdev and a "Steam Deck Motion Sensors" IMU evdev (INPUT_PROP_ACCELEROMETER). A layout-agnostic mash-probe drove 23 distinct BTN_* codes through hid-steam -> evdev, proving the input-report parse path. M1 line-checks the exact per-bit report layout against the lab kernel. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	3e498cd40d	docs(security): #9/#13 fixed, S7 rationale corrected (red-team follow-up) ... 17/18 now fixed. A red-team of the three accepted findings showed #9 and #13 rested on a circular premise (each was the other's "safe fallback") and S7's written rationale was wrong (signing exercises the same modexp Marvin targets). #9/#13 closed; S7 accept retained for the corrected reasons + amplifier hardened. See f0574a5, f6c9576. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	6e2e946bc9	docs(security): #5 fixed + on-box validated (RTX box, 2026-06-29) ... 15/18 now fixed; no finding remains open and actionable. SDDL scoped to SYSTEM+LocalService, validated live (6943-frame DualSense+IDD session works; non-SYSTEM OpenFileMapping now ACCESS_DENIED). See e59fa60. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	ed54f22997	docs(design): add multi-user / profiles design (schema-of-record) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:52:43 +00:00
enricobuehler	36259b264f	docs(security): record remediation status for the 2026-06-28 host audit ... 14/18 fixed (3532e35 Linux-verified + 6f903f7 Windows DACL paths pending CI/box); #5 deferred (needs on-box validation), #9/#13 accepted, S7 acknowledged (no upstream rsa fix). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 22:16:25 +00:00
enricobuehler	6b846913f5	docs(security): 2026-06-28 host security audit (follow-up) report ... Multi-agent follow-up audit of the privileged streaming host: 18 attack surfaces, every finding adversarially double-verified, plus a coverage critic. Records 15 confirmed + 9 partial findings and a prior-fix re-verification of the 2026-06-21 review. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 22:05:58 +00:00
enricobuehler	dac0fee4e3	docs(windows): reflect the install-via-exe (Option A) landing in the build/packaging doc ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:44:47 +00:00
enricobuehler	7b99b41ede	docs(design): trim shipped plans, consolidate cluster, add index ... Much of design/ described work that has since shipped. Trim each doc to its durable rationale + still-open items (the code is the source of truth for shipped detail; git history holds the full originals). - Shipped plans -> status stubs: stats-capture, gamestream-host-plan, apple-stage2-presenter, windows-service. - Trimmed completed-out / open-kept: implementation-plan, hdr-pipeline, host-latency, gpu-contention (fixed stale status table), game-library, linux-setup (fixed m0->spike + stale zero-copy claim), session-aware-host-followups, windows-client-bootstrap, windows-dualsense-{scoping,game-detection}, windows-virtual-display, security-review (per-finding status table; #12 still open), apollo-comparison (shipped backlog collapsed to one-liners). - Windows-host cluster consolidated: windows-host.md -> redirect into windows-host-rewrite.md (whose stale scorecard is corrected -- goal1 is merged, M4 done); windows-secure-desktop.md archived (now a fallback behind IDD-push primary). - Kept evergreen: ci.md, gamescope-multiuser.md, windows-build-and-packaging.md. - New design/README.md: per-doc status table + consolidated open-items roll-up so nothing is tracked in only one buried doc. - Repoint 5 code comments to the archived secure-desktop doc path. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-26 16:39:06 +00:00
enricobuehler	9ea2c17419	docs(windows): add design/windows-build-and-packaging.md + refresh packaging README ... A single repo-internal source of truth for the Windows build/packaging: what ships, the all-Rust driver workspace built FROM SOURCE in CI (+ the anti-stale rationale), the toolchain (clang 22 + bindgen 0.72, no LLVM pin), the Inno installer, the web console bundle, the CI workflows, signing, and the dev loop. (design/, not the docs-site.) packaging/windows/README.md: drop the deleted vendored-driver dir + its "Vendored driver" callout, add the build-* / install-gamepad / clear-force-integrity rows, point at the new design doc. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:22:40 +00:00
enricobuehler	5bf787eb2b	feat(host): web-console performance capture — record stream stats, graph them ... Arm streaming-perf-stats capture from the web console, play, stop, and review the run as graphs; finished captures are saved to disk as browsable/exportable recordings. Covers both the native punktfunk/1 path and GameStream. - stats_recorder.rs: one shared Arc<StatsRecorder> ring (created in gamestream::serve, shared with the mgmt API + both streaming loops, mirroring NativePairing). The hot-path gate is a runtime AtomicBool that replaces the startup-only PUNKTFUNK_PERF for *recording* (PERF stdout logging unchanged); bounded ring (~3 h); atomic temp+rename writes to ~/.config/punktfunk/captures/*.json; path-traversal-safe ids; poison-resilient locks. - native (punktfunk1.rs) + GameStream (stream.rs) emit a StatsSample at their existing ~2 s / ~1 s aggregation boundary — per-stage latency p50/p99, fps new/repeat, goodput, loss/FEC deltas — with no new per-frame work beyond the cheap atomic check. FrameMsg.was_measured keeps pre-arm in-flight frames out of the first window's percentiles (without zeroing the Windows-relay path's fps/encode). - mgmt.rs: 7 bearer-only /api/v1/stats/* endpoints (capture start/stop/status/live; recordings list/get/delete); api/openapi.json regenerated, in sync. - web: new "Performance" page (recharts, rendered SSR-safe) — capture control, live graphs while armed, recordings table (view / download-JSON / delete), and a detail view with the latency stacked-area bottleneck breakdown (p50/p99 toggle) + throughput + health. Charts adapt to either path's stage set. Design: design/stats-capture-plan.md. Built and adversarially reviewed via a multi-agent workflow; workspace build/clippy(-D warnings)/fmt/tests green, OpenAPI no-drift. Not yet on-glass validated against a live session. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 13:59:39 +00:00
enricobuehler	f6490f4c28	fix: complete the docs/→design/ and openapi→api/ rename references ... The file moves (docs/ → design/, docs/api/openapi.json → api/openapi.json) landed in d01a8fd, but the matching reference updates did not — so mgmt.rs's drift-test `include_str!("../../../docs/api/openapi.json")` pointed at a path that no longer exists and the host failed to build. This restores it and updates every reference: - mgmt.rs include_str! → ../../../api/openapi.json (fixes the build) - web/orval.config.ts codegen target, web/Dockerfile, .dockerignore - deb/rpm/Arch packaging install paths - CLAUDE.md, the .gitea CI workflows, code doc-comments, design-doc cross-links docs-site route URLs (/docs/...) untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 11:53:02 +00:00
enricobuehler	d01a8fd17a	feat(host): HDR Vulkan layer so Vulkan games get HDR on the virtual display ... NVIDIA/AMD Vulkan ICDs refuse to *advertise* an HDR color space for a surface on an IddCx indirect/virtual display, so Vulkan games (Doom: The Dark Ages, id Tech, Indiana Jones, …) report "device does not support HDR" — even though Windows HDR, DWM compose, and the client PQ stream all work, and the ICD happily *accepts + presents* a forced HDR swapchain there. The whole gap is enumeration; the community (Apollo/Sunshine/VDD) wrote this off as kernel-side / unfixable. Add VK_LAYER_PUNKTFUNK_hdr_inject (packaging/windows/pf-vkhdr-layer/): a standalone cdylib Vulkan implicit layer that appends {A2B10G10R10, HDR10_ST2084} + {RGBA16F, scRGB} to vkGetPhysicalDeviceSurfaceFormats[2]KHR (no need to hook vkCreateSwapchainKHR — the ICD doesn't validate the color space there). Self-gated on the surface monitor's actual advanced-color state (DisplayConfig GET_ADVANCED_COLOR_INFO), so it is a complete no-op on SDR sessions and real monitors (dedup). Always-on (registry-discovered) so it works regardless of how a game is launched — env-scoping silently fails for already-running Steam. Escape hatches: DISABLE_PF_VKHDR, PF_VKHDR_EXCLUDE, and a built-in kernel-anti- cheat denylist. The installer builds/signs/stages it and registers it under HKLM64\SOFTWARE\Khronos\Vulkan\ImplicitLayers (opt-out "Install the HDR Vulkan layer" task); windows-host CI fmt+clippy-gates it (msvc-only FFI). Live-validated on the RTX box: Doom: The Dark Ages enables HDR over the pf-vdisplay virtual display. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 11:33:20 +00:00