108 Commits

Author	SHA1	Message	Date
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
enricobuehler	2df3c0f2b4	fix(windows-drivers): parse the iddcx bindgen as C++ (clears struct-tag) ... Direct clang test on the box proved IddCx.h parses with 0 errors as C++ but fails as C (wdk_default has no --language=c++) — the IDARG_* typedef names hit "must use struct tag" in C mode. Fix generate_iddcx: --language=c++ + keep -DIDD_STUB + allowlist_recursively(false) + full codegen, so it emits ONLY IddCx items (structs, the IddFunctions table enums, DDI fn-ptr typedefs) and references WDF/Win/DXGI types from wdk-sys via `use crate::types::*` (no re-emission, no blocklist). Reverted the ENABLED_API_SUBSETS Iddcx entry (it wrongly pulled IddCx into the C-mode constants/types passes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:28:58 +00:00
enricobuehler	60df3c9c52	fix(windows-drivers): define IDD_STUB for the iddcx bindgen pass ... The iddcx bindgen failed with IddCxFuncEnum.h "IDDCX_VERSION_MAJOR is not defined" + a cascade of "must use struct tag" on IDARG_* types — NOT the feared #515 header conflict (IddCx parsed fine alongside Base+Wdf). IddCx.h needs STUB mode (function-table dispatch) for the version macros to resolve; add -DIDD_STUB to generate_iddcx, matching the wdf-umdf oracle. Deliberately NOT WDF_STUB (wdk-sys parses wdf non-stubbed; desyncing only here would break WDF type-identity). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:18:03 +00:00
enricobuehler	9fd19b90a9	feat(windows-drivers): vendor wdk 0.5.1 + add ApiSubset::Iddcx (M1 spike) ... Vendor the published, self-contained windows-drivers-rs 0.5.1 crates (wdk-build, wdk-sys) under vendor/ and add a first-class ApiSubset::Iddcx that bindgens iddcx/1.10/IddCx.h in an extra pass reusing bindgen::Builder::wdk_default (allowlist_file (?i).*iddcx.* — emits only IddCx items; WDF/DXGI types resolve to the shared base/wdf bindings, type-identity by construction). Mirrors the existing gpio/hid/spb subsets exactly: wdk-build gets the enum variant + iddcx_headers() (UMDF-only), wdk-sys gets generate_iddcx + the iddcx feature + pub mod iddcx. [patch.crates-io] redirects all wdk-sys/wdk-build (incl. wdk 0.4.1 transitive) to the patched copies. wdk-probe enables the iddcx feature. MAKE-OR-BREAK: does IddCx.h bindgen in wdk-sys config without a header conflict (issue #515) + does the generated module compile (type-identity)? CI answers it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 14:12:43 +00:00
enricobuehler	f896f70bb8	feat(windows-drivers): clear FORCE_INTEGRITY for self-signed driver load (M0) ... wdk-build links UMDF drivers with /INTEGRITYCHECK unconditionally (no opt-out), so the self-signed DLL would be refused by Code Integrity (3004/3089). Add a deterministic, idempotent, reusable packaging step (packaging/windows/clear-force-integrity.ps1) that clears the PE IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY bit (0x0080 @ e_lfanew+0x5e) and verifies — the gamepad recipe, no longer hand-run. driver-build now inspects the bit (before) then clears+verifies it. Real drivers will: build -> clear -> sign .dll -> Inf2Cat -> sign .cat. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 11:38:57 +00:00
enricobuehler	4f62643c82	ci(windows-drivers): static-CRT .cargo/config (fixes StaticCrtNotEnabled) ... wdk-build errored StaticCrtNotEnabled + the generated wdk-sys layout asserts overflowed (E0080) — UMDF needs the static CRT. Add the canonical windows-drivers-rs .cargo/config.toml: explicit target = x86_64-pc-windows-msvc (separates host proc-macros, which stay dynamic-CRT, from the driver) + target-feature=+crt-static scoped to that target. DLL now under the triple subdir. The WDK bindgen itself now runs (it generated out/types.rs) — this is the last build-config layer before the /INTEGRITYCHECK verdict. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:52:40 +00:00
enricobuehler	c91e7a0e38	ci(windows-drivers): workspace-level WDK driver-model (fixes wdk-sys build) ... wdk-sys build script: "missing field driver-model" deserializing workspace_metadata[wdk] — a workspace build reads the model from the WORKSPACE metadata, not the package. Set [workspace.metadata.wdk.driver-model] = UMDF 2.31 (all our drivers are UMDF 2.x incl. pf-vdisplay IddCx). Past the Cargo.lock fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:49:25 +00:00
enricobuehler	5d3cb5e63f	ci(windows-drivers): commit driver workspace Cargo.lock ... wdk-build requires a Cargo.lock next to the top-level Cargo.toml (it panics otherwise — "a Cargo.lock file should exist..."). Generated on Linux (resolution is platform-independent; only the build needs the WDK). Everything else compiled on the runner — pf-vdisplay-proto, bindgen, wdk-build/sys/macros. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:36:30 +00:00
enricobuehler	d3e4ea0118	feat(windows-drivers): driver workspace + wdk-probe on windows-drivers-rs (M1) ... Stand up packaging/windows/drivers/ — the unified driver workspace on crates.io windows-drivers-rs (wdk 0.4.1 / wdk-sys + wdk-build 0.5.1), retiring the dev-box ../../crates/wdk* path-deps. First member: wdk-probe, the smallest UMDF2 driver (DriverEntry -> WdfDriverCreate -> EvtDeviceAdd -> WdfDeviceCreate) that force-links the shared pf-vdisplay-proto ABI crate. It validates on the runner: wdk-sys bindgen + WDF stub link against the WDK + LLVM, the cross-workspace no_std proto path-dep, and the produced DLL's PE FORCE_INTEGRITY bit. windows-drivers.yml gains a driver-build job: cargo build -p wdk-probe (pinning Version_Number=10.0.26100.0) + a PE inspection that prints whether /INTEGRITYCHECK is set — the M0 self-signed-load question. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-24 08:33:38 +00:00
enricobuehler	e2c9bfd3d9	feat(windows): pf-vdisplay IDD-push — HDR + pipelined zero-copy capture ... HDR (display-driven, matching the WGC path): - CTA-861.3 HDR EDID (BT.2020 primaries + HDR Static Metadata block) so Windows offers "Use HDR" on the virtual display. The host FOLLOWS the display's live advanced-color state, recreating the shared ring at the matching format (FP16 in HDR / BGRA in SDR) on a toggle — no freeze. - Always emit Main10/BT.2020-PQ Rgb10a2 while the display is HDR; the client auto-detects PQ from the HEVC VUI (clients under-report VIDEO_CAP_10BIT). Generic HDR10 mastering SEI on every IDR. - Generation-tagged `latest` (gen<<40|seq<<8|slot) + driver `is_stale` re-attach kill the toggle-time garbage frame and any stale-ring read. Perf: - Pipeline the encode loop (Capturer::pipeline_depth; IDD-push = 2): submit N+1 before polling N so the convert/copy on the 3D engine overlaps the NVENC encode of N on the ASIC. PUNKTFUNK_IDD_DEPTH overrides (1 = synchronous). - Rotating host output ring (OUT_RING) so the in-flight encode and the next convert never touch the same texture. - HDR converts directly from the keyed-mutex slot's SRV into the output ring (drops the redundant slot->fp16 scratch copy); SDR copies the BGRA slot in. The slot mutex is held only across the convert/copy, not the encode. RING_LEN 3->6 for publish headroom. - Capture-health diagnostic: new_fps vs repeat_fps under PUNKTFUNK_PERF (a low new_fps at a high send rate means the source isn't compositing, not an encode stall). Validated live on the RTX box: 5120x1440@240 HDR streams; driver composes ~180 new fps, encode 240 fps @ ~4.3 ms p50. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:39:28 +02:00
enricobuehler	c5dab484df	feat(windows): bundle pf-vdisplay in the host installer; drop SudoVDA ... Switch the Inno Setup installer's virtual-display driver from the vendored SudoVDA C++ binary to our own all-Rust pf-vdisplay (validated streaming at 5120x1440@240). - packaging/windows/pf-vdisplay/: vendored SIGNED driver (pf_vdisplay.dll/inf/cat + punktfunk-driver.cer, the same cert the gamepad drivers ship), built from vdisplay-driver/ via deploy-dev.ps1. - install-pf-vdisplay.ps1 / stage-pf-vdisplay.ps1: mirror the SudoVDA scripts - trust cert -> gated ROOT\pf_vdisplay node via nefconc (NEVER devgen) -> pnputil /add-driver /install. Idempotent, best-effort (never aborts the install). - punktfunk-host.iss + pack-host-installer.ps1: install the pf-vdisplay bundle under the existing installdriver task. - Removed the vendored SudoVDA driver + install-sudovda.ps1 + stage-sudovda.ps1. - README + windows-host.yml: SudoVDA -> pf-vdisplay. The host's vdisplay/sudovda.rs backend is unchanged - it drives whichever driver provides the {e5bcc234} interface, now pf-vdisplay. Live installer build/test on the runner is the remaining step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:39:28 +02:00
enricobuehler	e27abc065e	feat(windows): pf-vdisplay CLEAR_ALL — reap orphaned virtual monitors on startup ... The "5-6 stale monitors that never tear down" failure (also seen with SudoVDA): an orphan from a crashed/killed previous host lingers because the driver watchdog is kept reset by a still-pinging new session, so it never fires for the orphan. - Driver (pf-vdisplay control.rs): new IOCTL_CLEAR_ALL (0x804) -> tear down every monitor. A pf-vdisplay extension; SudoVDA returns invalid for it (ignored), so the host can issue it unconditionally. - Host (vdisplay/sudovda.rs): send IOCTL_CLEAR_ALL once on startup (best-effort) to reap orphans before creating ours; and surface a failing keepalive PING (the old `let _ =` swallowed it, masking a lost control handle). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:36:21 +02:00
enricobuehler	d39da4bc06	feat(windows): pf-vdisplay — all-Rust IddCx virtual display (replaces SudoVDA) ... P1 done: a pure-Rust UMDF2 IddCx driver, drop-in compatible with the host's existing vdisplay/sudovda.rs control plane (the {e5bcc234} interface + the SudoVDA IOCTL ABI), so the host drives it unchanged. Validated streaming on glass at 5120x1440@240 — steady 240 fps, ~2.4 ms encode, clean teardown, full parity with SudoVDA. - Vendored wdf-umdf-sys / wdf-umdf bindgen crates (MIT, from virtual-display-rs) + the SDK-version build.rs fix that resolves the IddCxStub lib path by the WDK version actually containing um\x64\iddcx, not the max base SDK. - pf-vdisplay crate: entry/callbacks/context/control/monitor/edid/ swap_chain_processor. Our OWN 128-byte EDID (manufacturer PNK, product punktfunk — no SudoVDA bytes), a real swap-chain drain (faithful vdd port, required so DWM keeps compositing), the SudoVDA-compatible IOCTL control plane (ADD/REMOVE/PING/GET_WATCHDOG/GET_VERSION/SET_RENDER_ADAPTER) + a watchdog that tears down orphaned monitors when the host stops pinging. - deploy-dev.ps1: stage + sign + stampinf (date.time DriverVer) + Inf2Cat + install, codifying the "bump DriverVer or pnputil keeps the old binary" gotcha. - docs/windows-virtual-display-rust-port.md: investigation, the on-glass validation, and the two traps that cost time (Session-0 measurement + accumulated device-state needing a reboot). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-24 00:36:21 +02:00
enricobuehler	de232ec2f7	fix(web): bundle deps into the server (noExternals) — kill the 47k-file install ... The Windows installer ballooned to 154 MB and installed forever because the node-server bundle externalized the WHOLE @unom/ui dependency tree (payload, lexical, date-fns, prismjs…) to .output/server/node_modules — 47,567 files / 730 MB copied into Program Files. Set Nitro `noExternals: true` so every dependency is bundled + tree-shaken into the server output: .output drops to ~75 files / 10 MB, and the bare external imports (srvx, seroval…) bun couldn't resolve at runtime are gone — so the console runs on bun (no node, no node_modules), which is the issue we previously worked around with node. Windows installer now ships bun.exe + the ~75-file .output (was node.exe + a node_modules forest) and runs `bun .output\server\index.mjs`: - windows-host.yml: fetch a pinned portable bun (build tool AND shipped runtime); drop the node fetch + the .output/server install; smoke-boot under the bundled bun. - pack-host-installer.ps1 / punktfunk-host.iss: -NodeExe -> -BunExe; stage {app}\bun\bun.exe. - web-run.cmd / build-web.ps1: run/restart on bun; docs updated. Net win everywhere: the Linux .deb shrinks (node still runs the self-contained output), and the docker web image — which already ran `bun run .output/server/index.mjs` with only .output copied — is fixed (the externals had no node_modules to resolve at runtime). Validated locally: noExternals build = 75 files / 10 MB; node AND bun both serve /login (200) + static assets (200) + gate /api (401). (A true single binary via `bun build --compile` is blocked for now: Nitro serves public assets from an import.meta-relative path `--compile` doesn't embed (/$bunfs/public); the 75-file payload is the clean result.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 21:19:32 +02:00
enricobuehler	58f4dccc02	fix(windows-host): ISCC [Code] — don't put {tmp} inside a Pascal comment ... ISCC aborted compiling the installer at the web-console [Code] section: a comment `{ ... {tmp} is auto-cleaned. }` — Pascal `{ }` comments don't nest, so the `}` in `{tmp}` closed the comment early and `is auto-cleaned. }` parsed as code ("Identifier expected"). Reword to drop the brace. (All other {app}/{tmp} uses are `;` line-comments or code strings, which are fine.) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 20:21:41 +02:00