774 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
enricobuehler	4f0b4aa68f	docs(steam): production plan for Deck client pass-through + shippable usbip host ... Write design/steam-deck-passthrough-plan.md — the build plan to ship exact Steam Deck pass-through from the Linux client (incl. the Steam + QAM buttons) plus a virtual Deck on any Linux host. Key validated facts captured so the next session doesn't re-investigate: - Client capture is ALREADY correct: SDL3 maps Steam->Guide, QAM->Misc1; the client forwards BTN_GUIDE/BTN_MISC1; the host maps them to btn::STEAM/btn::QAM. Only precondition: Steam Input disabled on the client (the Decky UX). - Shippable host transport = usbip + vhci_hcd (in-tree + signed everywhere, no module build, no MOK) — PROVEN on Bazzite: Steam promotes the usbip interface-2 Deck (XInput slot + X-Box pad), identical to raw_gadget on SteamOS. - Build steps: refactor steam_gadget.rs into shared Deck-logic + a transport trait; add the usbip transport (vendor-trim the usbip crate to drop rusb/libusb, in-process vhci attach); transport-select raw_gadget->usbip->UHID/DualSense; client leave-shortcut (controller chord + Ctrl+Alt+Shift+D); serial polish. Also checks in the working usbip Deck PoC (packaging/linux/steam-deck-gadget/ usbip-poc/) for the next session to build on. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	963c406f33	feat(host/steam): default the gadget Deck on for SteamOS (glass-confirmed) ... The virtual Steam Deck is validated glass-to-glass on a Deck: it appears as a distinct second Steam controller, a held A drives Steam's overlay ("Resume Game"), and a button press registers in a real game (confirmed in-game). gadget_preferred() now defaults ON for SteamOS hosts (/etc/os-release ID=steamos or ID_LIKE), OFF elsewhere where the universal UHID path stays the default; PUNKTFUNK_STEAM_GADGET=1/0 forces it. A Deck-as-host with a physical Deck never reaches this path — resolve_gamepad's conflict gate degrades SteamDeck → DualSense first, so the two-Deck case never happens in production (it was only a test-rig confound on the dev Deck). The feature is complete: a virtual Steam Deck that Steam Input recognizes + promotes, churn-free, with input flowing to games. 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	7ab8acaf55	feat(host/steam): harden the gadget feature contract — fixes the evdev churn ... The virtual Deck's gamepad evdev was churning (destroyed + recreated) because Steam kept re-probing: GetControllerInfo reads HID feature reports, and the gadget served zeros for them. Captured the real contract off a physical Deck (packaging/linux/steam-deck-gadget/get_deck_attrs.c, hidraw HIDIOCGFEATURE — usbmon truncates to 32B) and implemented it in steam_gadget.rs::feature_reply: - 0x83 GET_ATTRIBUTES_VALUES: [83, 2d, 9×(attr-id, u32-LE)] — product id 0x1205, a per-instance unit serial (0x0a/0x04, so a gadget never collides with a real Deck or another gadget), and the capability attrs (0x09=0x2e, 0x0b=0x0fa0, rest 0). - 0xAE GET_STRING_ATTRIBUTE: [ae, len, attr, ascii] — serial (attr 1) / board serial (attr 0). - other commands (0x87 settings): echo the last write. Validated on the Deck: 1 connect / 0 disconnect / 1 gamepad evdev (was constant churn), Steam activates the gadget cleanly (no GetControllerInfo failed, no zombie) and emits its X-Box 360 pad. usbmon on the gadget's bus confirms our state reports (pressed button at byte 8) are delivered on the interrupt-IN and consumed by hid-steam — so with M1/M2's byte-8→BTN_SOUTH decode the input chain is proven end-to-end. Remaining: a foreground-game confirmation of Steam Input's XInput mapping, then default the gadget on for SteamOS. 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	c8e19396e4	feat(host/steam): raw_gadget Deck host backend (Steam-Input path, opt-in) ... Port the proven raw_gadget virtual Deck to a Rust host gamepad backend, the SteamOS-only transport that gets Steam Input to actually promote the Deck. - inject/linux/steam_gadget.rs (new): SteamDeckGadget — a userspace raw_gadget emulator of the real 3-interface USB Deck (mouse=0/keyboard=1/controller=2, 28DE:1205) on a dummy_hcd loopback UDC, descriptors captured from a physical Deck, answering every control transfer incl. the HID feature reports. Driven by the same steam_proto::serialize_deck_state as the UHID pad; rumble feedback via parse_steam_output. The raw_gadget UAPI is funneled through 4 documented ioctl wrappers (the crate denies undocumented unsafe). - inject/linux/steam_controller.rs: the manager pad is now a DeckTransport enum (Uhid | Gadget); ensure() prefers the gadget when PUNKTFUNK_STEAM_GADGET=1 (best-effort modprobe dummy_hcd+raw_gadget), gracefully falling back to the universal UHID SteamDeckPad. write/pump/heartbeat dispatch through the enum. Validated on a real Deck via a static musl harness that #[path]-includes the module: enumerates, hid-steam binds + reads our serial + creates the Steam Deck + Motion Sensors evdevs — identical to the C PoC. Caught a real portability bug: raw_gadget's no-arg ioctls (RUN/CONFIGURE/EP0_STALL) reject a non-zero `value` with EINVAL, and on musl an omitted ioctl vararg is a garbage register — so they must pass an explicit 0. Opt-in (default off) while the Steam GetControllerInfo feature contract is hardened (to stop the gamepad-evdev churn). 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	78020cd66c	docs(steam): gadget input-flow status — reports delivered + format-validated ... On the Deck, a pressa build shows hid-steam polls our interface-2 interrupt-IN endpoint and our 64-byte state reports are delivered ("STREAM: first input report delivered"). The report format is already validated (M1 serializer on-box + M2's EVIOCGKEY/EVIOCGABS test on the same hid-steam decode). The "Steam Deck" gamepad evdev forms but is transient (hid-steam recreates it as gamepad_mode toggles — Steam keeps re-probing because the PoC serves the serial but not Steam's full GetControllerInfo attribute set, on a heavily-churned test Deck), so a stable live EVIOCGKEY catch of the held A wasn't obtained. Delivery + format proven; the evdev transience is a feature-report-completeness gap the host backend resolves. 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	8870e85233	feat(steam): raw_gadget virtual Deck — full Steam Input recognition (proven on Deck) ... The interface-2 wall is climbed. packaging/linux/steam-deck-gadget/deck_raw_gadget.c is a raw_gadget userspace emulator of a real 3-interface USB Steam Deck (28DE:1205, mouse=0/keyboard=1/controller=2) on a dummy_hcd loopback UDC, with descriptors captured verbatim from a physical Deck and full HID feature-report handling. Live on a real Deck (SteamOS 3.8.11): hid-steam reads our serial (PFDECK000), creates the Steam Deck + Motion Sensors evdevs, and Steam Input PROMOTES it — controller.txt "Interface: 2 ... device opened ... reserving XInput slot 1" + "input: Microsoft X-Box 360 pad 1". Stable (1 connect, 0 disconnects, no zombie); the kernel Steam Deck evdev is then grabbed by Steam Input which exposes its own X-Box pad, exactly like a real Deck. First time a virtual Deck is fully Steam-Input promoted (UHID can't — it has no USB interface number, so Steam filters it). Also includes the configfs f_hid variant (configfs_gadget_up/down.sh) — the minimal reproducer that proved interface 2 makes Steam open+XInput-reserve the device, but f_hid can't serve feature reports so Steam dropped it as a zombie. Gotchas documented in the README: 7-byte vs 9-byte endpoint descriptor, no-data OUT controls acked via zero-length EP0_READ (not WRITE, else error -110), streamer must not start before SET_CONFIGURATION is acked. SteamOS-host only (needs dummy_hcd + raw_gadget). Recognition proven; feeding real client reports + a host backend is next. Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
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	7cd9364c9e	style(host): rustfmt the #9/#13 pairing edits ... 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	60de506f66	fix(host/gamestream): correct the rsa-Marvin (S7) rationale + cap pairing signatures ... Red-team found the .cargo/audit.toml justification for RUSTSEC-2023-0071 was materially wrong: it claimed "Marvin targets decryption, so the vulnerable path isn't exercised" — but the advisory is a variable-time modexp of the secret exponent, which RSA *signing* (signing_key.sign) also runs. The accept is still correct, for the RIGHT reasons (no decryption/padding oracle; the signed serversecret is host-random not attacker-chosen; signing is operator-PIN-gated; GameStream is off by default and the native QUIC plane uses rustls, not rsa; Moonlight mandates RSA-2048 so the GameStream key can't move off it). Rewrite the rationale accordingly. Also shut the timing-sample amplifier the review surfaced: the pairing session was never marked after phase 3, so a peer past phase 1 could loop phase2/phase3 to harvest many RSA signing-time samples. Sign exactly once per ceremony (reject a repeated serverchallengeresp). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	2865368771	fix(host/pairing): close native-pairing DoS findings #9 + #13 (red-team follow-up) ... The accepts for #9 (PIN-window burn) and #13 (knock-queue flood) rested on a circular premise — each cited the other as the safe fallback — and a re-review showed one LAN attacker could defeat BOTH, denying all onboarding. Close them: - #13 per-source-IP cap on the pending-knock queue (MAX_PENDING_PER_IP) so one host can't fill/evict the 32-slot queue (QUIC validates the source address); and eviction now NEVER drops a live *parked* knock (a held-open connection awaiting operator approval), so a cert-rotating flood can't evict the genuine device being onboarded. This makes the delegated-approval path genuinely flood-resistant — restoring the validity of #9's "use delegated approval on hostile LANs" fallback. - #9 fingerprint-bindable PIN window: `NativePairing::arm_for(ttl, Some(fp))` binds the window to one operator-selected device; `pin_for_attempt` returns `BoundToOther` for any other fingerprint, which the QUIC pair path rejects WITHOUT consuming the window — so an unpaired peer can neither pair nor BURN a window armed for a specific device (it can't forge the bound fingerprint). The mgmt `POST /native/pair/arm` gains an optional `fingerprint` (from a pending knock); unbound arming keeps the legacy any-device behavior (trusted-LAN). (Web-console "pair this pending device with a PIN" UX is a follow-up; the flood-resistant knock path above is the immediate hostile-LAN onboarding path.) + regression tests (armed_pin_is_fingerprint_bindable, pending_per_ip_cap_and_parked_protection); api/openapi.json regenerated. 110 host tests + clippy + fmt green. 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	b5f02000d6	fix(host/security): scope Windows shared-section SDDL to SYSTEM+LocalService (close #5) ... The gamepad host<->UMDF-driver shared sections (Global\pfds-shm-*, pfxusb-shm-*) and the IDD-push frame ring/event (Global\pfvd-*) were created with `D:(A;;GA;;;WD)` — GENERIC_ALL to **Everyone** — on the assumption the driver's WUDFHost ran under a restricted token needing broad access. So any local unprivileged user could OpenFileMapping the section to inject controller input, tamper the trusted HID channel, or read captured screen frames (security-review 2026-06-28 #5). On-box validation (RTX box, 2026-06-29) disproved the restricted-token premise: the WUDFHost token is NT AUTHORITY\LocalService (S-1-5-19), SYSTEM integrity, with ZERO restricted SIDs. So the section only needs SYSTEM (the host creates + writes it) and LocalService (the driver opens it). Scope both SDDL sites to `D:(A;;GA;;;SY)(A;;GA;;;LS)`; rename the now-misnamed `permissive_sa` -> `shared_object_sa`; correct the stale "restricted-token / Everyone" docs. Validated live: a full DualSense + 1280x720x60 session — 6943 frames received, HID output round-tripped, device status OK (pf_dualsense + pf_vdisplay WUDFHosts both LocalService open the scoped sections fine), while OpenFileMapping from a non-SYSTEM admin session now returns ACCESS_DENIED (was a granted handle under WD). Host-only change (the SDDL is set when the host CREATES the section); drivers unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 19:17:37 +00:00
enricobuehler	fe562f0562	chore(apple): rename app display name to "Punktfunk" ... CFBundleDisplayName was "Punktfunkempfänger" across all targets/configs; the in-app title is already "Punktfunk", so make the home-screen name match. Built iOS app resolves CFBundleDisplayName = "Punktfunk". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 20:34:16 +02:00
enricobuehler	4e00037a89	feat(apple): stage-2 default + pixel-perfect, decode robustness, UI/rumble polish ... Stream reliability - Default to the stage-2 presenter (VTDecompressionSession + CAMetalLayer): it detects and recovers a wedged decoder, where stage-1's AVSampleBufferDisplayLayer freezes hard on a lost HEVC reference frame with no app-side recovery (confirmed Apple limitation). Stage 1 is now a DEBUG-only presenter toggle, plus the automatic no-Metal fallback. - Stage-2 pixel-perfect: render the drawable at the decoded size (shader stays 1:1 = identity) and let the layer's contentsGravity scale via the system compositor — the same path stage-1's videoGravity used — instead of scaling in-shader. - Loss recovery in both pumps is now a persistent awaitingIDR want, retried until an IDR actually lands, so a keyframe request swallowed by the throttle can't strand a frozen frame; 100 ms keyframe throttle to match the Android path. - Fix "Publishing changes from within view updates": defer the HostStore writes out of the .onChange(of: model.phase) callback. - Move AVAudioSession setActive/setCategory off the main thread (async on a shared serial queue) to stop the UI-stall warning. Controllers - Rumble: capped-exponential backoff when the gamecontrollerd.haptics XPC breaks (-4811) so a transient server interruption self-heals instead of cascading; playsHapticsOnly so a controller engine doesn't join the always-active streaming audio session. - Host cards: iPad pointer "magnet" hover effect; iPhone press scale + light haptic. UI / design - Ship Geist (SIL OFL 1.1) as the app font (bundled OTFs + registration), with the license surfaced in Acknowledgements. - Restructure iOS/iPadOS Settings into a category NavigationSplitView; resolution wheel with custom-resolution entry; 10-bit HDR toggle in Display. - Industrial host-card redesign (left-aligned, bold, brand monogram tiles). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 20:26:10 +02:00
enricobuehler	46b9aa8cf0	fix(windows-host): IDD activation — resolve-first, force-EXTEND only as fallback ... force_extend_topology() was added before the resolve loop to de-clone a fresh IDD on integrated-screen boxes (laptops), but its bare SDC_TOPOLOGY_EXTEND preset is ACCESS_DENIED from the Session-0 service context on a HEADLESS box and broke the IDD auto-activation there: resolve_gdi_name stayed None -> "not an active display path" -> black screen. That regressed the headless/primary platform (live RTX box). Revert to the proven e2c9bfd flow: resolve FIRST (Windows auto-activates the IDD as its own extended path), and force-EXTEND only as the FALLBACK when resolve returns None (the integrated-screen clone case, observed live to leave resolve None). The success path is byte-identical to e2c9bfd (resolve -> set_active_mode -> isolate_displays_ccd). Validated live: the headless RTX box streams again (probe: frames flow, driver attaches to the ring, host/driver render LUIDs match). Reviewed multi-agent + adversarial: no regression on the validated headless path or the observed Optimus-laptop clone path (a cloned IddCx target resolves to None there, so the is_none() fallback fires + de-clones). Known theoretical caveat, documented inline and unobserved for IddCx but untested across GPU/driver/OS: a CCD clone that manifests as a shared-source ACTIVE path would resolve to Some and bypass the is_none() gate. Follow-up: widen the gate (a target_is_cloned helper) once an integrated-screen box is available to validate. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-29 16:15:48 +02:00
enricobuehler	372b27540b	fix(apple): render Acknowledgements notices in lazy chunks ... THIRD-PARTY-NOTICES.txt is ~885 KB / 16k lines; rendering it in a single SwiftUI Text overshot the text-rendering height limit — it laid out for ages and drew blank below the cutoff (only the small punktfunk licenses above it showed). Split the notices into ~80 line-chunks (<=200 lines / <=18 KB each, computed once as Licenses.thirdPartyNoticesChunks) and render them in a top-level LazyVStack so only on-screen chunks lay out and no chunk is tall enough to clip. Chunking is lossless — rejoining the chunks reproduces the original byte-for-byte, so no notice text is dropped. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 12:34:19 +02:00
enricobuehler	db4d15bf8b	fix(apple): stop the iOS/iPadOS Add Host sheet from scrolling ... The add-host content is a SwiftUI Form (backed by a scrollable list), so it bounced/scrolled inside the fixed .height(320) detent even though the three rows + action button fit exactly. Lock it with .scrollDisabled(true) on iOS (covers iPadOS); macOS (fixed-size panel) and tvOS (custom rows, no Form) are untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 12:12:08 +02:00
enricobuehler	8e24ea9ed7	fix(ci): archive Apple release builds with Automatic signing ... The in-app OSS license screens (7591425) added a `resources:` array to the PunktfunkKit SwiftPM target, which makes SwiftPM emit a resource-bundle target (PunktfunkKit_PunktfunkKit). A resource bundle is a product type that cannot carry a provisioning profile, so the explicit PROVISIONING_PROFILE_SPECIFIER each release.yml archive step set — global on macOS, sdk-scoped on iOS/tvOS — now lands on it and fails the archive ("does not support provisioning profiles") on all three platforms. (Before that commit there was no resource bundle, so the profile was harmless.) Switch all three archive steps to CODE_SIGN_STYLE=Automatic (development): Automatic signing assigns a profile only to the app target and leaves the resource bundle (and the macOS-host SwiftPM macro plugins) alone, and bakes the sandbox entitlements in. No -allowProvisioningUpdates, so it stays offline and never cloud-signs (the App-Manager ASC key can't). DISTRIBUTION signing is unchanged — still manual, in the -exportArchive step (which maps the profile to io.unom.punktfunk only). Drops the now-unneeded manual signing xcconfigs. Requires the runner to have a development provisioning profile for io.unom.punktfunk on each platform (now installed for macOS/iOS/tvOS). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 12:12:08 +02:00
enricobuehler	73c0125843	fix(mgmt): regenerate api/openapi.json for 0.3.0 ... The OpenAPI 'info.version' tracks CARGO_PKG_VERSION; the 0.3.0 bump made the checked-in spec stale (the openapi_document_is_complete_and_checked_in test). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 07:54:30 +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> v0.3.0	2026-06-29 06:52:43 +00:00
enricobuehler	031ee86ed5	chore(release): bump workspace version to 0.3.0 ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:52:43 +00:00
enricobuehler	7591425f6f	feat(clients): in-app OSS / third-party-license screens ... Surface THIRD-PARTY-NOTICES.txt in every GUI client (the desktop packages already ship it as a file; this adds the on-glass screen): - Linux: Preferences -> About -> Third-party licenses (adw::AboutDialog with the app license + Legal sections; include_str! the root notices). - Apple: macOS About tab / iOS+tvOS Acknowledgements link; notices bundled as PunktfunkKit SPM resources, read via Bundle.module (the Xcode app links the SPM product, so they ride along - no .pbxproj edit). - Android: Settings -> About -> Open-source licenses (reads the bundled asset). - (Windows landed earlier in d1d2ca2: Settings -> About -> Third-party licenses.) gen-third-party-notices.sh now copies the generated file into the Apple Resources/ and Android assets/ trees so the in-tree copies never drift. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:52:43 +00:00
enricobuehler	d1d2ca293d	feat(pairing): seamless no-PIN delegated approval (host parks the knock, clients add "Request access") ... Web-console "Approve" (delegated pairing, roadmap §8b-1) was unreachable: every client routed a fresh pair=required host straight to the SPAKE2 PIN ceremony, so no "knock" was ever recorded; and an unpaired connect was rejected+closed with no way to resume after approval. The backend + console were complete but had no client-side trigger and no post-approval admit path. Host (native_pairing.rs, punktfunk1.rs): an unpaired identified knock is now PARKED instead of rejected — it releases its NVENC session permit, awaits an operator decision (NativePairing::wait_for_decision, woken by a Notify on approve/deny), and on approval re-acquires a slot and admits the SAME connection with no reconnect. QUIC keep-alive (4s/8s) holds the parked connection warm. The pairing gate moves out of the HANDSHAKE_TIMEOUT-bounded handshake future; approve_pending is reordered read-then-add and wait_for_decision double-checks is_paired to close a "neither pending nor paired" race. New PENDING_APPROVAL_WAIT (180s). Tests: delegated_approval_admits_after_knock now approves mid-park (no reconnect) + new wait_for_decision_approve_deny_timeout unit test (108 host tests green). Clients (Linux/Apple/Windows/Android): a fresh pair=required host now offers "Request access" alongside the PIN ceremony — a plain identified connect with a ~185s handshake budget and a cancelable "waiting for approval" UI; on success the host is saved as paired, and cancel returns the UI immediately while a late- resolving connect is torn down silently via a per-attempt flag. Apple reuses the existing C-ABI timeout_ms (no ABI change); Windows adds SessionParams.connect_timeout + a RequestAccess screen; Android adds a timeoutMs arg to the nativeConnect JNI seam (both sides + both callers). Linux built + clippy + fmt clean; Apple/Windows/ Android pending their CI/on-device compiles. SPAKE2 ceremony reviewed end-to-end against the spake2 0.4 contract — correct, no changes needed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:41:09 +00:00
enricobuehler	705a8fa94e	chore(deps): drop unmaintained rustls-pemfile; axum-server 0.7 -> 0.8 ... axum-server was used only for the plain-HTTP nvhttp listener, but we enabled its tls-rustls feature (HTTPS is hand-rolled over tokio-rustls) — and that feature was what pulled the unmaintained rustls-pemfile (RUSTSEC-2025-0134). Drop the feature, bump axum-server to 0.8 (0.8 also no longer pulls it), and move our own PEM parsing in gamestream/tls.rs to rustls-pki-types' PemObject (the same path punktfunk-core/quic.rs already uses), removing our direct rustls-pemfile dep too. Net: rustls-pemfile fully gone; dependency graph trimmed 547 -> 529 crates (the tls-rustls feature also dragged in prettyplease + a wasm-tooling chain). cargo audit now reports only audiopus_sys + paste (transitive, latest, no successor). 108 host tests + clippy + fmt green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:32:58 +00:00
enricobuehler	4ba63b7da6	fix(deps): bump memmap2 0.9.10 -> 0.9.11 (RUSTSEC-2026-0186, unsound) ... memmap2 0.9.10 has an unchecked-pointer-offset unsoundness; 0.9.11 is the patched release (pulled transitively via xkbcommon in the host). cargo audit now reports only the 3 deliberately-visible `unmaintained` warnings (audiopus_sys / paste / rustls-pemfile — all latest, transitive, warn-only, do not fail CI per .cargo/audit.toml). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:20:55 +00:00
enricobuehler	bee1f0416d	chore(licensing): LGPL FFmpeg swap, third-party notices, attribution hygiene ... The MIT OR Apache-2.0 SOURCE license is clean (audit found no copied copyleft); the gaps were all binary-distribution (Layer-2). This makes the shipped artifacts honest: - Windows host + client: bundled FFmpeg BtbN gpl-shared -> lgpl-shared (AMF/QSV/decode unaffected; the GPL-only x264/x265 were never used), and ship the FFmpeg LGPL notice + license text in the installer + MSIX (licenses/). - THIRD-PARTY-NOTICES.txt generated + bundled into installer/MSIX/deb/rpm. Offline generator (scripts/gen-third-party-notices.{py,sh}) + cargo-about config (about.toml/ .hbs) with a permissive-only accepted-license allow-list as a copyleft regression gate. - Reword the win32u GPU-preference hook comments to reflect independent reimplementation (no Apollo/Sunshine GPL-3.0 source copied). - README dual-license + inbound=outbound contributor clause + non-affiliation trademark disclaimer; new CONTRIBUTING.md. - LICENSE files into the standalone driver + vk-layer workspaces; deb copyright holder aligned to "unom and the punktfunk contributors". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:20:38 +00:00
enricobuehler	54d9246ca7	fix(deps): bump quinn-proto 0.11.14 -> 0.11.15 (RUSTSEC-2026-0185) ... The 0.11.15 bump for S1 (pre-auth out-of-order STREAM reassembly memory exhaustion on the default QUIC listener) was reverted before the original fix commit, so Cargo.lock on main still pinned the vulnerable 0.11.14 and the new cargo-audit CI gate failed. Re-apply and lock it in. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 06:05:10 +00:00
enricobuehler	91bb955d0c	style(host): rustfmt the security-fix wrapping (cargo fmt --all --check) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-29 05:19:22 +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	6f903f79bc	fix(host/security): Windows DACL hardening — close audit #2, #3, #8, #11 ... Windows local-privilege findings from design/security-review-2026-06-28.md. These are #[cfg(windows)] paths (verify in CI / on the box; this Linux dev VM can't compile MSVC). They follow the existing write_secret_file/icacls patterns; the cross-platform parts are cargo check/clippy/test green. - #2 [HIGH]: route the mgmt bearer token write through the shared write_secret_file so it gets the SAME Windows DACL (SYSTEM/Administrators) as the host key — it was cfg(unix)-only and left Users-readable, leaking full mgmt admin authority to any local user. - #3 [HIGH]: create_private_dir now applies a restrictive DACL to the %ProgramData%\punktfunk config directory (re-owns to Administrators to defeat a pre-creation, strips inheritance, SYSTEM/Admins/OWNER full + Users read-only) so a local user can't plant host.env/apps.json that the SYSTEM service trusts (env/arg-injection LPE). host.env is now written DACL-locked via write_secret_file; the config + logs dirs go through create_private_dir. - #8 [LOW]: write the web-console password file empty, icacls-lock it, THEN write the secret — closes the brief write-then-icacls TOCTOU window. - #11 [LOW]: the SYSTEM logs dir is DACL-locked (Users read-only, no create), so a local user can't pre-plant host.log as a reparse/hardlink to redirect SYSTEM's writes (subsumed by the #3 dir lockdown). Deferred: #5 (host<->UMDF gamepad/IDD shared-section Everyone:GENERIC_ALL). The section SDDL is intentionally permissive because the UMDF driver opens it under a restricted token of unknown SID/integrity; scoping it blind would likely break the live-validated gamepad/IDD pipeline, so it needs on-box validation first. Tracked in the report. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 22:14:19 +00:00
enricobuehler	3532e35b75	fix(host/security): close audit findings S1,#1,#4,#10,#12,#7,#6,S2-S6 (Linux/cross-platform) ... Remediations from design/security-review-2026-06-28.md verified on Linux (cargo check/clippy/test green; Windows-gated paths verify in CI): - S1 [HIGH]: bump quinn-proto 0.11.14 -> 0.11.15 (RUSTSEC-2026-0185, pre-auth out-of-order STREAM reassembly memory exhaustion on the always-on default QUIC listener). - #1 [HIGH]: remove the unauthenticated nvhttp `GET /pin` endpoint; the GameStream PIN is delivered ONLY via the bearer-gated mgmt API, so a network client can no longer submit its own displayed PIN and self-pair. - #4 [HIGH->MED]: gate the unauthenticated RTSP/UDP media plane on a paired `/launch` and bind it to the launching client's source IP (threaded through the HTTPS handler), so an unpaired peer can neither start capture on an idle host nor ride a paired client's active launch. - #12: bound concurrent parked pairing waiters (MAX_PARKED_WAITERS) so a pre-auth peer can't pin unbounded 300s handshakes. +regression test. - #10: throttle the per-packet ENet control GCM-decrypt-failed warn (exponential backoff) so a junk flood can't spam the log. - #7 [MED->LOW]: serialize all process-global env mutation on the session-setup path under a new vdisplay::ENV_LOCK (apply_session_env / apply_input_env / the launch-cmd set_var / the gamescope env read), so concurrent native sessions can't race set_var/getenv (data-race UB -> host-wide DoS). Full per-session SessionContext threading remains a follow-up for cross-session value confusion. - #6 [MED]: move the gamescope EIS socket relay from world-writable /tmp to $XDG_RUNTIME_DIR (per-user 0700) and reject a symlinked relay file, so a local user can't intercept (keylog) or deny the remote session's input. - S2: a malformed client Opus mic frame now drops that frame instead of tearing down the shared host-lifetime virtual mic (cross-session DoS). - S3: track held buttons/keys in capped HashSets (was unbounded Vec with O(n) scans) so a paired client can't grow per-session input state. - S5: reject fps==0/absurd at the open_video chokepoint (covers Hello, ANNOUNCE, Reconfigure) so the encoder time_base/pts math can't div-by-0. - S6: bound the shared mic mpsc (drop-newest when full). - S4: cap Epic launcher-cache reads (catcache.bin/.item) so a planted giant can't OOM the host during library enumeration. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 22:06:24 +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	26c6c939a2	fix(ci/apple): set CMAKE_POLICY_VERSION_MINIMUM=3.5 for the vendored libopus ... With cmake now found, Homebrew's CMake 4 refuses the vendored libopus's `cmake_minimum_required(VERSION <3.5)` ("Compatibility with CMake < 3.5 has been removed"). Export CMAKE_POLICY_VERSION_MINIMUM=3.5 (the same knob the Windows build uses) so the cmake crate's child cmake configures the audiopus_sys libopus. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:49:27 +00:00
enricobuehler	b6e6f2bff5	fix(ci/apple): locate Homebrew explicitly for the cmake install ... The self-hosted macOS runner runs steps with `bash --noprofile --norc`, so Homebrew's bin dir is not on PATH — the previous `brew install cmake` died with `brew: command not found` (exit 127). Find brew at its known prefix, install cmake only if missing, and export the brew bin dir to $GITHUB_PATH so the subsequent xcframework build (audiopus_sys → vendored libopus) actually finds `cmake`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:47:05 +00:00
enricobuehler	e3034958ee	fix(ci): unbreak the Apple + Windows-client builds after the surround-audio merge ... The 5.1/7.1 surround commit (75627c8) added in-core Opus, which broke two CI jobs that the merge didn't touch: * Windows MSIX client: clients/windows/src/main.rs's headless `SessionParams` initializer was missing the new `audio_channels` field (the GUI path sets it from settings). Default the CLI/test path to stereo (2), matching trust.rs. * Apple xcframework (apple.yml + release.yml): in-core Opus decode pulls `audiopus_sys`, which builds a vendored *static* libopus via CMake when pkg-config finds no system Opus — keeping the xcframework self-contained (no runtime libopus.dylib on end-user Macs/devices). The self-hosted macOS runner lacked `cmake`; install it self-healing before every xcframework build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:44:44 +00:00
enricobuehler	8672026e97	fix(host): clear clippy doc_lazy_continuation in the 4:4:4 docs ... A line-wrap put `+`/`*`-style markers at the start of two doc lines, which clippy (Windows host job, rust 1.96) reads as markdown list items whose unindented follow-on lines trip `doc_lazy_continuation` under `-D warnings`: - encode/windows/nvenc.rs `chroma_444` field doc (the failing Windows-host clippy job): "+ chromaFormatIDC = 3" → "and chromaFormatIDC = 3". - encode/linux/vaapi.rs `probe_can_encode_444` doc: "+ validate" → "and validate" (last line, didn't fire yet, but fragile — fixed pre-emptively). Pure doc rewording, no behaviour change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:38:07 +00:00
enricobuehler	75627c8afe	feat(audio): end-to-end 5.1/7.1 surround across the native path + all clients ... Adds negotiated 5.1/7.1 surround to the punktfunk/1 protocol and every client (previously stereo-only): - core: new shared `audio` layout table (LAYOUT_51/71 + identity multistream mapping, canonical wire order FL FR FC LFE RL RR SL SR); Hello/Welcome `audio_channels` negotiation via the trailing-byte back-compat pattern (old peers fall back to stereo); C-ABI `punktfunk_connect_ex6`, `punktfunk_connection_audio_channels`, and in-core multistream decode `punktfunk_connection_next_audio_pcm` for embedders without a multistream Opus decoder. Real-libopus channel-identity round-trip test. - host: native audio thread captures + Opus-(multi)stream-encodes at the negotiated count (with a cross-session cached-capturer channel-mismatch fix); GameStream surround unified onto the safe `opus::MSEncoder`, dropping `audiopus_sys` (~4 unsafe blocks) and un-gating Windows GameStream surround; WASAPI loopback capture relaxed to 2/6/8 with the correct dwChannelMask. - clients: Linux (PipeWire), Windows (WASAPI), Android (AAudio) decode via `opus::MSDecoder` + render multichannel; Apple decodes in-core to PCM → AVAudioEngine with an explicit wire-order channel layout; each gains a Stereo/5.1/7.1 setting. `punktfunk-probe --audio-channels N` is the headless validator. Verified on Linux: core/host/linux/probe test suites + the Android Rust (cargo-ndk) build, clippy -D warnings, and rustfmt all green. Windows/Apple builds, all on-glass checks, and the live native loopback are pending (CI / a free box). Also lands the concurrent in-tree HEVC 4:4:4 host work (PUNKTFUNK_444): it shares the same touched files (quic.rs, punktfunk1.rs, encode/*, ...) and so cannot be committed separately from the surround changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-28 21:11:05 +00:00
enricobuehler	6383e5f4fd	feat(client/android): CI screenshot capture via Roborazzi ... Play-listing/marketing screenshots of the Compose client rendered on the host JVM by Roborazzi (Robolectric Native Graphics) — no emulator, GPU, KVM, host, or JNI core. Five scenes render the REAL composables with embedded mock state under a forced brand palette (Material You has no wallpaper to seed from on the JVM): hosts grid, settings, TOFU + PIN dialogs, and the live stats HUD. Validated 5/5 locally. - New JVM unit-test source set (app/src/test) + Roborazzi/Robolectric test deps; @Config(sdk=36) is mandatory (no android-all jar for compileSdk 37) and the animation clock is paused so a text-bearing scene reaches idle. - kit: `-PskipRustBuild` skips the cargo-ndk native build so the JVM-only test job needs no Rust/NDK; normal APK/AAR builds are unchanged. - Widen BrandDark / StatsOverlay to internal so the tests can use them. - Standalone best-effort tag-gated workflow; PNGs upload as a 30-day artifact. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 15:05:54 +00:00
enricobuehler	6a93d164a0	feat(client/linux): CI screenshot capture ... Host-free UI screenshots of the GTK4/libadwaita client under a virtual X display (clients/linux/tools/screenshots.sh) — Xvfb + software GL (llvmpipe) + a root-window grab, one app launch per scene. PUNKTFUNK_SHOT_SCENE routes build_ui to render one mock-populated REAL view (hosts grid / settings dialog / TOFU + PIN dialogs) and print PF_SHOT_READY once it has settled; the saved-hosts grid is driven by a seeded client-known-hosts.json. NON_UNIQUE in shot mode so back-to-back launches don't collide. The stream scene is deferred — its page needs a live NativeClient. Gated to stable release tags in a standalone best-effort workflow that builds the client in the rust-ci image and captures under Xvfb; PNGs upload as a 30-day artifact, not committed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-28 15:05:38 +00:00