11 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 4.8	b5fa878bc6	fix(pf-win-display): follow the input desktop so a UAC prompt can't refuse display writes ... Field-reported 2026-07-23: a consent prompt left up on an unattended host made the box unreachable. Every connect black-screened and failed after ~60 s, and the host had to be reached over SSH to clear the prompt. Windows refuses ChangeDisplaySettingsEx/SetDisplayConfig issued from a thread that is not on the desktop currently receiving input. While UAC (or the lock / logon screen) is up that desktop is Winlogon, and the host — which the service launches explicitly onto WinSta0\Default — got DISP_CHANGE_FAILED / ERROR_ACCESS_DENIED for every write. A session starting in that window could never set its virtual display's mode, so the capturer sized its ring to a stale mode, every composed frame was dropped for a size mismatch, and bring-up burned 8 retries before giving up. Measured on glass (RTX box, SYSTEM host in console session 2, real consent prompt up, virtual display active): INPUT desktop = Winlogon UNBOUND CDS_TEST -> -1 (DISP_CHANGE_FAILED) UNBOUND SDC_VALIDATE -> 0x5 (ERROR_ACCESS_DENIED) BOUND CDS_TEST -> 0 (DISP_CHANGE_SUCCESSFUL) BOUND SDC_VALIDATE -> 0x0 (ERROR_SUCCESS) New input_desktop.rs mirrors pf-inject's sendinput.rs retry model: issue the write, and only when it fails the way a wrong-desktop write fails, rebind this thread to the current input desktop and retry once. A working write is never touched, so the normal path is unchanged. The retry predicate stays narrow (ERROR_ACCESS_DENIED only) so the unrelated 0x57 exclusive-mode topology bug is not re-issued and mis-attributed. Unlike sendinput's dedicated injector thread, the binding here is SCOPED — a shared display-write thread left on a Winlogon desktop that is later destroyed would fail every subsequent write, which is the wedge this removes. Applied to all eight SetDisplayConfig sites and both ChangeDisplaySettingsExW calls in set_active_mode. The isolate site now decides its supplied config once, outside the write, so a retry re-issues the identical config rather than logging its escalation twice. A save is logged, because a silent one is indistinguishable in a field log from a write that never needed saving — which made the first on-glass verification of this change inconclusive. Both ACCESS_DENIED diagnostics now ask which cause applies instead of naming only the disconnected-RDP one: that phrasing sent this investigation chasing a phantom RDP session on a host that was already service-launched in the console session, while a consent prompt was the actual cause. Verified on glass: connect with a consent prompt up now reaches first frame in 3.0 s (was a black screen then "Connection failed" after ~60 s), with six "retried bound to it and it applied desktop=Winlogon" lines and rc=0x0 throughout. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 00:36:51 +02:00
enricobuehlerandClaude Fable 5	51792536d1	fix(pf-win-display): escalate CCD isolate to a keep-only supplied config on 0x57 ... Field bug (Steam Deck client, exclusive topology): every isolate retry failed SetDisplayConfig 0x57 with the physical panel left lit, while iPhone sessions worked — their virtual monitor's connected-set already had a sole-display topology persisted, so Windows deactivated the physical on hotplug and the isolate was a no-op re-commit (deactivated 0). The Deck's monitor identity had no such entry, forcing the live-deactivate path: supplying the doomed path (inactive, modes unpinned) plus its orphaned mode entries is rejected 0x57 by some driver/OS validation combos, so the retry loop could never converge — the prior mode-index unpin (5e088af7) was necessary but not sufficient on this box. Attempt 1 keeps the shipped shape; once a survivor is seen, later attempts supply ONLY the keep paths with the mode table rebuilt to just their referenced entries (indexes remapped, clone-shared entries deduped). The same host applies exactly this keep-only shape rc=0 whenever the DB has pre-isolated the virtual display, so the escalated shape is field-validated on the failing machine. The final attempt also drops SDC_FORCE_MODE_ENUMERATION — a real path removal drives COMMIT_MODES on its own. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:50:44 +02:00
enricobuehlerandClaude Opus 4.8	d31d41b6b8	fix(windows/capture): match the HDR-composited cursor to the target's SDR white level ... sRGB→linear alone lands cursor-white at 80 nits (scRGB 1.0) while DWM composes the surrounding SDR desktop at the user's SDR-brightness setting (~200+ nits by default) — the cursor read visibly dark on HDR. Scale by DISPLAYCONFIG_SDR_WHITE_LEVEL (new win_display::sdr_white_level_scale, queried on blend-scratch rebuilds — the CCD query stays off the per-frame path). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	5e088af7ed	fix(pf-win-display): unpin mode indexes on paths the CCD isolate deactivates ... Field report: with Exclusive Topology, the physical monitor sometimes stayed lit — every isolate attempt re-committed and failed SetDisplayConfig with 0x57 ERROR_INVALID_PARAMETER. Clearing DISPLAYCONFIG_PATH_ACTIVE alone leaves the deactivated path's source/target modeInfoIdx pinned to the queried mode entries, and per the SetDisplayConfig contract a path being turned off must have BOTH mode indexes set to DISPLAYCONFIG_PATH_MODE_IDX_INVALID; some driver/topology combinations (notably when the doomed path shares a source with the kept virtual path) reject the supplied config outright, so the retry loop could never converge. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 12:26:44 +02:00
enricobuehlerandClaude Fable 5	22b352c1da	chore(release): bump workspace version to 0.13.0 ... The eight W6 leaf crates hardcoded 0.12.0 instead of inheriting the workspace version — switched to version.workspace = true so the next bump is one line again. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 16:32:35 +02:00
enricobuehlerandClaude Opus 4.8	c8ee4b9902	fix(pf-vdisplay,pf-capture,pf-win-display): pre-split paths in the auto-merged v4 code ... The rename-followed perf hunks still said crate::win_display:: (the pre-W6 layout) — point them at pf_win_display::win_display:: and widen the four helpers they call cross-crate. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:13:15 +02:00
enricobuehlerandClaude Opus 4.8	1197415216	fix(pf-vdisplay,pf-win-display): v4 trait surface on the extracted driver.rs + cross-crate visibility ... The W-refactor extracted VdisplayDriver into manager/driver.rs (the merge resolution assumed it deleted) — carry the v4 changes there: open() returns the driver's protocol version, update_modes() default-errs to the re-arrival fallback. wait_target_departed goes pub for the manager's cross-crate call. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:11:34 +02:00
enricobuehlerandClaude Opus 4.8	09849906e9	Merge perf/first-frame-latency: driver proto v4 + first-frame/resize latency (P0-P2) ... Brings the first-frame-latency branch (P0.1 transition tracing, P1.1/P1.2 Welcome-time display prep, P2 in-place resize; pf-driver-proto v3 -> v4 with IOCTL_UPDATE_MODES) onto current main. The branch predates the W6.2/W7 splits, so git's rename detection carried most of it into the moved crates (pf-capture idd_push, pf-vdisplay manager/pf_vdisplay, pf-win-display, pf-driver-proto, the driver workspace) and the punktfunk1.rs remainder was re-homed by hand: - native/handshake.rs: welcome/start trace marks + the Welcome-time display prep spawn (the prep thread BECOMES the stream thread; hand-off via a SyncSender<SessionContext>). negotiate() gains bringup/quit/stop and returns the PrepHandle. - native.rs: bringup/resize_ms creation + the stop/quit flags hoisted BEFORE the handshake (the close watcher splits: flags pre-handshake, lifecycle events post-handshake where `hello` exists); punch_done stamp; the data plane adopts the prep thread's result or builds inline. - native/stream.rs: SessionContext/SendStats carry the trace; send_loop finishes it on the first video packet; the resize path gains the in-place fast path (try_inplace_resize) with the full rebuild as fallback, restructured so both share the post-rebuild bookkeeping; prepare_display/PreparedDisplay/ PrepHandle; build_pipeline(+retry) thread the stage marks. - session_status/mgmt: ttff_ms + last_resize_ms per session (union with the lifecycle-events fields main added to the same spots). - pf-capture: Capturer gains capture_target_id() + resize_output() defaults. - pf-vdisplay manager: perf's faster activation poll (60x50ms) + the settle floor before the PnP sweep, on main's knobs/no-trait shape. Also: packaging/windows/build-gamepad-drivers.ps1 is ASCII again (an em-dash from the pf-mouse work tripped windows-host.yml's locale-safety gate on main). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 16:08:16 +02:00
enricobuehlerandClaude Fable 5	845a97601d	feat(pf-frame,pf-win-display): leaf primitives for the lid-closed first-frame fix ... Three leaf-crate additions the IDD-push capturer (pf-capture, plan §W6 C6) builds on — committed ahead so the capture-crate extraction and the HID compose kick can land on top: - pf-frame session_tuning::DisplayWakeRequest — RAII PowerCreateRequest/ PowerSetRequest(PowerRequestDisplayRequired + SystemRequired), the service-grade 'someone is watching this screen' assertion (visible in powercfg /requests), held for a capture session so the console cannot drop into display-off mid-stream. Object-lifetime, unlike the thread-bound ES_* flags in on_hot_thread. Prevention only: no power request turns an already-off display back on — that wake is input's job (the virtual-mouse compose kick). - pf-win-display win_display::desktop_bounds() — the virtual-desktop bounds as the union of every ACTIVE CCD path's source rect. From the CCD database (global), NOT GetSystemMetrics (a per-session view), so a non-console-session host still aims HID absolute coordinates at the console's real layout. - pf-win-display console_session_mismatch() — the session guard from 3d9b3290, copied into the leaf so pf-capture reads it as a peer instead of reaching into the orchestrator (relocation authored by the W6 extraction session). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 11:17:29 +02:00
enricobuehlerandClaude Fable 5	3d9b329084	fix(host): name the lid-closed/no-frames failure — display-write decode, console-session guard, driver-truth attach diagnostics ... Field report (Windows laptop, lid closed, Tailscale): v0.12.0's activation fix works — the pf-vdisplay target activates in ~200ms — but the session still dies at the first-frame gate: 'driver_status=1 but no frame published within 4s'. Triage showed three independent blind spots; this names all of them at their source instead of guessing downstream: - pf-win-display: decode ChangeDisplaySettingsExW failures (-1 FAILED — a display write rejected, the wrong/remote-session signature — vs -2 BADMODE, which the old 'mode not advertised?' text conflated), and WARN on every non-zero SetDisplayConfig rc in the CCD isolate even when verification passes vacuously (the lid-closed case: nothing else active, so the INFO swallowed rc=0x5 ERROR_ACCESS_DENIED while the load-bearing COMMIT_MODES → ASSIGN_SWAPCHAIN re-commit silently never applied). Access-denied rcs get the remedy appended (console session / installed service). - host: console-session guard (interactive::console_session_mismatch) — a host outside the active console session (a hand-launched host after an RDP round-trip) fails every display write, reads the wrong session's GDI view, and its SendInput compose kicks go nowhere. Named ERROR at vdisplay acquire + appended to the first-frame timeout, instead of the misleading generic failure. (The idd_push diagnosis half of this landed in 9a36ea21; this commit adds the proto helpers + session guard it references, healing the windows-cfg build.) - proto + driver: while OPENED, driver_status_detail now carries a live packed word (bit31 live-marker | offered 15-bit | mismatch-dropped 16-bit) maintained by the publisher, so the host's first-frame timeout can tell apart: never-attached (no swap-chain worker ran), attached-but-DWM-composed- zero-frames (undamaged/powered-off desktop, kicks blocked on the secure desktop), and composed-but-every-frame-mismatched (ring sized from a stale/ foreign-session GDI mode). Zero layout change, old drivers read as 'no detail'; unit-tested pack/unpack in pf-driver-proto. Verified on winbox: cargo check + clippy -p punktfunk-host -p pf-win-display -p pf-driver-proto EXIT 0, drivers ws cargo check -p pf-vdisplay EXIT 0 (Version_Number=10.0.26100.0), cargo fmt --all --check clean; pf-driver-proto tests 13/13 pass locally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 10:47:47 +02:00
enricobuehlerandClaude Opus 4.8	ccc4b08d45	refactor(host/W6.2): extract the Windows display-topology cluster into the pf-win-display leaf crate ... windows/{win_display,monitor_devnode,display_events}.rs move into crates/pf-win-display: the CCD/GDI path-activation + mode-set + HDR advanced-colour + source-rect helpers, the PnP monitor-devnode enable/disable lever, and the WM_DISPLAYCHANGE / device-arrival watch. The coming pf-capture crate's IDD-push capturer consumes all three; the host's pf-vdisplay backend consumes win_display + monitor_devnode. A leaf lets both depend on them as a PEER instead of the capturer reaching back into the orchestrator (plan §W6). win_display's one external tie (crate::vdisplay::Mode) becomes the underlying punktfunk_core::Mode; the cluster is otherwise self-contained (pf-paths for the state file, serde_json for it, windows). pub(crate) items bump to pub at the boundary; win_display carries a module-level allow(missing_safety_doc) to keep the pre-carve behavior (the FFI helpers were pub(crate) unsafe fn with prose safety docs — the lint only fires once they're pub, and this is an internal publish=false leaf). The host imports the three modules at its crate root, so every crate::{win_display,monitor_devnode,display_events}::* path is unchanged. Verified: Linux clippy -D warnings (leaf empty + host nvenc,vulkan-encode,pyrowave --all-targets); Windows clippy -D warnings (pf-win-display --all-targets + host nvenc,amf-qsv --all-targets) Finished exit 0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 10:14:17 +02:00