10 Commits

Author	SHA1	Message	Date
enricobuehler	0c17343a50	fix(mgmt): version-agnostic OpenAPI drift test + regenerate the 0.5.0 snapshot ... The snapshot comparison now normalizes info.version on both sides and compares structurally — a version bump alone can never invalidate the checked-in spec again (the 0.5.0 release tripped on exactly this; the API surface is what drift-control protects). Snapshot regenerated so the docs-site copy shows the current version. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 17:53:33 +00:00
enricobuehler	8af1a15aa6	feat(host,web): host log ring + GET /api/v1/logs + console Logs page ... Remote debugging without shell access: a tracing layer tees every event at DEBUG-and-up — independent of the RUST_LOG filter gating stderr/host.log, so console-side debugging never needs a restart — into a bounded in-memory ring (log_capture.rs, 4096 newest entries, OnceLock singleton like config()), installed at both init sites (stderr path in main, the Windows service file path). The mgmt API serves it cursor-paged at GET /api/v1/logs?after=&limit= — bearer-only and deliberately NOT on the mTLS cert allowlist (log lines can name client identities and host paths). The web console grows a Logs page (follow/pause · min-level filter · text search · eviction-gap badge); polling self-paces: a non-empty page advances the after-cursor (new query key → immediate refetch, drains backlogs), an empty page idles at the 2s interval. OpenAPI regenerated; ring pagination/eviction, layer wiring, and the authed route are unit-tested; Storybook story included. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 16:33:56 +00:00
enricobuehler	019f2677a7	feat(host,web): multi-GPU selection — GPU inventory + preference API, web-console GPU card ... - new crate::gpu (compiled on all platforms so the OpenAPI doc stays platform-independent): DXGI / sysfs GPU inventory with reboot-stable ids (PCI vendor:device + occurrence — LUIDs are per-boot), persisted auto/manual preference (<config>/gpu-settings.json, atomic temp+rename with in-memory rollback), one selection with precedence console preference > PUNKTFUNK_RENDER_ADAPTER > max VRAM and graceful fallback when the preferred GPU is absent, plus a live "in use" record (RAII session guard wrapped around every encoder open_video returns) - fix: windows_gpu_vendor derived the encoder backend from DXGI adapter 0 instead of the selected render adapter — on a hybrid box (e.g. Intel iGPU at index 0 + NVIDIA dGPU) the backend could disagree with the GPU the capture ring / IddCx render pin sit on. The NVENC 4:4:4 probe now also runs on the selected adapter (was: OS default), the codec/4:4:4 probe caches are keyed per selected GPU (were process-lifetime OnceLocks), and an explicit PUNKTFUNK_ENCODER conflicting with the selected GPU's vendor warns up front - mgmt API: GET /api/v1/gpus (inventory + mode + preferred + next-session selection with reason + in-use GPU/backend/session-count) and PUT /api/v1/gpus/preference (validates mode/gpu_id before writing); openapi.json regenerated; the vdisplay render pin now also engages for a console preference (not just the env pin) - web console: GPU card on the Host page — list with vendor + VRAM, Automatic / Prefer controls, Preferred / Next session / "In use · backend" badges, missing-preferred-GPU warning and env-pin note; en + de messages - Linux: a matched manual preference picks the VAAPI render node and the NVENC-vs-VAAPI auto choice; auto mode is exactly the previous behavior Validated live on the hybrid laptop (RTX 3500 Ada + Intel Arc Pro, which enumerates twice — the occurrence ids disambiguate): enumerate, prefer, bad-id 400, restart persistence, auto-restore keeping the stored pick. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-02 13:57:26 +02:00
enricobuehler	7975a95cd6	chore(release): regenerate api/openapi.json for 0.4.2 ... The OpenAPI info.version tracks the crate version, so the 0.4.2 bump (0604c4f) left api/openapi.json stale at 0.4.1 and would redden mgmt::tests::openapi_document_is_complete_and_checked_in. The API surface is unchanged since the last regen (ecbbff5 already refreshed it for the new library endpoints), so this is the version string only. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-07-01 14:40:51 +00:00
enricobuehler	ecbbff5544	feat(apple): gamepad ui	2026-07-01 15:14:19 +02:00
enricobuehler	2262332150	chore(release): regenerate api/openapi.json for 0.4.1 ... The OpenAPI `info.version` tracks the crate version, so the 0.4.1 bump (4563a04) left api/openapi.json stale at 0.3.0 and reddened `mgmt::tests::openapi_document_is_complete_and_checked_in`. The API surface is unchanged since v0.4.0, so this is the version string only. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-30 20:18:19 +02: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	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	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	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