9 Commits

Author	SHA1	Message	Date
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	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	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