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>
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>
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>
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>
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>
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>
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>
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>
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>
enricobuehler