unom/punktfunk
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases 3 Wiki Activity

docs(windows-rewrite): secure desktop validated on glass — mark M3 done, retire the biggest risk

Browse Source 
Owner-confirmed on glass (2026-06-25, "works great"): the IDD-push primary path
captures the lock/UAC secure desktop AND input reaches the streamed console
session. This was the single biggest open risk — the whole capture strategy
(Decision B: IDD-push primary for everything incl. secure desktop, WGC/DDA
demoted) rested on it. Now proven, not asserted.

- §15: M3 row → DONE (secure desktop); removed the secure-desktop gate from
  "What genuinely remains" (renumbered); added it to "Resolved since §11".
- §11 "IDD-push input + secure desktop" open item → RESOLVED.
- §14 critique "SINGLE BIGGEST RISK: the secure-desktop claim" → RESOLVED.

The WGC-relay / secure-DDA path is no longer load-bearing — kept only as a
non-IddCx-hardware fallback. Remaining rewrite work is migration/cleanup (M4
gamepad drivers, M5/M6, slot-reclaim), none blocking the validated path.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
Enrico Bühler
2026-06-25 21:42:25 +00:00
parent 48202a0f89
commit 6bed5d9e8e
1 changed files with 21 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/windows-host-rewrite.md
+21 -15
View File
@@ -586,10 +586,10 @@ What remains are **technical unknowns to confirm on the RTX box** (not user deci
- **Driver swap-chain reuse.** Does the clean ownership model (`EvtCleanupCallback` + DeviceContext state
+ single `Monitor` identity) actually fix the "reused swap-chain dies after ~2 sessions" root cause? If
not, the residual serialization stays inside `VirtualDisplayManager`.
- **IDD-push input + secure desktop.** Confirm `serve` runs in the console session so `SendInput` reaches
the streamed desktop (a code comment warns about Session 0→1); confirm IDD-push frames flow through the
lock screen / UAC (owner reports yes — verify and lock it in as the primary, demoting the DDA secure
leg to fallback).
- **IDD-push input + secure desktop. ✅ RESOLVED (owner-confirmed on glass, 2026-06-25).** `serve` runs in
the console session so `SendInput` reaches the streamed desktop, and IDD-push frames flow through the lock
screen / UAC — both confirmed live ("works great"). Locked in as the primary; the DDA secure leg is
demoted to a non-IddCx fallback. (See [§15](#15-current-status-2026-06-25).)
- **Does the demoted DDA fallback still need the `win32u` hook** against pf-vdisplay, or was that purely
a SudoVDA/hybrid pathology? If unneeded, the self-modifying-code hook can be deleted entirely.
- **AMF/QSV** stays CI-only (no hardware) — system-readback default, zero-copy experimental.
@@ -775,10 +775,11 @@ the locally-duplicated header/MAGIC/name consts.
### Critique verdict + the big risk
Plan is implementation-ready once the 4 CI-checkable unknowns are gates (3 now resolved by the surface-assert
+ `.Size` machinery presence; std-under-UMDF is the STEP-0 gate). **SINGLE BIGGEST RISK: the secure-desktop
claim** — the plan retires the proven two-process WGC relay + DDA on the *unproven* assertion that one
IddPushCapturer captures the lock/UAC secure desktop directly (IDD-push is opt-in today behind
`PUNKTFUNK_IDD_PUSH`). Make it a blocking on-glass gate (step 6) and keep the WGC relay recoverable for one
release. Other defined-failure-branch items: monitor `EvtCleanupCallback` firing, IDD_PERSIST/Reconfigure,
claim** — ~~the plan retires the proven two-process WGC relay + DDA on the *unproven* assertion that one
IddPushCapturer captures the lock/UAC secure desktop directly~~ → **✅ RESOLVED (owner-confirmed on glass,
2026-06-25): the IddPushCapturer captures the lock/UAC secure desktop AND input reaches it — "works
great."** The assertion held; this risk is retired (see [§15](#15-current-status-2026-06-25)). The WGC relay
stays only as a non-IddCx-hardware fallback. Other defined-failure-branch items: monitor `EvtCleanupCallback` firing, IDD_PERSIST/Reconfigure,
concurrent-monitor device sharing, host↔driver `protocol_version` lockstep.
---
@@ -805,27 +806,32 @@ that branch's commits, not the M2 greenfield tree the build order imagined.
| **§2.5** — ownership-model rewrite (`VirtualDisplayManager`/`MonitorLease`); swap-chain-reuse / monitor-leak | ✅ **DONE / RESOLVED** | `windows-host-goal1` §2.5 (`1520201`…`683c81b`); reconnect-leak A/B: 0 leaked monitors |
| **Goal-1 host refactor** (the in-place §2.2–2.5 realization, incl. `EncoderCaps`) | ✅ **DONE** | `windows-host-goal1` branch — all 6 stages + §2.5 + 3 seam tightenings |
| **Game-capture bug (GB1)** — fullscreen game breaks IDD-push | ✅ **FIXED** | `c87bfe0`/`f98ab07`/`789ad49`; see [game-capture-bug.md](windows-host-rewrite-game-capture-bug.md) |
| **M3** — service / input / audio cleanup | 🟡 code present (largely via the existing host + goal1) | — |
| **M3** — service / input / audio / **secure desktop** | ✅ **DONE** — secure desktop (lock/UAC) on-glass validated | owner-confirmed 2026-06-25: IDD-push captures the secure desktop + input reaches it |
| **M4** — gamepad drivers (`pf_dualsense`/`pf_xusb`) onto the unified stack, WDF device contexts (true multi-pad) | ❌ **NOT STARTED** | old gamepad-driver crates still separate |
| **M5** — demoted WGC/DDA fallback port + GameStream-on-`session/pipeline` + AMF/QSV (no hw) | 🟡 **PARTIAL** | fallbacks exist; not re-shaped onto the new seams |
| **M6** — cut over + delete the old monoliths | 🟡 **PARTIAL** | old `vdisplay-driver/` tree deleted (`a2bd0cd`); host monoliths remain |
### What genuinely remains
1. **Secure-desktop on-glass gate (the single biggest open risk, §14 STEP 6 critique).** IDD-push capturing
the lock screen / UAC with `serve` in the console session is **asserted, not yet locked on glass**. Until
it passes, keep the WGC-relay / secure-DDA path recoverable. Hardware-gated (RTX box; ephemeral).
2. **M4 — gamepad-driver migration** onto `windows-drivers-rs` (WDF device contexts → true multi-pad). The
With the secure-desktop gate passed (below), the primary-path risk is retired. What's left is migration /
cleanup / a driver robustness gap — none of it blocking the validated streaming path:
1. **M4 — gamepad-driver migration** onto `windows-drivers-rs` (WDF device contexts → true multi-pad). The
proven recipe exists; ~2–3 days, hardware-gated.
3. **M5/M6 cleanup** — re-shape the WGC/DDA fallback + GameStream onto `session/pipeline`, then delete the
2. **M5/M6 cleanup** — re-shape the WGC/DDA fallback + GameStream onto `session/pipeline`, then delete the
old Windows monoliths. Low priority; AMF/QSV stays CI-only (no lab hw).
4. **pf-vdisplay driver slot reclaim** — sustained ADD/REMOVE churn wedges the driver (`ADD →
3. **pf-vdisplay driver slot reclaim** — sustained ADD/REMOVE churn wedges the driver (`ADD →
0x80070490 ERROR_NOT_FOUND`): it doesn't reclaim IddCx monitor slots on REMOVE (ghost nodes accumulate).
Recovery today is `packaging/windows/reset-pf-vdisplay.ps1`; the real fix is in the driver
(`control.rs`/`adapter.rs`). Dev helpers `reset-pf-vdisplay.ps1` + `redeploy-pf-vdisplay.ps1` are committed.
### Resolved since the original §11 open items
- **Secure desktop (the single biggest open risk; §14 STEP 6 / "biggest risk").** ✅ **Confirmed on glass
(owner, 2026-06-25): the IDD-push primary path captures the lock screen / UAC secure desktop AND input
reaches the streamed console session — "works great."** The core assertion the whole capture strategy
(Decision B) rested on is now proven, not asserted; the WGC-relay / secure-DDA path is no longer load-
bearing (kept only as a non-IddCx-hardware fallback).
- **Driver swap-chain reuse** — the clean ownership model (`EvtCleanupCallback` + DeviceContext-owned state +
single `Monitor` identity) is in; §2.5's reconnect-leak A/B shows **0 leaked active monitors**. The
per-frame `CURRENT_MON_GEN` "monitor-gen bail" turned out to have been **write-only** (never wired), so the