5 Commits

Author	SHA1	Message	Date
enricobuehler	c21549c136	feat(host/windows,drivers): gamepad driver attach/heartbeat health surfaced in logs ... The gamepad drivers have no IOCTL plane (hidclass gates the stack), so until now the host had ZERO visibility into whether a driver ever bound: a pad could be "created" with no driver installed and nothing was logged. Two health fields are carved from reserved shm space (layout-compatible; pf-driver-proto pins the offsets): driver_proto — stamped by pf-xusb at device add + per serviced XInput IOCTL (movement = the game-visible path) and by pf-dualsense/DS4 from its ~125Hz timer — and driver_heartbeat. Host-side, every pad owns a DriverAttach watcher fed from the existing service() poll: INFO on attach (WARN on proto mismatch), and after 3s of silence ONE diagnosis WARN combining a cached pnputil /enum-drivers store check, the devnode's CM problem code (CM_Locate_DevNodeW/CM_Get_DevNode_Status on the instance id now captured from the create callback, with plain-language hints: 28 = not installed, 52 = signature/Memory Integrity, …) and the driver's debug log path. Also fixes a real bug both SwDeviceCreate wrappers shared: the 10s WaitForSingleObject result was ignored and the callback HRESULT zero-initialised, so a PnP timeout read as SUCCESS (now E_FAIL init + explicit timeout error). Failure-mode table: design/gamepad-driver-health.md. Linux workspace green; Windows host + drivers CI-compile only, on-box recipe at the bottom of the design doc. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:33:56 +00:00
enricobuehler	12843fe253	feat(protocol,clients): codec preference negotiation + Linux client decodes per Welcome (Phase 2a) ... Adds a client-selectable **preferred codec** and wires the core + ABI + probe + Linux client to negotiate and decode it. (Windows/Apple/Android follow in 2b.) **Core:** - `Hello.preferred_codec` (a single CODEC_* bit, 0 = auto) — a soft hint appended after `video_codecs`. `resolve_codec(client, host, preferred)` now honors the preference when the host can also emit it, else falls back to precedence (HEVC > AV1 > H.264). Roundtrip + preference tests. - `NativeClient::connect` takes `video_codecs` + `preferred_codec`; `NativeClient.codec` exposes the resolved `Welcome.codec`. - ABI: `punktfunk_connect_ex7` (adds the two codec params; `ex6` delegates to it advertising HEVC-only) + `punktfunk_connection_codec` getter + `PUNKTFUNK_CODEC_{H264,HEVC,AV1}` constants (drift-guarded against the wire values). Header regenerated. **Host:** passes `hello.preferred_codec` into `resolve_codec`. **probe:** `--codec h264|hevc|av1|auto` sets the preference (still advertises it can decode all three); the dump extension already follows the resolved codec. **Linux client:** advertises the codecs FFmpeg can actually decode (`decodable_codecs()`), threads the user's `codec` setting as the preference, and builds the decoder — both the software and VAAPI paths, plus the mid-session VAAPI→software demotion — from the negotiated `Welcome.codec` instead of hardcoding HEVC. New "Video codec" dropdown in Preferences (Automatic/HEVC/H.264/AV1). Live-validated on the dev box: probe `--codec hevc` against a software (H.264-only) host resolves to H.264 (graceful soft-preference fallback), no failure. clippy + core (57) + host (133) tests green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-02 00:13:26 +00:00
enricobuehler	d6596ff81b	docs: rework client/crate READMEs, add missing ones ... Rework the client READMEs to be accurate and inviting to first-time visitors, and fill in the gaps where crates and tools had none. - Rewrite clients/{apple,android,decky} READMEs (features-first, trim dense internal narrative; drop the stale "one session at a time" / "renegotiation not implemented" section from the Apple README). - Add READMEs for clients/{linux,windows,probe}, which had none. - Add crate READMEs for punktfunk-host, punktfunk-core, pf-driver-proto. - Add brief READMEs for tools/{loss-harness,latency-probe}. - Fix packaging/README duplicate "Option B" heading (bootc -> Option C). - Fix docs-site/README stale docs/ -> design/ reference. - De-stale packaging/windows/drivers/pf-dualsense README (drop "M0 spike" / external-checkout framing; reflect in-tree workspace + shipped + installer-bundled + multi-pad), keeping the driver-authoring lore. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-01 19:31:06 +00:00
enricobuehler	a9cca82fb8	chore(windows): clean up build/packaging - drop vendored driver binaries + the LLVM-21 pin ... Now that the drivers build from source in CI, remove the dead checked-in binaries and the toolchain cruft they left behind: - Delete packaging/windows/{pf-vdisplay,gamepad-drivers}/ (the prebuilt .dll/.inf/.cat/.cer). pack-host-installer.ps1 builds + signs all three drivers from the drivers/ workspace and nothing reads the vendored dirs anymore; stage-pf-vdisplay.ps1's -VendorDir is now a mandatory build-output path, not a vendored default. - Drop the LLVM-21 pin. The vendored bindgen 0.71->0.72 bump (the shipping pack already builds green on the runner-default clang 22) retired the bindgen-0.71 layout-test overflow that needed LLVM 21.1.2, so windows-drivers.yml + provision-windows-wdk.ps1 no longer install/point at C:\llvm-21 (~898 MB off a fresh provision) - both driver builds now use one toolchain (clang 22 + bindgen 0.72). - pack -SkipBuild on the gamepad build (build-pf-vdisplay.ps1 already builds the whole workspace), build-web.ps1 reaps a stale node too, deploy-dev.ps1 nefconc path + comments. - Reword the vendored-driver references (build scripts, .iss, READMEs, the vite web-bundle comment) to the build-from-source reality. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:16:46 +00:00
enricobuehler	92e68024f1	fix(windows-installer): build the gamepad drivers from source in CI too ... Fold the pf-dualsense (DualSense / DualShock 4) and pf-xusb (Xbox 360 / XInput) UMDF drivers into the in-tree drivers workspace (their source had stale ../../crates/wdk-* path-deps from before the wdk vendoring reorg and could no longer build at all) and build them from source per release, exactly like pf-vdisplay - same anti-stale reasoning. One `cargo build --release` now builds all three drivers against the vendored wdk-sys (incl. the bindgen 0.72 pin), and build-gamepad-drivers.ps1 signs pf_dualsense + pf_xusb (clear FORCE_INTEGRITY -> sign dll -> stampinf -> Inf2Cat -> sign cat) with one shared cert + .cer, matching the layout install-gamepad-drivers.ps1 expects. pack-host-installer.ps1 builds + stages them instead of the retired checked-in binaries. Validated on the runner: the whole workspace (pf-vdisplay + pf-dualsense + pf-xusb) builds with CARGO_TARGET_DIR=C:\t set, and build-gamepad-drivers.ps1 produces signed pf_dualsense.{dll,inf,cat} + pf_xusb.{dll,inf,cat} + the .cer. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 15:08:40 +00:00