78 Commits

Author	SHA1	Message	Date
enricobuehler	8ae161fe61	docs(windows): README - install via punktfunk-host.exe driver install / web setup (not .ps1) ... Option A removed install-pf-vdisplay.ps1 / install-gamepad-drivers.ps1 / web-setup.ps1; the installer now calls the exe subcommands. Drop the stale table rows + reword the install-flow + 'thin installer' notes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:46:05 +00:00
enricobuehler	125a51d81d	feat(windows-installer): move driver + web install into the host exe (ASCII root fix) ... Port the three install-time PowerShell *files* (install-pf-vdisplay.ps1, install-gamepad-drivers.ps1, web-setup.ps1) into punktfunk-host.exe subcommands: `driver install [--gamepad] --dir <stage>` and `web setup --app-dir <app> [--password-file <f>]` (windows/install.rs). Why: PowerShell 5.1 reads a BOM-less .ps1 FILE in the machine ANSI codepage, so a stray non-ASCII byte mis-decodes and aborts on a non-English box - exactly how the pf-vdisplay driver install silently failed. A compiled subcommand drives the same external tools (certutil/pnputil/nefconc/schtasks/netsh/icacls) as fixed string literals, with no file-codepage surface. (The .iss's INLINE -Command PowerShell is a command-line string, not a file read, so it's unaffected and stays.) - windows/install.rs: faithful port - cert trust, gated nefconc node create + pnputil for pf-vdisplay; pnputil per-inf for gamepads; web-password ACL, the PunktfunkWeb task (generated UTF-16 XML), firewall rule, start. Best-effort (a hiccup warns, never aborts). - punktfunk-host.iss [Run]: call the exe instead of `powershell -File`; drop the web-setup.ps1 staging + WebSetup define; WebSetupParams emits --app-dir/--password-file. - pack-host-installer.ps1: stop copying the three install scripts into the stages. - delete the three .ps1 files. The `mod install;` + dispatch arms in main.rs landed in the preceding docs commit (swept up by a concurrent commit); this commit adds the module + installer wiring. CI-compile-validated via windows-host; the install path is on-glass-validated on the next canary install (the test box is offline). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 16:43:18 +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	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	7ab0661ddc	fix(windows-installer): escape the brace in the [UninstallRun] PowerShell so ISCC compiles ... The Bug C [UninstallRun] one-liner had `ForEach-Object { Stop-Process ... }`; Inno Setup parses `{...}` as a constant in [Run]/[UninstallRun] sections, so ISCC aborted with "Unknown constant" and the windows-host pack failed at the ISCC step (the host build, clippy, driver build + web smoke-boot all passed). Escape `{` as `{{`. The same one-liner in the [Code] StopWebConsole proc is inside a Pascal string literal, so its brace is literal and must NOT be escaped. Validated: ISCC now parses past [UninstallRun] + [Code] (fails only later on the absent dummy payload). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 15:15:07 +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
enricobuehler	64abce6daa	fix(windows-installer): pf-vdisplay CI build - default target dir + non-fatal cat guard ... The CI driver build panicked in wdk-sys's build script - "a Cargo.lock file should exist in the same directory as the top-level Cargo.toml". wdk-build's find_top_level_cargo_manifest() walks UP from OUT_DIR for the first ancestor holding a Cargo.lock and explicitly does NOT support non-default target dirs - but build-pf-vdisplay.ps1 pointed CARGO_TARGET_DIR at an out-of-tree dir (to isolate from CI's shared C:\t), so no ancestor of OUT_DIR had a Cargo.lock. Build into the driver workspace's DEFAULT target dir instead (its ancestors include the driver Cargo.lock); the driver's own [workspace] already isolates it and it has no CMake deps needing C:\t. Also make the Test-FileCatalog coverage guard non-fatal (it can't open a catalog signed by a not-yet-trusted cert). Validated on the runner with CARGO_TARGET_DIR=C:\t. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:58:20 +00:00
enricobuehler	bdfab8e0d5	fix(windows-installer): build pf-vdisplay from source in CI; ASCII scripts; upgrade-safe web console ... The pf-vdisplay virtual-display driver shipped as a checked-in PREBUILT binary that went stale - two field failures on a fresh install (live-repro'd on a German-locale Dell laptop): * Bug A (every box): a repo-wide rename edited the vendored pf_vdisplay.inf but never re-signed pf_vdisplay.cat, so the catalog stopped covering the INF -> `pnputil /add-driver` fails SPAPI_E_FILE_HASH_NOT_IN_CATALOG -> driver never installs -> every session dies "pf-vdisplay driver interface not found". * the prebuilt binary also predated IOCTL_SET_RENDER_ADAPTER (added to the driver source after the vendor freeze) that the host needs to pin the IDD render GPU on hybrid/Optimus boxes. Fix: build the driver FROM SOURCE every release (build-pf-vdisplay.ps1, wired into pack-host-installer.ps1) so .dll/.inf/.cat are always in lockstep and current driver features ship. The runner's clang 22 made the driver's pinned bindgen 0.71 emit opaque structs (157 layout-assert errors), so bump the vendored wdk-sys/wdk-build bindgen 0.71 -> 0.72 (+ lock). The build self-signs the driver per build (installer trusts the bundled .cer); a stable DRIVER_CERT_PFX_B64 secret can override. * Bug B (non-English boxes): the installer runs install-pf-vdisplay.ps1 etc. via powershell.exe (5.1), which reads a BOM-less script in the ANSI codepage - an em-dash's trailing 0x94 byte becomes a curly quote on German Windows-1252 and the script aborts "unterminated string", so the driver never installed (the gamepad script survived only because it was already ASCII). Scrub every installer-run .ps1/.cmd to ASCII + add a CI gate that fails on any non-ASCII so it can't regress. * Bug C (upgrades): nothing stopped the OLD web console before re-registering its task, so a stale server kept :3000 (the new one restart-looped on EADDRINUSE) and served a broken old bundle (500 on /login). Stop + reap it (runtime-agnostic, by the :3000 listener owner) in web-setup.ps1 and in the .iss before the file copy + on uninstall. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 14:33:34 +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
enricobuehler	bd05bc8c30	fix(windows): clippy/build cleanups the on-glass build surfaced (-D warnings) ... Built the host crate (`cargo clippy --features nvenc -D warnings`) and the driver workspace (`cargo build`) on the RTX box — the project's intended Windows gate, which `cargo check` (what the goal1/§2.5 work used) never runs. It surfaced lint issues accumulated across the goal1 / §2.5 / this-session Windows work: - 9× redundant `as *mut c_void` after `.as_raw_handle()` (already `*mut c_void`): idd_push.rs (3, this session), service.rs (3, this session), manager.rs (3, pre-existing §2.5 — my OwnedHandle work copied the idiom). Removed the casts + the now-unused `use std::ffi::c_void` in idd_push.rs / manager.rs (service still uses it). - `if_same_then_else` in session_plan.rs::resolve_topology (pre-existing goal1 stage 3): collapsed the two `false` arms into one condition (behavior identical). - `unused_unsafe` in the driver `pod_init!` macro: it expands at call sites already inside an `unsafe` block, where its own `unsafe` is redundant — `#[allow( unused_unsafe)]` (needed at the non-unsafe sites, redundant at the nested ones). After these, BOTH builds are clean on the box — validating the whole session's blind Windows + driver work compiles + passes clippy on real hardware. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 07:15:00 +00:00
enricobuehler	6b3cbce120	wip: host latency/GPU-contention notes + Windows packaging tweaks ... Pre-existing working-tree changes committed to the branch on request: the gpu-contention investigation doc, host-latency-plan additions, and small pack-host-installer / stage-pf-vdisplay packaging-script edits. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 06:53:09 +00:00
enricobuehler	bf577044f1	refactor(windows-drivers): pod_init! macro — 27 unsafe { mem::zeroed() } POD inits -> 1 (Goal-3 #3) ... The driver zero-initialised C POD structs (IddCx/WDF descriptors) with 27 scattered `let mut x: T = unsafe { core::mem::zeroed() };`, each carrying its own `// SAFETY` about the all-zero bit pattern being valid + the caller setting `.Size` etc. right after. Replace with one `pod_init!(T)` macro (in log.rs, reachable everywhere via the existing `#[macro_use] mod log;` — same mechanism as `dbglog!`) that owns the single `unsafe { zeroed::<T>() }` + the SAFETY rationale. All 27 sites (adapter 6, callbacks 3, entry 4, monitor 10, swap_chain_processor 4) now read `let mut x = pod_init!(T)`. Zero behavior change (mem::zeroed semantics identical); the type is passed explicitly so no inference depends on the removed annotation. 27 `unsafe` blocks → 1. Driver still `deny(unsafe_op_in_unsafe_fn)`-clean (the macro expands to an explicit `unsafe {}`; the one nested-in-user-unsafe site is fine — no `unused_unsafe` for macro-generated blocks). Driver-only (CI-gated); adversarially reviewed (macro scoping, all sites, no leftover raw zeroed). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 06:01:02 +00:00
enricobuehler	00cf51d610	refactor: rename pf-vdisplay-proto -> pf-driver-proto (it spans all drivers) ... The shared host<->driver ABI crate already contains more than the virtual display: the IDD-push frame ring + control plane AND the gamepad shared-memory layouts (XusbShm / PadShm). "pf-vdisplay-proto" was a misnomer — the name now represents all the drivers it serves. Mechanical rename, no behavior change: - git mv crates/pf-vdisplay-proto -> crates/pf-driver-proto (package name + path-deps in the host crate and the driver workspace). - pf_vdisplay_proto -> pf_driver_proto across host + driver Rust, both Cargo.lock files, the workspace members, the CI path triggers (windows-drivers.yml), and the docs/INF comments. The runtime Global\pfvd-* shared-object names are a SEPARATE contract and are deliberately untouched (host<->driver name matching). - The pf-vdisplay DRIVER crate + its INF service name (Root\pf_vdisplay, UmdfService=pf_vdisplay, pf_vdisplay.dll) are unchanged — only the full `pf_vdisplay_proto` token was replaced, never the `pf_vdisplay` driver name. Linux-verified: cargo test -p pf-driver-proto (const size-asserts compile) + cargo clippy -p punktfunk-host -D warnings clean; Cargo.lock regenerated. The driver-workspace side (path-dep + imports + its Cargo.lock) is Windows-CI-gated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-26 05:38:21 +00:00
enricobuehler	8cde8621ce	fix(windows-drivers): reclaim pf-vdisplay monitor ids on REMOVE (P1, slot-reclaim) ... The driver assigned each virtual monitor a monotonically-increasing NEXT_ID used as the EDID serial / IddCx ConnectorIndex / container GUID, and never reclaimed it on REMOVE. Under sustained ADD/REMOVE churn the connector index kept climbing, so IddCx/PnP allocated a NEW OS target slot every cycle and orphaned the old one (ghost "Generic Monitor (punktfunk)" nodes) until the adapter's target capacity was exhausted and ADD failed 0x80070490 ERROR_NOT_FOUND. Fix: `create_monitor` now allocates the LOWEST free id (`alloc_monitor_id`, computed under the MONITOR_MODES lock with the push) instead of a counter, so a departed monitor's id is reclaimed and a fresh ADD reuses its target slot rather than orphaning it. With <= N live monitors the id stays bounded to 1..=N+1. Deleted the now-unused NEXT_ID + AtomicU32/Ordering import. CI-compile-gated only — the wedge reproduces solely under sustained churn on the RTX box, so this needs an on-glass reconnect-storm A/B to confirm (box is ephemeral/down). Marked on-glass-pending in windows-host-rewrite.md §4; keep reset-pf-vdisplay.ps1 as the recovery until validated. NOT to be relied on (or merged to main) until that A/B passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 22:11:36 +00:00
enricobuehler	0255a8289c	docs(windows-host): consolidate 5 scattered docs into one current source of truth ... The Windows-host docs were scattered across a design plan, a staged-refactor plan, an audit, an audit-remediation tracker, and a game-capture-bug analysis — several badly stale (the audit/remediation predate the Goal-1 branch landing and call DONE items "not started"). Verified the true state of every audit finding / goal / milestone against current code+git (4-agent workflow), then rewrote windows-host-rewrite.md as ONE consolidated, accurate doc: - §1 Status scorecard (Goals 1-3, M0-M6, GB1, audit P0/P1/P2) with DONE/PARTIAL/ OPEN + commit evidence. - §2 Architecture as-built (layering, HostConfig→SessionPlan→SessionContext, the VirtualDisplayManager ownership model, IDD-push-primary capture incl. secure desktop + GB1 recovery, encode/EncoderCaps, pf-vdisplay-proto, the driver, service/packaging). - §3 Validated invariants (the jewels). - §4 Prioritized open tasks (the genuine remaining work). - §5 Operations (RTX-box recipe, CI, env, build). - §6 Deep reference (/INTEGRITYCHECK answer, the 6 iddcx bindgen knobs, the driver port checklist, resolved decisions). Deleted the four now-redundant docs (content folded in; history in git): windows-host-goal1-plan.md, windows-host-rewrite-audit.md, windows-host-rewrite-remediation.md, windows-host-rewrite-game-capture-bug.md. Repointed the 6 code/proto/driver doc-comment refs that targeted them at the consolidated windows-host-rewrite.md sections. Linux cargo check clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 21:57:23 +00:00
enricobuehler	e119aa50e9	feat(windows-packaging): dev-iteration scripts — reset + redeploy pf-vdisplay driver ... Today's manual driver recovery (wedged under ADD/REMOVE churn → ERROR_NOT_FOUND) and the manual host-stop/install/host-start dance around drivers/deploy-dev.ps1 are now two scripts: * reset-pf-vdisplay.ps1 — recover a wedged driver: stop host → pnputil /remove-device the ghost "Generic Monitor (punktfunk)" nodes → Disable+Enable the adapter (Restart-PnpDevice doesn't exist on the box PS) → start host. No reboot (the box boots to Proxmox). -Verify probes to confirm ADD recovered. * redeploy-pf-vdisplay.ps1 — one-shot dev redeploy wrapping deploy-dev.ps1 with the host stop/start (the running host holds the driver DLL) + a post-install adapter reload (pnputil updates the store but the live device keeps the old binary). Both standalone (don't touch deploy-dev.ps1). README gains a "Dev iteration on the test box" section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 20:48:32 +00:00
enricobuehler	cd591514ad	feat(windows-drivers): EvtCleanupCallback + single-identity dedup; document state ownership (E1) ... EvtCleanupCallback on the WDFDEVICE (entry.rs + callbacks::device_cleanup): on device removal (PnP/unload) drop every monitor's swap-chain worker via monitor::cleanup_for_device_removal (joins threads, IddCx-free — the framework tears the monitors down with the device). Worker threads no longer linger into teardown. Single identity per session (create_monitor): a re-ADD of a still-live session_id departs the stale monitor first, so one session maps to exactly one monitor (no duplicate EDID/target). DeviceContext-owned state (audit §2.5): documented decision NOT to migrate the globals to a Box/AtomicPtr device-owned allocation. The IddCx monitor/mode DDIs receive only an IddCx handle (never the WDFDEVICE/context), so the state MUST be globally reachable (upstream virtual-display-rs is a process-static for the same reason); the globals are already module-encapsulated; and with one devnode + UmdfHostProcessSharing=ProcessSharingDisabled they die with the host process on removal anyway. A pointer variant would only add a host-gone-watchdog-race use-after-free for zero benefit. Verified: driver workspace builds clean on the RTX box (.173). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 16:48:23 +00:00
enricobuehler	a2bd0cd77c	refactor(windows-packaging): delete the superseded vdisplay-driver/ tree (M6) ... The old all-Rust IddCx driver tree (packaging/windows/vdisplay-driver/ — the wdf-umdf-sys 'oracle', 7896 lines) is fully superseded by packaging/windows/drivers/ (wdk-sys / windows-drivers-rs + the owned pf-vdisplay-proto ABI), which is the source of the vendored + installed driver. It was in NO cargo workspace (never built) and NO CI workflow; only stale doc/script refs pointed at it (the confusion the audit + game-capture-bug doc both flagged). Delete it + repoint the build-relevant refs (packaging/windows/README.md, stage-pf-vdisplay.ps1, pack-host-installer.ps1) at drivers/ + drivers/deploy-dev.ps1. The vendored driver (packaging/windows/pf-vdisplay/) is unaffected; docs/windows-virtual-display-rust-port.md keeps its historical mentions as narrative. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 16:37:00 +00:00
enricobuehler	48f980ebb1	feat(packaging): deploy-dev.ps1 for the new-tree pf-vdisplay driver ... Build/sign/install script for the wdk-sys/windows-drivers-rs driver in packaging/windows/drivers/ (the new tree lacked one). Like the old vdisplay-driver/deploy-dev.ps1 but adds the FORCE_INTEGRITY clear (this tree links /INTEGRITYCHECK) and a 9.9.MMdd.HHmm DriverVer (the vendored build is 9.5.*). Verified: deployed the rebuilt driver to the RTX box (.173). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 16:09:27 +00:00
enricobuehler	789ad49bc4	feat(windows-drivers): publish() descriptor guard + log appender (game-capture GB3 groundwork) ... publish() now guards width/height alongside format (CopyResource needs matching DIMS too, else garbage): drops a surface whose descriptor no longer matches the host ring (a fullscreen game mode-set the display) AND logs the actual descriptor once per mismatch episode, so a repro shows exactly what changed (GB1/Stage-0 diagnostic + the Stage-2 width/height guard). log.rs: a process-lifetime, flushed, Mutex-shared append handle (opened ONCE) replaces the per-call open/append — so the swap-chain WORKER thread's lines land. They were hidden (per-call open raced the control thread / could fail under the worker's restricted token), which is exactly why a game-break repro showed no swap-chain-processor lines (bug doc S3). This is the observability foundation the bug doc gates Stage S (S1/S2 driver resilience) on. Needs a driver rebuild + re-vendor to deploy (separate from the GB1 host-only fix). Stage 3 (trim default_modes) deprioritized: GB1 recovers from mode-sets, and trimming risks the live display-activation path. Verified: driver workspace builds clean on the RTX box (.173). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 15:33:11 +00:00
enricobuehler	a755d6eab7	chore(windows-drivers): deny(unsafe_op_in_unsafe_fn) on the driver crates (audit §8 P0) ... Lock in the explicit-unsafe-block discipline so a fn-level 'unsafe' never silently blesses its whole body (the per-site // SAFETY: comments already landed in STEP 8). Builds clean on the RTX box — no fallout. The host-wide unsafe-lint sweep + clippy::undocumented_unsafe_blocks (hundreds of blocks across Linux+Windows) are a larger dedicated follow-up. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 13:19:38 +00:00
enricobuehler	0a7ae5ef09	feat(windows-drivers): host-gone watchdog, SET_RENDER_ADAPTER, log gate, mode bounds ... Audit §4.1: implement the host-gone watchdog — it was dead code (WATCHDOG_PINGS bumped but never sampled, no thread). Every IOCTL now bumps a liveness counter; a watchdog thread reap_orphaned()s monitors (created_at grace) if no IOCTL arrives within WATCHDOG_TIMEOUT_S, so a crashed/TerminateProcess'd host no longer leaves its virtual monitor + swap-chain worker + pooled D3D device wedged until the next CLEAR_ALL. Removes the false 'watchdog thread' comments. Audit §4.2: implement SET_RENDER_ADAPTER (was STATUS_NOT_IMPLEMENTED) via IddCxAdapterSetRenderAdapter, so the host can pin the IDD render to the NVENC GPU on a hybrid iGPU+dGPU box (else the OS-picked iGPU makes the host ring textures un-openable -> DRV_STATUS_TEX_FAIL). Audit §4.4: gate the world-writable C:\Users\Public\pfvd-driver.log behind debug builds / PFVD_DEBUG_LOG (a release build never writes it). Audit §4.5: bounds-check the requested mode in IOCTL_ADD; compute display_info clock_rate in u64 + saturate (the old u32 refresh*(h+4)^2 overflowed/aborted the mode DDI for large modes). Verified: driver workspace builds clean on the RTX box (WDK 26100 + LLVM 21.1.2, MSVC). On-glass functional validation of the watchdog/render-pin is a follow-up (needs a driver reinstall + session). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 12:49:49 +00:00
enricobuehler	a11b0dd3c7	feat(windows-drivers): STEP 8 (3/n) — re-vendor the installer driver from the new wdk-sys tree ... The installer's vendored driver binary (packaging/windows/pf-vdisplay/) was STALE — built from the OLD oracle tree (packaging/windows/vdisplay-driver/, wdf-umdf, SudoVDA-compat GUID), so it was ABI-mismatched with the host (which opens the owned proto GUID 70667664). Re-vendor it from the NEW drivers/ tree so the rewrite's ACTUAL driver is what the installer ships. Built RELEASE on the RTX box from the new tree + the new .inx: cargo build --release -p pf-vdisplay -> FORCE_INTEGRITY clear -> stampinf (DriverVer 06/25/2026,9.5.0625.1614, > the old 06/22) -> Inf2Cat /os:10_X64 -> signtool sign the .cat with punktfunk-ds-test (.cat sig Valid). Replaces the stale .dll/.inf/.cat; the .cer is unchanged (same cert). ON-GLASS VALIDATED (install-test): pnputil /add-driver /install the release package -> clean WUDFHost reload -> Status=OK, init_adapter -> IddCxAdapterInitAsync -> 0x0 (FP16 accepted), IddCxMonitorCreate(id=1) -> 0x0. The shipping installer now installs + loads the real wdk-sys proto-GUID driver, FP16/HDR-capable, monitor-create working. Remaining STEP 8 (recorded in memory, deferred): re-point the stale "built from vdisplay-driver/" comments in stage-pf-vdisplay.ps1 / pack-host-installer.ps1 / packaging README; selector default -> pf-vdisplay unconditional; CI build-sign-or-stale-vendored drift guard; then DELETE the oracle tree. KEEP sudovda.rs (runtime fallback + the backend-neutral CCD helpers pf_vdisplay.rs reuses) and the WGC-relay/DDA secure path (the secure-desktop lock/UAC gate is not yet proven on glass for IDD-push). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 12:18:48 +00:00
enricobuehler	3b21d8ecf8	feat(windows-drivers): STEP 8 (2/n) — give the new pf-vdisplay tree its own .inx ... The new wdk-sys driver tree (packaging/windows/drivers/pf-vdisplay/) had no INF — it borrowed the oracle's (packaging/windows/vdisplay-driver/.../pf_vdisplay.inx), which blocked deleting the oracle. Port it verbatim: the proto-vs-SudoVDA control GUID is registered in CODE (WdfDeviceCreateDeviceInterface), so the INF is GUID-agnostic and identical — HWID Root\pf_vdisplay, UmdfExtensions=IddCx0102, the control-device security DACL, UpperFilters=IndirectKmd, UmdfHostProcessSharing=ProcessSharingDisabled. Prerequisite for the STEP-8 re-vendor (build -> stampinf -> Inf2Cat -> sign the .dll/.cat from the NEW tree into packaging/windows/pf-vdisplay/, replacing the stale oracle-built binary) and for deleting the oracle tree. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 12:03:26 +00:00
enricobuehler	83d3d6384a	refactor(windows-drivers): STEP 8 (1/n) — unsafe-reduction pass (per-site // SAFETY) ... Audit pass over the new pf-vdisplay driver's unsafe surface: 92 per-site // SAFETY comments added across adapter.rs / monitor.rs / entry.rs / callbacks.rs / swap_chain_processor.rs / frame_transport.rs / direct_3d_device.rs (control.rs already had full coverage). COMMENTS ONLY — zero logic, signature, or control-flow change (verified via git diff: every added line is a // SAFETY comment or blank). The dominant gap was the pervasive `core::mem::zeroed()` FFI-struct builds (IDDCX_*/WDF_*/ DISPLAYCONFIG_* C PODs whose all-zero bit pattern is a valid uninitialized/Invalid state, with the required .Size/fields set immediately after) — each now carries a one-line // SAFETY. Plus explicit notes on the two stack/local-pointer-into-FFI hazards (adapter.rs `version` ptr into IddCxAdapterInitAsync; monitor.rs `edid` Vec ptr into IddCxMonitorCreate — both read synchronously before the local drops) and the frame_transport.rs raw-HANDLE / mapped-header derefs + cleanup paths. The already-justified Send/Sync wrappers (SendAdapter, CtxTypeInfo/DevCtxInfo, MonitorObject, Sendable, FramePublisher) were audited — each already carried a // SAFETY. No site needed a code change. First slice of STEP 8 (the SudoVDA drop). Comments-only ⇒ build-neutral; windows-drivers.yml verifies on the next runner build. Remaining STEP 8: re-vendor the installer's driver binary from the new drivers/ tree (the shipping packaging/windows/pf-vdisplay/ binary is still built from the OLD oracle tree with the SudoVDA-compat GUID — ABI-mismatched with the host's proto GUID), add an .inx to the new tree, re-point scripts/README from vdisplay-driver/ to drivers/, flip the selector default to pf-vdisplay, then delete the old oracle tree. Keep sudovda.rs (the runtime fallback + the backend-neutral CCD helpers pf_vdisplay.rs reuses) and the WGC-relay/DDA secure path (the secure-desktop gate is not yet passed on glass). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 12:00:55 +00:00
enricobuehler	6399d2817d	feat(windows-drivers): STEP 7 — HDR/FP16 (validated on-glass: Mac connects WITH HDR) ... The pf-vdisplay driver now advertises HDR/FP16 and the full glass-to-glass HDR path works end-to-end — validated LIVE: the Mac client connected to the .173 host WITH HDR (display_hdr=true, FP16 ring -> NVENC P010). The STEP-3 assumption that FP16 needs a higher UmdfExtensions was WRONG: IddCx0102 + CAN_PROCESS_FP16 + the *2 DDIs works (the oracle proved it; confirmed on-glass IddCxAdapterInitAsync -> 0x0 WITH the FP16 cap set). Driver-only change — the host FP16-ring -> NVENC-P010 path and the HDR EDID were already in place. - adapter.rs: caps.Flags = IDDCX_ADAPTER_FLAGS_CAN_PROCESS_FP16. - entry.rs: register the 6 *2/HDR callbacks (ParseMonitorDescription2, MonitorQueryTargetModes2, AdapterCommitModes2, AdapterQueryTargetInfo, MonitorSetDefaultHdrMetaData, MonitorSetGammaRamp) ALONGSIDE the v1 set (matching the oracle — CAN_PROCESS_FP16 OBLIGATES the *2 DDIs or the framework rejects the adapter at init; STEP 3 rejected FP16 only because they weren't registered). - callbacks.rs: parse_monitor_description2 + monitor_query_modes2 now fill IDDCX_MONITOR_MODE2 / IDDCX_TARGET_MODE2 with BitsPerComponent (8|10 bpc RGB); query_target_info already reports IDDCX_TARGET_CAPS_HIGH_COLOR_SPACE; set_default_hdr_metadata + set_gamma_ramp accept (the gamma one is mandatory under FP16). - monitor.rs: wire_bits() (Rgb 8|10, no YCbCr) + target_mode2(). - EDID + INF UNCHANGED (the EDID already carries the CTA-861.3 BT.2020 + ST.2084/PQ block; the INF stays UmdfExtensions=IddCx0102). Built via the ultracode flow (STEP-7 map workflow -> agent-implement -> box build [driver green] -> deploy -> on-glass HDR). OPERATIONAL NOTE: do NOT Disable/Enable the IddCx devnode to reload it — that leaves the adapter STOPPED in the persisted WUDFHost process (ADAPTER OnceLock survives), so monitor-create then fails with 0xc00002b6 (INDIRECT_DISPLAY_DEVICE_STOPPED). Kill the pf_vdisplay WUDFHost process (or reboot) for a clean adapter re-init. This completes the pf-vdisplay rewrite STEP 0-7, all on-glass validated (loads, adapter inits, monitor appears, swap-chain drain, IDD-push frames at ~235fps, and HDR). Remaining: STEP 8 (unsafe- reduction + delete the old vdisplay-driver tree + the vendored SudoVDA driver + unbundle from the installer = the SudoVDA drop). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 11:31:28 +00:00
enricobuehler	e2f004589c	feat(windows-drivers): STEP 6 — IDD-push FramePublisher (driver) + host migration to proto::frame ... The driver now publishes each acquired swap-chain surface into the host-created shared ring (the IDD-push path) — the full glass-to-glass transport is code-complete. Both sides use the canonical pf_vdisplay_proto::frame layout (lockstep by compile-error, not "must match" comments). Driver compiles + LOADS on-glass (adapter inits, Status=OK; no regression — the publisher is dormant until a frame is acquired); host cargo check green; adversarially reviewed (no blockers — token layout, keyed-mutex key 0, names by target_id, and the format guard all match the host consumer). - new driver frame_transport.rs: FramePublisher OPENS the host ring by target_id (OpenFileMapping header + magic Acquire readiness gate + OpenEvent + OpenSharedResourceByName RING_LEN keyed-mutex textures), writes its render LUID + DRV_STATUS back into the header; publish() is NON-BLOCKING (round-robin 0ms try-acquire -> CopyResource -> ReleaseSync -> FrameToken::pack store Release -> SetEvent; drops the frame if every slot is busy or the surface format != the ring format). Manual handle/view cleanup on every try_open early return; RAII Drop (slots -> unmap -> CloseHandle). Layout/consts/names/token all from pf_vdisplay_proto::frame. - swap_chain_processor.rs run_core: lazy rate-limited attach (every ~30 frames) + is_stale re-attach (mid-session HDR ring recreate); publishes buffer.MetaData.pSurface via IDXGIResource::from_raw_borrowed (preserves IddCx's refcount) BEFORE IddCxSwapChainFinishedProcessingFrame. run/run_core gain the render LUID; callbacks.rs assign_swap_chain passes it. - host idd_push.rs migrated onto pf_vdisplay_proto::frame (deleted the hand-rolled SharedHeader / MAGIC / VERSION / RING_LEN / DRV_STATUS_* / name fns / token packing) — pure refactor, byte-identical, no behavior or gating change. DebugBlock + DXGI_SHARED_RESOURCE_RW kept local (not in the proto). - driver windows crate gains Win32_System_Memory (MapViewOfFile/OpenFileMappingW/...); rustfmt'd the whole driver workspace (incl. wdk-probe — fmt-only). Built via the ultracode flow: STEP-6 map workflow -> agent-implement -> box build (driver + host both green; caught nothing this time) -> adversarial-verify-agent (no blockers) -> FrameToken::pack hardening -> deploy (loads). Glass-to-glass frame validation awaits a composited session (per the parity finding: this headless box yields 0 frames for the proven SudoVDA path too). FOLLOW-UPs: port the optional Global\pfvd-dbg DebugBlock triage channel to the new driver; STEP 7 HDR; STEP 8 drop SudoVDA. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 10:28:47 +00:00
enricobuehler	590ceaa850	fix(windows-drivers): driver Cargo.lock — pf-vdisplay gains windows + thiserror edges (STEP 5) ... STEP 5 (d8a453f) added the windows + thiserror deps to pf-vdisplay/Cargo.toml but the workspace lock was not updated (driver is windows-only, cant build on the Linux dev box). Regenerated on the RTX box. Both crates were already resolved in the lock (pulled by wdk-build), so this is purely the pf-vdisplay dependency edges. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 09:32:12 +00:00
enricobuehler	d8a453f6ca	feat(windows-drivers): STEP 5 — SwapChainProcessor + Direct3DDevice (swap-chain drain) ... The pf-vdisplay driver now consumes the OS swap-chain so a virtual monitor is a usable display rather than a stalled one. Compiles + loads on-glass (no regression: adapter still inits, Status=OK); adversarially reviewed — no blockers, the leak/deadlock invariants preserved. - new swap_chain_processor.rs: a worker thread (MMCSS "Distribution") that binds the render D3D device (IddCxSwapChainSetDevice, single-borrow 60x@50ms retry) then drains the swap-chain (ReleaseAndAcquireBuffer2 -> FinishedProcessingFrame; E_PENDING waits 16ms on the surface event). NO frame publisher yet (STEP 6). RAII terminate+join Drop; the load-bearing top-of-loop terminate check (the oracle's reconnect-leak fix). Fixed a Rust-2021 disjoint- capture bug: `.0` field access bypassed the Sendable Send wrapper -> rebind the whole wrappers. - new direct_3d_device.rs: CreateDXGIFactory2 -> EnumAdapterByLuid(render LUID) -> D3D11CreateDevice; a DEVICE_POOL of one Arc<Direct3DDevice> per render LUID (the NVIDIA-UMD-worker-thread leak fix). - monitor.rs: MonitorObject gains swap_chain_processor; set/take helpers return it for the caller to drop OUTSIDE the MONITOR_MODES lock (dropping joins the worker — must never happen under the lock); remove_monitor/clear_all drop it before IddCxMonitorDeparture. - callbacks.rs: assign_swap_chain spawns the processor (pooled device per RenderAdapterLuid; WdfObjectDelete on D3D-init failure so the OS retries); unassign_swap_chain drops it. Fixed the stale `panic = "abort"` doc (workspace is unwind; the extern "C" boundary aborts on unwind). - Cargo.toml: windows 0.58 + thiserror (both already resolved in the driver lock). The 3 needed swap-chain DDIs were already wrapped in wdk-iddcx; their HRESULT-shaped NTSTATUS is classified by hand (hr>=0 success, 0x8000000A E_PENDING). - Also rustfmt'd the whole driver workspace (it had never been driver-fmt'd). Built via the ultracode flow: STEP-5 map workflow -> agent-implement -> box build (caught the Send-capture bug) -> adversarial-verify-agent -> deploy (loads). Session-1 on-glass validation (the drain loop servicing an ACTIVE monitor) is the next gate — assign_swap_chain only fires under an interactive session. Note for STEP 6: target_id_for_object uses the MONITOR_MODES handle lookup the oracle moved to a WDF context; revisit before target_id keys the shared frame ring. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 09:29:20 +00:00
enricobuehler	bbc891e50a	feat(windows-drivers): STEP 4 (2/n) — create_monitor + real mode DDIs + ADD/REMOVE ... The virtual-monitor lifecycle is now code-complete on the driver side (CI-green; deployed — no load/adapter-init regression, Status=OK): - new monitor.rs: the monitor/mode model (Mode/MonitorObject/MONITOR_MODES), ported from upstream virtual-display-rs with guid:u128 -> session_id:u64. create_monitor builds an EDID (serial=id) -> IddCxMonitorCreate -> IddCxMonitorArrival, stores the monitor, and returns the OS target id + adapter LUID for AddReply. remove_monitor / clear_all depart + drop. display_info/target_mode build the DISPLAYCONFIG timing (the union videoStandard u32 set directly — bindgen-API-agnostic, vs the oracle new_bitfield_1 transmute). - callbacks.rs: parse_monitor_description (EDID-serial lookup -> count-then-fill IDDCX_MONITOR_MODE) + monitor_query_modes (pointer-match -> IDDCX_TARGET_MODE) are real. - control.rs: IOCTL_ADD -> create_monitor + AddReply, REMOVE -> remove_monitor, CLEAR_ALL -> clear_all, via read_input/write_output_complete WDF buffer helpers. SET_RENDER_ADAPTER still stubbed (hybrid-GPU pin, next) + the watchdog thread (next). - DISPLAYCONFIG_* resolve at the wdk_sys root (pub use types::*), not iddcx. Warnings are the STEP-7 *2/HDR stubs + created_at (read by the watchdog, next). The on-glass "monitor appears at WxH@Hz" gate awaits the host switch to pf_vdisplay_proto. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-25 07:19:39 +00:00
enricobuehler	3e535f1de4	feat(windows-drivers): STEP 4 (1/n) — control-plane IOCTL dispatch (GET_INFO + PING) ... EvtIddCxDeviceIoControl now dispatches the pf-vdisplay-proto control plane (new src/control.rs): IOCTL_GET_INFO writes InfoReply{protocol_version, watchdog_timeout_s} (the host asserts the version + fails loudly on mismatch), IOCTL_PING bumps the watchdog keepalive. ADD/REMOVE/SET_RENDER_ADAPTER/CLEAR_ALL are dispatched but stubbed (STATUS_NOT_IMPLEMENTED) pending create_monitor + the real mode DDIs (next). Unknown IOCTLs -> STATUS_NOT_FOUND. Builds CI-green; warnings are the *2/HDR stubs (STEP 7) + the stored adapter handle (read by create_monitor, next). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 23:21:25 +00:00
enricobuehler	c94a81d523	chore(windows-drivers): clean up STEP-3 debugging artifacts; restore device interface ... Verified on-glass after cleanup: adapter still inits (IddCxAdapterInitAsync 0x0, Status OK) and WdfDeviceCreateDeviceInterface 0x0. - RESTORE WdfDeviceCreateDeviceInterface (regression from debugging): the proto control plane sends IOCTLs via EvtIddCxDeviceIoControl, which needs the device interface for the host to open. Upstream omits it only because it uses a socket; ours is IOCTL-based. - Drop the framework_struct_size / version-table machinery + size.rs: size_of suffices (these are IddCx 1.10 structs on a 1.10 framework, matching upstream). The version-table reads were added chasing a size mismatch that was never the bug (GammaSupport was). - Drop /OPT:NOICF (ICF folding was a non-issue) + fix the stale stub-pick comment (the 1.10 stub is needed for the dispatch table, not size.rs symbols). - Debug-wait/PID-file/go-file gate already removed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 23:16:25 +00:00
enricobuehler	df32060655	fix(windows-drivers): STEP 3 DONE — IddCx adapter inits on-glass (Status=OK) ... The all-Rust wdk-sys IddCx driver now initializes its adapter on the RTX box: IddCxAdapterInitAsync -> 0x0, EvtIddCxAdapterInitFinished fires, device Status=OK. ROOT CAUSE (found via cdb wt-trace of iddcx!IddCxImplAdapterInitAsync + the upstream virtual-display-rs source): IDDCX_ENDPOINT_DIAGNOSTIC_INFO.GammaSupport was left zeroed = IDDCX_FEATURE_IMPLEMENTATION_UNINITIALIZED (0), which the framework adapter validator (ddivalidation.cpp:797) rejects with STATUS_INVALID_PARAMETER. Must be NONE (1). Also required (matched to the proven-working upstream virtual-display-rs, installed + verified Status=OK on the same box): - caps Flags = NONE (SDR). CAN_PROCESS_FP16 needs a newer contract than UmdfExtensions= IddCx0102 grants; deferred to STEP 7 (HDR). - SDR config: only the 7 required callbacks (+ DeviceIoControl for the proto control plane). The *2/gamma/HDR-metadata/query-target-info callbacks are FP16-obligated and rejected without FP16 caps; they return in STEP 7. - device WDF context type on WdfDeviceCreate; adapter WDF context type on the init attrs. Debugging note: cdb is reliable via live-attach (go-file gate to avoid the IsDebuggerPresent race) but cdb -z static hangs on the VM; iddcx WPP needs the control GUID (TMF GUIDs are not it). Diagnostics trimmed; log.rs dbglog kept for STEP 4+. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 22:39:49 +00:00
enricobuehler	55899bf73f	test(windows-drivers): adapter-init isolated to wdk-sys IddCx binding (Rust IddCx PROVEN to work on-box) ... DECISIVE: installed the pre-built UPSTREAM virtual-display-rs (Rust wdf-umdf IddCx) driver on the SAME box -> Status=OK. So a Rust IddCx driver inits an adapter here, self-signed, right now. My wdk-sys driver still fails ONLY at IddCxAdapterInitAsync (0xc000000d) despite matching virtual-display-rs on EVERY inspectable dimension: - same iddcx 1.10 headers+stub - IDDCX_ADAPTER_CAPS + IDD_CX_CLIENT_CONFIG byte-perfect (offsets match C header) - runtime pointers all valid/non-null (names .rdata, version stack, dev handle) - identical IddFunctions[idx]+IddDriverGlobals dispatch; indices 0/1/2 - matched the minimal link (tested vendored wdk-build WITHOUT OneCoreUAP/ NODEFAULTLIB/OPT/INTEGRITYCHECK -> still fails; export pollution ruled out) - device context, no device interface (control via EvtIddCxDeviceIoControl), init order The IddCx ClassExtension ETW provider emits no decodable reason (WPP/kernel-debugger only). The remaining difference is the wdk-sys IddCx binding itself, invisible to inspection. This commit keeps the upstream-matching structure (device context, no interface) + the on-glass instrumentation; vendored wdk-build reverted to pristine. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 19:40:26 +00:00
enricobuehler	725e596d2b	feat(windows-drivers): adapter WDF context type + init-before-interface (match SudoVDA) ... On-glass diagnosis narrowed decisively. PROVEN it is the driver, NOT the box: enabling the installed SudoVDA devnode -> Status=OK (the box inits a self-signed IddCx adapter right now). SudoVDA uses the IDENTICAL UmdfExtensions=IddCx0102 and is built against IddCx 1.10 (DriverVer 1.10.9.289) — exactly our config. Matched SudoVDA/the oracle on every inspectable dimension, none fixed the IddCxAdapterInitAsync INVALID_PARAMETER: caps byte-perfect (offsets+sizes vs C + framework table), minimal SDR adapter fails identically, dispatch byte-identical to the oracle (IddFunctions[idx] + IddDriverGlobals), IddMinimumVersionRequired=4 (same as oracle), version pointers, ObjectAttributes, init order, and now an adapter WDF context type (this commit). The remaining difference is the Rust binary itself vs SudoVDA C++. Next: capture IddCx ETW/WPP rejection reason (or kernel debugger), or build the oracle (wdf-umdf Rust) on-glass to isolate Rust-wide vs wdk-sys-specific. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 18:25:07 +00:00
enricobuehler	d17aeefd1c	fix(windows-drivers): wstr! const->static (latent dangling .as_ptr) + record adapter-init ruleouts ... wstr! used `const W; W.as_ptr()` which points to a temporary dropped at the end of the statement (dangling) — fixed to `static W` (stable address). On-glass it did NOT change the IddCxAdapterInitAsync INVALID_PARAMETER, and a minimal SDR adapter (Flags=NONE + required callbacks only) fails identically, so the caps content + callbacks are NOT the blocker (offsets are byte-perfect vs C; sizes match the framework table; dispatch + device are correct). Config restored to FP16 + full HDR callbacks. Remaining suspects: IDARG_IN_ADAPTER_INIT layout, the missing DeviceContext (oracle always sets one), or a box/framework regression. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 18:07:15 +00:00
enricobuehler	1b0a13c25e	test(windows-drivers): offset-audit the IddCx caps — bindgen layout is byte-perfect ... IddCxAdapterInitAsync still INVALID_PARAMETER. Logged offset_of! for every IDDCX_ADAPTER_CAPS + IDDCX_ENDPOINT_DIAGNOSTIC_INFO field on the box: ALL match the expected C x64 layout exactly (caps Flags=4 MaxRate=8 MaxMon=16 Diag=24 Static=80; diag Trans=4 Friendly=8 Model=16 Manuf=24 HwVer=32 FwVer=40 Gamma=48). So the wdk-sys bindgen lays the struct out correctly — NOT a layout bug. The caps are byte-identical to C + match the framework size table + the oracle, yet rejected. Next: runtime compare vs the oracle (does it init an adapter on this box now?) + WDK-docs deep-dive. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 17:54:11 +00:00
enricobuehler	3d3dd3627c	feat(windows-drivers): STEP 3 on-glass — driver LOADS + runs full IddCx init chain ... Major on-glass progress on the RTX box. The all-Rust wdk-sys IddCx driver now LOADS under Secure Boot and runs the ENTIRE init chain: DriverEntry -> WdfDriverCreate -> driver_add -> IddCxDeviceInitConfig(0x0) -> WdfDeviceCreate -> CreateDeviceInterface -> IddCxDeviceInitialize -> D0Entry -> init_adapter. Findings: - Signing was a RED HERRING (the driver loads); std works in WUDFHost (DualSense uses it too). - THE unblock: link the iddcx **1.10** IddCxStub (build.rs now picks the highest version-aware), not 1.0 — the 1.0 stub lacks the version-table symbols AND its dispatch table mismatched the 1.10 framework, which made IddCxDeviceInitConfig return INVALID_PARAMETER. With 1.10 the whole chain runs. - Added a file/OutputDebugString logger (log.rs, matches the DualSense driver) — the driver was silent; this is how the chain was traced. - size.rs: framework_struct_size() reads the frameworks authoritative struct sizes from IddStructures[] (the config keeps size_of=208, validated working). - adapter.rs: version ptrs + ObjectAttributes(InheritFromParent) + FP16 + framework caps/diag/version sizes — matches the oracle. KNOWN WIP: IddCxAdapterInitAsync still returns INVALID_PARAMETER though caps match the framework size table (88/56/24) + the oracle exactly — likely a subtle wdk-sys bindgen field-layout detail in IDDCX_ADAPTER_CAPS/IDDCX_ENDPOINT_DIAGNOSTIC_INFO. CI gate (compile+link) stays green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 17:46:58 +00:00
enricobuehler	ad27174027	feat(windows-drivers): STEP 3 — IddCx adapter init (deferred D0, FP16 caps) ... adapter.rs: init_adapter(device) builds IDDCX_ADAPTER_CAPS (CAN_PROCESS_FP16, MaxMonitorsSupported=16, endpoint diagnostics with wstr! PCWSTR names) + IDARG_IN_ADAPTER_INIT and calls IddCxAdapterInitAsync; EvtDeviceD0Entry triggers it (idempotent), EvtIddCxAdapterInitFinished stashes the adapter in a OnceLock for later DDIs. zeroed()+named-field construction dodges the Default-derive + field-order questions. Compiles + links clean on the box (pf_vdisplay.dll 268KB). CI gate = compile+link; the on-glass load/enumerate gate needs the box + an INF + SwDeviceCreate (next). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 16:28:10 +00:00
enricobuehler	d0d31b1040	fix(windows-drivers): size_of config size (1.0 IddCxStub lacks the version table) + CI builds pf-vdisplay ... The versioned IDD_STRUCTURE_SIZE path referenced IddClientVersionHigherThanFramework/ IddStructureCount/IddStructures — LNK2019 unresolved, because the WDK links the iddcx 1.0 IddCxStub which lacks those (they are >=1.4). We target 1.10 against a current framework (higher==false) where size_of is exactly the versioned result, so use it directly (the surface-assert refs linked only because they were DCE-eliminated). pf-vdisplay now COMPILES + LINKS IddCxStub on the box (263,680B). Point windows-drivers.yml at the whole workspace + clear FORCE_INTEGRITY on pf_vdisplay.dll; drop the obsolete UINT diagnostic dump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 16:16:22 +00:00
enricobuehler	4f10f3439d	feat(windows-drivers): pf-vdisplay STEP 2 — IddCx device skeleton ... DriverEntry -> driver_add builds the full IDD_CX_CLIENT_CONFIG (14 IddCx callbacks + PnP EvtDeviceD0Entry, all stubs with correct PFN signatures) sized via the ported IDD_STRUCTURE_SIZE! (size.rs), runs IddCxDeviceInitConfig -> WdfDeviceCreate -> WdfDeviceCreateDeviceInterface(the owned pf-vdisplay GUID, not SudoVDA) -> IddCxDeviceInitialize. callbacks.rs has all 14 + device_d0_entry; query_target_info implements HIGH_COLOR_SPACE. edid.rs salvaged verbatim from the oracle. proto gains interface_guid_fields() (u128 -> Windows GUID fields). Links IddCxStub (the CI gate); adapter/monitor/swapchain/IDD-push fill the stubs in STEP 3-6. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 16:12:20 +00:00
enricobuehler	788e4acbb5	feat(windows-drivers): STEP 1 — wdk-iddcx with all 11 IddCx DDI wrappers ... Graduate the proven iddcx_rt.rs dispatch into wdk-iddcx + add the full DDI set the pf-vdisplay driver needs: DeviceInitConfig/Initialize, AdapterInitAsync, MonitorCreate/Arrival/Departure, AdapterSetRenderAdapter (void-returning DDI — its PFN returns ()), SwapChainSetDevice/ReleaseAndAcquireBuffer2/FinishedProcessingFrame. One dispatch macro pins each (_IDDFUNCENUM index, PFN_* type) pair exactly once (the only place table dispatch can be UB). Box-compiles green; IddCxStub link gets validated when pf-vdisplay (cdylib) consumes it in STEP 2. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:55:45 +00:00
enricobuehler	d7a9fbf0b6	feat(windows-drivers): pf-vdisplay STEP 0 scaffold + std-under-UMDF link gate ... M1 step 2 begins. Add the wdk-iddcx (lib, re-exports wdk_sys::iddcx) + pf-vdisplay (cdylib) workspace members. pf-vdisplay STEP 0 = DriverEntry + WdfDeviceCreate skeleton + a #[used] _std_link_gate forcing std::thread + OwnedHandle to link, so the build proves the std surface resolves under the wdk-build UMDF link settings (kernel32 is /NODEFAULTLIB - std must come via OneCoreUAP). If std fails to link here, the SwapChainProcessor worker-thread design needs a CreateThread shim before any callback work (port-plan critique gap #9). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:49:03 +00:00
enricobuehler	ae803b24d5	test(windows-drivers): CI-assert the full IddCx driver symbol surface ... Port-plan critique #1: convert "the (?i).*iddcx.* allowlist may miss a symbol the full driver needs" from a box-only surprise into a CI compile gate. New wdk-probe/src/iddcx_surface_assert.rs size_of-asserts every *2/HDR struct (IDDCX_TARGET_MODE2/PATH2/METADATA2, IDARG_*RELEASEANDACQUIREBUFFER2 — these embed DISPLAYCONFIG_*/LUID, which RESOLVE from crate::types: no allowlist gap), None-asserts all 14 inbound PFN_IDD_CX_* callbacks, and confirms the .Size machinery (IddStructures/IddStructureCount/IddClientVersionHigherThanFramework/ _IDDSTRUCTENUM::INDEX_*) + the FP16/HIGH_COLOR_SPACE flags. Box-built green; the wdk-sys binding is proven complete for the ENTIRE driver, not just init. Also silence the bindgen naming lints in the iddcx module. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:39:03 +00:00
enricobuehler	3fbabc854c	feat(windows-drivers): IddCx link probe — call init DDIs via table dispatch ... First USE of the iddcx binding: a minimal table-dispatch (src/iddcx_rt.rs) over wdk_sys::iddcx — IddFunctions[_IDDFUNCENUM::<Name>TableIndex] cast to PFN_*, IddDriverGlobals as implicit arg 1 (the WDF model; ModuleConsts i32 index, not the oracle NewType .0). The probe EvtDeviceAdd now calls IddCxDeviceInitConfig → WdfDeviceCreate → IddCxDeviceInitialize → IddCxAdapterInitAsync, exports IddMinimumVersionRequired=4, and build.rs links IddCxStub (globbed from the SDK Lib dir that ships iddcx). CI gate = compile + link IddCxStub. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:18:48 +00:00
enricobuehler	6d8c7a5185	fix(windows-drivers): translate iddcx enum repr ints (UINT in nested mods) ... Last UINT errors were all `pub type Type = UINT;` inside bindgen enum modules (pub mod _DXGI_X {..}) — the top-level UINT alias cannot reach nested modules. C++ parsing made bindgen keep the UINT typedef as the enum underlying repr (C mode emits a primitive). translate_enum_integer_types(true) emits native u32 reprs, so the enum modules are self-contained; struct-field UINT stays covered by the src/iddcx.rs alias. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 15:01:22 +00:00
enricobuehler	c6a818e985	fix(windows-drivers): DXGI enum-modules + define UINT in iddcx module ... Last iddcx type gaps: (1) DXGI enum newtypes are `pub use self::_DXGI_X::Type as DXGI_X` — the `_DXGI_X` module needs allowlisting too (broaden DXGI_.* to _?DXGI_.*, matching the OPM fix); (2) UINT bindgen raw_line landed in a scope the bindings cannot see — define `pub type UINT` directly in src/iddcx.rs next to `use crate::types::*` instead. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:49:11 +00:00
enricobuehler	f34e956818	fix(windows-drivers): emit OPM struct tags + D3DCOLORVALUE + shim UINT ... DXGI resolved. Remaining iddcx type gaps: OPM typedefs need their _OPM_* struct tags too (recursively(false) drops them), D3DCOLORVALUE (an OPM field), and UINT (unsigned int — absent from crate::types, and allowlist_type does not emit bare primitive aliases). Broaden to _?OPM_.* + _?D3DCOLORVALUE and raw_line the UINT alias. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:40:25 +00:00
enricobuehler	04e52b0c22	fix(windows-drivers): emit IddCx DXGI/OPM/UINT types locally ... The iddcx bindgen now SUCCEEDS (C++ fix). Generated module had 38 unresolved-type errors — a bounded set wdk-sys does not bindgen: UINT, DXGI_FORMAT, DXGI_COLOR_SPACE_TYPE, IDXGIDevice/Resource, 6 OPM_* types. No WDF type is missing, so the crate::types sharing (type-identity) holds. Allowlist those families so they emit locally in iddcx.rs (non-conflicting — absent from crate::types), keeping allowlist_recursively(false). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:33:59 +00:00