5 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	5219107177	chore(unsafe): the workspace adopts the drivers' unsafe discipline ... `packaging/windows/drivers/*` has run `deny(unsafe_op_in_unsafe_fn)` + `deny(clippy::undocumented_unsafe_blocks)` for a while, with `forbid(unsafe_code)` on the modules that need no unsafe at all. The main workspace had no lint config whatsoever, so nothing stopped a clean crate from quietly growing an `unsafe`, and nothing distinguished the handful of genuinely-unsafe lines inside a 600-line `unsafe fn` from the safe ones surrounding them. Three things, all mechanical: * `#![forbid(unsafe_code)]` on the eight crates that already contain zero unsafe (`pf-driver-proto`, `pf-host-config`, `pf-paths`, the three clean clients, both tools). These were clean by accident, not by contract; now they are clean by contract. * `unsafe_op_in_unsafe_fn = "warn"` workspace-wide. `unsafe fn` states a contract the CALLER must uphold — it was never meant to switch off checking for the whole body. Measured fallout is 300 sites on Linux, and they are concentrated: six files carry all of them, while `punktfunk-core`, `pf-frame`, `pf-clipboard` and `pf-vdisplay` are already at zero. `warn` (not `deny`) so the build stays green while those six are worked down; it flips to `deny` once they are. This is also the Rust 2024 default, so it pays off the edition migration early. * `proc::current_uid()` replaces eight `unsafe { libc::getuid() }` blocks. Each site had copied out the same SAFETY note verbatim, which is the tell: `getuid()` is parameterless, always succeeds and touches no memory, so there is no contract for a caller to uphold and no reason for the unsafe to be visible eight times. One `unsafe` behind a safe wrapper, none at the call sites. Verified: `pf-vdisplay` builds clean on Linux (Nobara) at zero E0133; the macOS-buildable crates build clean locally. No behaviour change.	2026-07-28 21:31:41 +02:00
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	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 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 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