92 Commits

Author	SHA1	Message	Date
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
enricobuehler	5e106c51cf	feat(windows-host): bundle + auto-run the web console in the installer ... The Windows host installer shipped only the host exe + SudoVDA driver + FFmpeg, so a fresh install had no web management console — required for basically every user (status, paired devices, the PIN pairing flow). The console was only ever set up by hand on the dev box (build-web.ps1 + a hand-made PunktfunkWeb task whose web-run.cmd wasn't even committed). Bundle it into the same installer, mirroring the proven Linux punktfunk-web deploy. - windows-host.yml builds the Nitro node-server console (bun, deb.yml's shape) + fetches a pinned portable Node, smoke-boots it under node (/login == 200) to gate the build, and hands web/.output + node.exe to the pack script. - pack-host-installer.ps1 gains -WebDir/-NodeExe and stages the .output tree, node, and the two new scripts into the non-WOW64-redirected build area. - punktfunk-host.iss lays the payload into {app}\web\.output + {app}\node\node.exe, adds a wizard page for the console login password pre-filled with a crypto-random default (shown on the finish page; kept on upgrade), and runs web-setup.ps1. - web-setup.ps1 writes the ACL'd %ProgramData%\punktfunk\web-password (Administrators + SYSTEM), registers the PunktfunkWeb scheduled task (boot, SYSTEM, restart-on-failure -> web-run.cmd -> node on :3000), opens inbound TCP 3000, and starts it. web-run.cmd sources the host's mgmt-token + the password and runs the bundled node. - The console proxies the host's loopback mgmt API with the host's own %ProgramData%\punktfunk\mgmt-token (no host-code change). Uninstall removes the task + firewall rule. Validated locally: bun build -> node-server bundle, node boot serves /login (200) and gates /api (401). The Windows-only bits (ISCC compile, scheduled task, password page, firewall) validate on the Windows runner CI + on-glass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 19:28:47 +02:00
enricobuehler	b0c82333d2	feat(gamepad): pure-user-mode Windows DualShock 4 + Xbox 360 (drop ViGEm) + installer + multi-pad ... Windows virtual gamepads now have zero external dependencies - ViGEmBus is removed. - DualShock 4: Windows UMDF backend (inject/dualshock4_windows.rs + dualshock4_proto.rs), reusing the DualSense SwDeviceCreate game-detection identity fix. The one UMDF driver serves the DS5 or DS4 identity/descriptor/features/strings per a device_type byte the host stamps into shared memory. Driver also gains IOCTL_HID_GET_STRING and a 41-byte calibration feature. - Xbox 360: a new UMDF2 XUSB companion driver (packaging/windows/xusb-driver/) that registers GUID_DEVINTERFACE_XUSB and answers the buffered XInput IOCTLs from a shared section, so classic XInputGetState/SetState work with no kernel bus driver. inject/gamepad_windows.rs is rewritten to drive it and the vigem-client dependency is removed. Xbox One folds to the 360 XInput path. - Installer: vendor + pnputil-install the three UMDF drivers (packaging/windows/gamepad-drivers/ + install-gamepad-drivers.ps1, wired into pack-host-installer.ps1 + punktfunk-host.iss). - Multi-pad: the host stamps each pad index into the device Location (pszDeviceLocation); the driver reads it via WdfDeviceAllocAndQueryProperty to map its own *-shm-<index>, with UmdfHostProcessSharing=ProcessSharingDisabled giving each pad its own host (per-pad statics). Validated live on the Windows host: Cyberpunk native DualSense detection, DS4 identity + descriptor, XInputGetState + rumble round-trip, two pads -> two distinct XInput slots, and a full installer build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-22 16:35:03 +02:00
enricobuehler	72eeedc4da	feat(windows): AMD (AMF) + Intel (QSV) hardware encode on the Windows host ... The Windows host was NVIDIA-only (NVENC) with an openh264 software fallback. Add AMD AMF and Intel QSV via libavcodec — the Windows analogue of the Linux VAAPI backend — so one installer serves all three GPU vendors. - encode/ffmpeg_win.rs: new WinVendor{Amf,Qsv} encoder. System-memory NV12/P010 readback (default, robust) + opt-in zero-copy D3D11 (PUNKTFUNK_ZEROCOPY: shares the capturer's ID3D11Device; AMF takes AV_PIX_FMT_D3D11, QSV derives a QSV frames ctx and maps) with a system fallback for the format-group mismatch the capturer's video-processor fallback can produce. HDR Main10 (P010 + BT.2020/PQ VUI; an Rgb10a2->P010 swscale covers the shader fallback). - encode.rs: Codec::amf_name/qsv_name; open_video + windows_resolved_backend() resolve PUNKTFUNK_ENCODER=auto|nvenc|amf|qsv|sw via a DXGI adapter VendorId probe. - capture/dxgi.rs: gpu_mode mirrors the resolved backend (D3D11 NV12/P010 for AMF/QSV). - gamestream/serverinfo.rs: GPU-aware codec advertisement (windows_codec_support; AV1 gated to RDNA3+/Arc, like the VAAPI path). - Cargo.toml: amf-qsv feature (optional ffmpeg-next in the windows target block). - CI/installer: windows-host.yml sets FFMPEG_DIR + builds --features nvenc,amf-qsv; the Inno installer bundles the FFmpeg DLLs; host.env default nvenc -> auto. CI-green target; AMF/QSV not yet on-glass validated (no AMD/Intel Windows box in the lab) — NVENC stays live-validated. An adversarial-review pass caught + fixed real FFI bugs (AV_PIX_FMT_P010 is a macro -> P010LE; windows-rs 0.62 GetImmediateContext/ GetDesc1 return Result; AV_HWFRAME_MAP_* is a bindgen enum with no BitOr). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-22 10:31:54 +00:00
enricobuehler	01dc0b616c	refactor(windows): trim the inert IOCTL channel from the DualSense driver ... The host<->driver channel is the shared-memory section (hidclass blocks the device stack and UMDF has no control device), so the first-attempt in-driver IOCTL channel never fired. Remove it: the custom device interface, IOCTL_PFDS_SET_INPUT/GET_OUTPUT, the output queue, and the on_set_input/complete_one_read/deliver_output helpers. The driver keeps the HID handshake, the 8ms read timer fed from the shared section, and on_output_report publishing the game's 0x02 to the section. Rebuilt + reloaded + the channel still verifies both directions live on the RTX box. Also list `pf_dualsense` as a second hardware id (alongside `root\pf_dualsense`) so the host's SwDeviceCreate'd software device binds the same driver as a devgen one. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-21 21:34:00 +00:00
enricobuehler	aa159df33f	feat(windows): Rust UMDF virtual DualSense driver + shared-memory host channel ... A self-authored UMDF2 HID minidriver (packaging/windows/dualsense-driver) that presents a virtual Sony DualSense (VID 054C/PID 0CE6) on Windows — adaptive triggers / lightbar / rumble that ViGEm structurally cannot deliver. Validated live on an RTX box (Win11 25H2, Secure Boot ON): the self-signed driver loads, Steam recognizes it as a genuine DualSense, and a game's 0x02 output report reaches the driver. The host<->driver channel is a named shared-memory section (Global\pfds-shm-<idx>) the host creates and the driver maps from its timer: input report 0x01 host->driver, output report 0x02 driver->host — input and output proven both directions live. This bypasses hidclass, which gates both a custom device interface and custom IOCTLs on the HID node, and UMDF has no control device. Built in Rust on microsoft/windows-drivers-rs. The load wall was the PE FORCE_INTEGRITY bit that wdk-build sets via /INTEGRITYCHECK (forces a CI-trusted page-hash signature a self-signed cert cannot satisfy) — cleared post-build. See packaging/windows/dualsense-driver/README.md for the build/sign/install recipe. Deferred: SwDeviceCreate per-session device lifecycle; removing the inert in-driver IOCTL-channel code; full on-glass session test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-21 20:36:39 +00:00
enricobuehler	0205c7b8d6	ci(release): split canary/stable tracks + unified Gitea Releases ... A push to main publishes canary builds to canary channels (fast iteration, unchanged); a single vX.Y.Z tag releases every platform at one version to the stable channels and attaches all artifacts (.deb/.rpm/.msix/.apk/.aab/.dmg + flatpak/decky/host-installer) to one Gitea Release. Collapses the host-v*/win-v*/host-win-v* tag namespaces into v* — the channel split makes the version-shadow bug structurally impossible (canary and stable are separate repos, never a shared version line). - scripts/ci/gitea-release.{sh,ps1}: one idempotent release helper (create-or-fetch + delete-before-upload), replacing 3 copy-pasted inline blocks and fixing their latent 409-on-reupload bug; prerelease flag auto-derived from the tag (an -rc tag won't shadow "Latest") - channels: apt canary/stable distributions; rpm *-canary/base groups; flatpak canary/stable OSTree branches + a 2nd .Canary.flatpakref; generic-registry canary/ vs latest/ aliases; Play internal/alpha; Apple TestFlight vs notarized DMG - android versionName threaded through gradle (versionCode stays run_number); Apple canary = TestFlight-only (no DMG/tvOS); canary base bumped to 0.3.0 - docs: new docs-site channels.md (subscribe table + cut-a-release runbook + box migration), refreshed ci.md workflow table + packaging READMEs Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 17:26:38 +00:00
enricobuehler	54b75c9be4	feat(host): GameStream/Moonlight compat is now opt-in (--gamestream) — secure native-only by default ... Follows the security audit (#5/#9): the GameStream-compat plane carries inherent on-path weaknesses that can't be fixed on the wire without breaking stock Moonlight — its pairing runs over plain HTTP (#9, MITM-able during the pairing window) and its legacy control encryption can reuse GCM nonces (#5, a passive eavesdropper can recover/forge input). The native punktfunk/1 plane (SPAKE2 PIN pairing + per-direction AEAD nonces) has neither. So flip the default to secure-by-default: - `serve` → native punktfunk/1 plane + management API ONLY (no GameStream surface). - `serve --gamestream` → ALSO the GameStream/Moonlight-compat planes (nvhttp pairing, RTSP, ENet control, _nvstream mDNS). Opt-in, logged with a trusted-LAN caveat. `--moonlight` is an alias. - The native plane is now ALWAYS on in `serve` (`--native` is a kept-for-compat no-op); the unified GameStream+native host is `serve --gamestream`. `gamestream::serve` gates the GameStream spawns (nvhttp/rtsp/control/mdns) on the flag; the native plane + mgmt + native-pairing handle always run. To avoid silently regressing validated Moonlight deployments, the explicit deployment configs PRESERVE Moonlight via `--gamestream` (each documents dropping it for a secure native-only host): the Linux systemd unit, the Steam Deck installer, and the Windows service default (DEFAULT_HOST_CMD). The bare `serve` default (new/manual use) is secure. Docs swept to match (host-cli, moonlight, quickstart, install, packaging READMEs, CLAUDE.md, README, …): Moonlight setup now instructs `--gamestream`; native/console refs use bare `serve`. OpenAPI regenerated (a stale "run `serve --native`" string). fmt + clippy clean; 94 host tests green. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 10:19:40 +00:00
enricobuehler	f85d51b9f9	feat(steamdeck): one-command host install + docs (build-on-device) ... SteamOS is immutable read-only Arch, and the Deck is AMD (VAAPI) — so none of the checked-in packaging (arch/sysext is NVENC-first + client-oriented, deb/rpm are soname-mismatched) actually installs a working host on a Steam Deck. The proven path (distrobox-built native binary + systemd-run units) was 100% manual. Make it one command. - scripts/steamdeck/install.sh — idempotent installer: ensure the pf2 Debian-trixie distrobox + toolchain → build host (+web console) → write config (generated web login password) → raise UDP buffers to 32 MB + udev + input group (sudo, skipped gracefully if unavailable) → install + start punktfunk-host / punktfunk-web systemd USER services with linger. Flags: --open (accept unpaired clients), --no-web, --src=DIR. Builds on-device so a rebuild always matches the running SteamOS (no prebuilt-binary fragility across OS updates); VAAPI on the Deck's AMD GPU. - scripts/steamdeck/update.sh — rebuild from current source + restart (config/pairings persist). - scripts/steamdeck/README.md — deep reference (why on-device, what's installed, gotchas). - docs-site: new "Steam Deck (Host)" guide + sidebar entry; install.md splits Arch from the Steam Deck host path; packaging/arch/README points Deck-host users here and corrects the stale "NVENC-only" note (VAAPI host encode landed). Live-validated on the Deck: installer runs clean, both services come up, host listens (QUIC :9777 + mgmt :47990), web serves (302→login); on a client connect it takes over the Game-Mode gamescope session at the client's mode, captures via PipeWire, and VAAPI-encodes (hevc_vaapi) — full pipeline confirmed in the host journal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-20 22:20:00 +00:00
enricobuehler	6922e1c467	feat(host): VAAPI codec probe + AMD/Intel packaging + neutral logs (Phase 3) ... Polish for AMD/Intel support: - GameStream serverinfo advertises only codecs the GPU can ACTUALLY encode on the VAAPI backend (probed once by opening a tiny encoder per codec). AV1 encode is narrow (Intel Arc/Xe2+, AMD RDNA3+/RDNA4) and an old iGPU may lack HEVC, so a Moonlight client never negotiates a codec the encoder can't open. NVENC/Windows keep the Moonlight-validated static mask. Validated on a Radeon 780M: h264/h265/av1 all probe true -> mask unchanged (65793). - Packaging: Recommends mesa-va-drivers + intel-media-va-driver (deb) / mesa-va-drivers + intel-media-driver (rpm) so the auto-selected VAAPI backend works out of the box on AMD/Intel; NVIDIA boxes can --no-install-recommends. (Fedora note: stock mesa-va-drivers disables HEVC/AV1 -- needs the freeworld variant from RPM Fusion.) - De-NVIDIA-fy the user-facing encoder log/context strings ("open NVENC" -> "open video encoder") now that VAAPI is a first-class backend. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-06-20 10:41:37 +00:00
enricobuehler	53aade0279	docs(packaging/windows): note the host is x64-only (no ARM64) ... The host is NVIDIA/NVENC + SudoVDA coupled; Windows ARM64 has neither an NVIDIA driver nor an ARM64 SudoVDA, so an ARM64 host would install but couldn't encode or make a virtual display. Document the deliberate x64-only scope so it doesn't get re-litigated. ARM64 stays client-only. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 13:23:30 +00:00
enricobuehler	24ee05a4d0	fix(packaging/windows): dodge WOW64 redirection — run ISCC on copies under C:\t ... Root cause of the persistent ISCC "path not found": ISCC.exe is 32-bit, and the self-hosted runner runs as SYSTEM, so the checkout lives under C:\Windows\System32\config\systemprofile\.cache\... . WOW64 file-system redirection rewrites a 32-bit process's System32 reads to SysWOW64 (where nothing exists), so ISCC died opening the .iss before it even printed its version line. (The smoke-test diagnostic compiled fine precisely because it lived at C:\t\out.) Fix: copy every file ISCC reads (the .iss + host.env.example + README.md) into the non-redirected build dir C:\t\out and compile from there; BinDir, StageDir, and OutputDir already live under C:\t. Removed the now-spent smoke diagnostic. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:27:19 +00:00
enricobuehler	d59de1553f	fix(packaging/windows): make the .iss pure ASCII (ISCC encoding failure) ... The smoke-test diagnostic proved Inno itself is healthy (a trivial ASCII script compiled), while the real .iss died before the "Compiler engine version" line — i.e. at script open, not during compile. The difference: the real .iss was UTF-8 with non-ASCII chars (→, —) in comments, which ISCC 6.4+ rejects without a UTF-8 BOM (and the German-locale runner misreads). Replace them with ASCII (->, -). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:22:00 +00:00
enricobuehler	e905801567	diag(packaging/windows): isolate the ISCC "path not found" failure ... All [Files] sources are validated-present yet ISCC still errors before any "Compiling" output (no line number) — so it's startup/[Setup]-internal, not a source path. Add an explicit [Languages] (compiler:Default.isl) to rule out the auto-added default language, and on ISCC failure dump the Inno install dir + run a trivial [Setup]-only smoke script to tell "Inno broken" from "my script". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 12:13:29 +00:00
enricobuehler	43e0be4cf4	fix(packaging/windows): pass installer source files as validated absolute defines ... The {#SourcePath} relative-traversal for host.env.example/README kept tripping ISCC ("path not found", error 2) regardless of the separator, so drop it: compute the two paths absolutely in pack-host-installer.ps1, Test-Path them (clear PS error if missing), and pass /DHostEnv + /DReadme. The .iss [Files] now reference the absolute defines — no {#SourcePath}, no ..\.. traversal. Also prints "source ok" for each so a future failure is unambiguous. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 11:44:30 +00:00
enricobuehler	822fde1e89	fix(rpm): derive the libcuda link stub from source (fixes undefined cu* symbols) ... The Fedora RPM build linked punktfunk-host against a synthesized libcuda stub with a FROZEN symbol list baked into ci/fedora-rpm.Dockerfile. The priority- stream work added cuCtxGetStreamPriorityRange / cuStreamCreateWithPriority / cuStreamSynchronize / cuMemcpy2DAsync_v2, which weren't in that list, so the link failed with "undefined symbol". build-rpm.sh now regenerates /usr/lib64/libcuda.so.1 from every cu* symbol the host source references (grep of crates/punktfunk-host/src), before rpmbuild — so a new cu* call can never silently break the link again. Self-maintaining and needs no builder-image rebuild (it supersedes the Dockerfile's frozen stub). Verified the 23 extracted symbols compile and cover the 4 that were undefined. Also fix the bogus %changelog weekday (Sun -> Mon, Jun 15 2026 is a Monday) that rpmbuild warned on. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 08:29:16 +00:00
enricobuehler	7dad881d98	fix(packaging/windows): add '\' after {#SourcePath} in the .iss [Files] ... ISPP's {#SourcePath} has no trailing backslash, so {#SourcePath}..\..\scripts resolved to ...\packaging\windows..\..\scripts (invalid component "windows..") -> ISCC error 2 "path not found". Add the explicit separator (a double backslash is harmless on Windows if a future ISPP ever adds the trailing one). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-19 07:36:01 +00:00