9 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	560e663aef	fix(drivers): the pad channel asks the devnode who to trust, not the mailbox ... A LocalService principal could take over a virtual pad's shared input section and forge HID input into the interactive desktop. The host duplicates each pad's unnamed DATA section into the driver's WUDFHost, and through gamepad proto v2 it learned that process from `driver_pid` in the named bootstrap mailbox. That mailbox has to be LocalService-writable — that is what the driver's own WUDFHost runs as — and the delivery gate, verify_is_wudfhost, only checks that the target's IMAGE is %SystemRoot%\System32\WUDFHost.exe. That image is world-executable. So anything running as LocalService — notably the deliberately de-privileged plugin runner — could spawn its own WUDFHost (CREATE_SUSPENDED parks it indefinitely with the right image path), publish that pid, and be handed SECTION_MAP_READ|WRITE on a live section. For pf-mouse that section drives a real absolute pointer, so it was desktop control; for the pads it was forged gamepad input plus a read of the remote user's controller state. The module docs claimed mailbox tampering "yields at worst a gamepad DoS, never a read or an injection". That was wrong, and the reasoning behind it — that a LocalService token is DACL-denied OpenProcess on a UMDF WUDFHost — only covers the REAL host, not one the attacker spawned itself. The pid now comes from the device stack (ChannelProof, proto 2 -> 3). The host asks the devnode it SwDeviceCreate'd who is serving it, looked up by the instance id PnP handed back, so a planted look-alike devnode is not a candidate and the kernel — not anything the attacker supplies — does the routing. Only the driver PnP actually bound to that device can answer. `driver_pid` survives as a liveness hint; a tamperer can still deny a pad, which squatting the name always allowed, but can no longer choose the recipient. Two rules keep the state machine honest around it: a delivery stands until its target process EXITS (judged on a retained SYNCHRONIZE handle, so a recycled pid cannot fake it, and UMDF's restart-after-driver-crash still re-attaches), and a pad with no SwDeviceCreate devnode refuses to deliver rather than fall back — unless an operator sets PUNKTFUNK_PAD_CHANNEL_TRUST_MAILBOX, which says so loudly. Three transports, because Windows carries different things to different driver shapes, and the obvious two did not survive contact with hidclass. Measured on .173 (Win11 26200): HidD_GetIndexedString is NOT forwarded to a UMDF HID minidriver at all — it failed for every index including ones the driver demonstrably serves through the named wrappers; and a private device interface registers and enumerates but cannot be OPENED (ERROR_GEN_FAILURE), because hidclass owns IRP_MJ_CREATE on a devnode it is the FDO for. That is exactly why pf-xusb was never affected: it is not a HID minidriver, so nothing sits above it. What works: * pf-xusb — a private IOCTL on its own GUID_DEVINTERFACE_XUSB. * pf-mouse — the HID serial string. Verified: PFCP:3:0:7296, and 7296 was a genuine service-spawned WUDFHost.exe. Safe here alone: nothing reads the virtual mouse's serial, whereas a pad's is SDL/Steam dedup material. * pf-gamepad — a HID feature report, and it cost NO report-descriptor change. The captured descriptors already declare far more Feature ids than the driver ever served: 0x85 is declared on DualSense, DualShock 4 and Edge alike and used to fail with STATUS_INVALID_PARAMETER, so hidclass lets it through and nothing can have depended on the old failure. The Deck's one feature report is unnumbered and Steam drives it command->response, so its proof rides that existing contract via a private two-byte command. Verified: feature 0x85 returned magic "PFCP", proto 3, pad_index 0, wudf_pid 18456 — and 18456 was a WUDFHost — with the product string still 'DualSense Wireless Controller'. Also renamed pf-dualsense -> pf-gamepad. One driver has always served four identities, so the old name read as if the other three lived elsewhere. ONLY the package identity moved (crate, INF/CAT/DLL, UMDF service, build script, CI lines, log file, env var). The four HARDWARE IDS are deliberately unchanged — they bind every devnode the host creates and every installed system — as are the Global\pfds-boot-<i> mailbox and PAD_MAGIC, which are wire contract. `driver install --gamepad` now retires the pre-rename store package first, matched on pf_dualsense.dll because that string appears only in the OLD inf; matching on the hardware ids would delete what we are about to install. On .173 that separated 14 stale packages from the 1 new one with 0 ambiguous, and the renamed package binds the old hwid (devgen root\pf_dualsense -> oem143.inf = pf_gamepad.inf). The repo's own pre-commit/pre-push rustfmt hooks named the old crate, so they caught the rename before the commit did — they now check pf-gamepad, and pf-mouse alongside it, which they had been missing relative to the CI line. Host and drivers MUST ship together: v2<->v3 fails closed in both directions by design, with the existing "update host + drivers together" diagnostic. The rename moved files that also carry the security change, so splitting this into two commits would mean reconstructing an intermediate state that was never gated. It is one commit on purpose. Gated on the windows-amd64 runner with cargo clean first (the box's clock lags, so stale artifacts would read as a vacuous green): clippy -D warnings clean for pf-inject, pf-capture and pf-driver-proto, drivers workspace build + the CI clippy line clean, cargo check --release -p punktfunk-host clean, 19 + 58 tests green. Also fixes pf-mouse still writing its debug log to world-writable C:\Users\Public, which the 2026-07-17 review moved for the other three drivers and missed here. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 16:54:40 +02:00
enricobuehlerandClaude Opus 5	a98174ebfa	feat(host): anchor-test, and libei says which output absolute input landed on ... The absolute-region ladder existed for one case a unit test can only simulate — two heads of the SAME size, where matching a libei region by the streamed mode is a coin flip — and that case had never been run against a real compositor. It was also unobservable: the log said which regions the EIS server offered, never which one a coordinate went into, so "the pointer is on the wrong monitor" could only be discovered by looking at a monitor. libei now reports the chosen region once per distinct answer, beside the existing miss warning: one covers an anchor that named nothing, this one covers an anchor that matched something, by saying which. `anchor-test` is the gate that reads it, in the shape mirror-test established: it enumerates the heads, SAYS whether the rig actually has two of the same size (a green run on a single-head box proves nothing), anchors at a named one (or `--none` for the A/B that makes the anchored run mean anything), and walks the corners. It refuses to run off libei rather than emitting a green result about a ladder that isn't there. On-glass on KWin 6.7.3 with `kwin_wayland --virtual --output-count 2` (regions 1920x1080+0+0 and +1920+0): unanchored picks +0+0, anchored at Virtual-1 picks +1920+0, anchored at Virtual-0 picks +0+0. That is open item 3 of design/per-monitor-portal-capture.md §8b, closed. Clearing the pin now logs too — setting one always did, and the streamed screen going back to virtual is the same size of change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	d461d889c3	feat: the streamed screen is a persisted setting, pickable from the console ... P4 of design/per-monitor-portal-capture.md. The pin was an env var read once at startup, which a console picker can never write — so it becomes a field of the display policy (orthogonal to presets, like game_session), and `vdisplay::capture_monitor()` resolves env-over-policy: an appliance that pinned in its unit's host.env stays pinned there, and a console click cannot re-aim a machine whose operator already declared the answer. Read per `open` rather than cached, so a picker change takes effect on the next session instead of the next host restart. The host re-resolves the input anchor on every policy write — including clearing it when the pin is cleared, or a later virtual-display session inherits an anchor aimed at a monitor it is not showing. `with_manual_layout` carries the pin through like the other orthogonal axes: without that, saving a display ARRANGEMENT would silently swap the streamed screen back to virtual. Console: a "Streamed screen" card listing the host's real monitors beside "Virtual screen (default)", saving on selection. A disabled head is listed but not selectable (so "why isn't it here?" has an answer), and an env-pinned host renders read-only with the reason rather than offering controls that silently lose to the environment. Verified on GNOME/Mutter: pinning via the policy file alone (no env) routes sessions to the mirror and anchors input; setting the env to a different connector overrides it, exactly as documented. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Opus 5	358cfa4be4	feat(host): mirror-test — the on-glass gate for per-monitor capture ... Opens the display backend exactly as a session would, attaches a capturer and reports the frames a named head actually produces, with no client involved. `--monitor` names the head explicitly (it cannot go through PUNKTFUNK_CAPTURE_MONITOR: pf_host_config parses the environment once and startup already read it, so a tool setting it for itself would still see the old snapshot — hence vdisplay::open_mirror); with no argument it exercises the production routing through the pin. A frame timeout is NOT treated as failure. Compositor capture is damage-driven — the host's own capture diag logs new_fps=0 for virtual outputs on an idle desktop for exactly this reason — so the first version of this tool ended its measurement on the first idle gap and made a working mirror look like a 2-frame stall. Verified on KWin 6.7.3 (home-nobara-1), mirroring HDMI-A-1: 346 frames in 20s at 1920x1080, arriving while input was injected and pausing when the desktop went quiet, on both the CPU (BGRx/MemFd) and zero-copy (NV12 dmabuf) paths, ownership=External. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 23:51:41 +02:00
enricobuehlerandClaude Fable 5	aca5aa9993	feat(host+inject): pen P1 — per-session uinput virtual tablet, HOST_CAP_PEN live ... The Linux injection leg of design/pen-tablet-input.md: 0xCC/0x05 pen batches now route through the per-session PenTracker into a lazily-created 'Punktfunk Pen' uinput tablet (BTN_TOOL_PEN/RUBBER, pressure, tilt-from-polar, ABS_Z barrel roll, hover distance, INPUT_PROP_DIRECT) — compositors pick it up via libinput and hand apps zwp_tablet_v2 with full fidelity. The host now advertises HOST_CAP_PEN when /dev/uinput is accessible (PUNKTFUNK_PEN=0 kill-switch); transitions group into SYN frames so proximity-enter carries its position. Stroke failsafe: clients heartbeat ≤100ms while in range (documented wire contract — capture APIs are silent for a stationary pen); 200ms of silence force-releases. 'punktfunk-host pen-test' draws a pressure-ramped sine stroke through the real tracker→uinput chain, no client needed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 16:18:31 +02:00
enricobuehlerandClaude Fable 5	cc6b37fef0	fix(host/linux): emit absolute pointer/touch on region-less EIS devices + abs input-test probe ... gamescope's "Gamescope Virtual Input" advertises pointer_abs but no region, so every MouseMoveAbs (and the degraded-touch moves built on it) was silently dropped (emitted=false) — clicks then landed at a stale cursor position. With no region, the managed session runs at the client's mode, so client pixels are output pixels: emit them raw. Also: log region count/dims at device-resume, and add PUNKTFUNK_INPUT_TEST_ABS=WxH to `input-test` (corners + center, 1s apart) so the degraded-touch path is verifiable with xdotool alone. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 10:36:05 +02:00
enricobuehlerandClaude Fable 5	85dd2bb077	feat(host/windows): resident virtual HID mouse (pf-mouse UMDF minidriver) ... Headless Windows hosts (no dongle) stream an INVISIBLE cursor: with no pointing device present win32k reports SM_MOUSEPRESENT=0 and DWM never composites a pointer into the pf-vdisplay frame, even though SendInput moves it. Keep ONE virtual HID mouse devnode alive for the host's lifetime — the Sunshine/Parsec-class fix, zero client changes. - pf-mouse: UMDF2 HID minidriver, one fixed identity (PF:MO 5046:4D4F, obviously virtual, nothing fingerprints it), one 8-byte input report (5 buttons + absolute 15-bit X/Y + wheel + AC-pan). Transport is the sealed pad channel verbatim (Global\pfmouse-boot-0 mailbox + unnamed MouseShm DATA section) so pf-umdf-util's audited layer serves it unchanged; report delivery is event-driven (idle = no HID traffic). - host: inject::mouse_windows — VirtualMouse (SwDeviceCreate'd devnode + channel), ensure_resident() keeper thread started by every InjectorService (process-wide, PUNKTFUNK_NO_VIRTUAL_MOUSE opts out), vmouse-spike on-glass validation (cursor sweep via HID reports). - proto: mouse module (magic, boot-name, identity, report layout, unit-tested input_report packing). - SwDeviceProfile grows container_tag so the mouse's ContainerId family (PFMO) never groups with a pad's (PFDS) in the Devices UI. - packaging: pf-mouse rides the gamepad-driver build + install pipeline (build-gamepad-drivers.ps1, windows-drivers.yml, driver install --gamepad picks up every staged .inf). On-glass validated on winbox: devnode + HID child bind, SM_MOUSEPRESENT=1 with no physical mouse, cursor sweeps via HID reports (vmouse-spike). This work was implemented in a parallel session; committed here as the build prerequisite for the HID compose kick that follows. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 11:02:10 +02:00
enricobuehlerandClaude Opus 4.8	47587827ec	refactor(host/W6.0): hoist GamepadEvent/GamepadFrame to punktfunk_core::input ... First de-coupling for the host crate carve (plan §W6.0 / §2.4): the GameStream (Moonlight-plane) decoded controller types were defined in gamestream/gamepad.rs — the "junk drawer" — yet consumed 18× by the platform-neutral input injectors AND by the Moonlight decode path. Once inject becomes pf-inject, reaching them via crate::gamestream would be an illegal upward edge. Move the two types to core::input (below both planes; inject already depends on core) and repoint every consumer. Also consolidate the duplicated MAX_PADS onto the existing core::input::MAX_PADS. The gamestream BTN_* const aliases stay for now (separate follow-up); decode()/rumble/tests remain in the Moonlight plane, now importing the types from core. Verified: Linux (home-worker-5) clippy -p punktfunk-core -p punktfunk-host --all-targets -D warnings + gamepad tests green; Windows (192.168.1.158) clippy -p punktfunk-host --features nvenc,amf-qsv --all-targets green (the inject/windows/* consumers compile). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-17 00:49:38 +02:00
enricobuehlerandClaude Opus 4.8	4ffa2665ac	refactor(host): extract src/devtest.rs — the standalone dev/test subcommands ... Per plan §W5 (main-cli, 'devtest.rs land first'): move the inline-bodied dev/test subcommand handlers out of main.rs's match into src/devtest.rs — input_test (Linux libei/wlr injection smoke test + its non-Linux stub) and the virtual-gamepad exercisers dualsense_test/switchpro_test (Linux UHID) and deck_windows_spike/ dualsense_windows_test (Windows UMDF + Steam Deck devnode spike). main.rs's arms become one-line forwards; main.rs drops 1004→667 lines. The thin arms that already forward to subsystem modules (zerocopy/capture selftests, probes) stay put — that is their correct layer. Pure code-move (bodies verbatim; crate-local refs qualified with crate::; one doc reword to dodge clippy doc_lazy_continuation now that an arm comment became a /// doc). Verified clippy 0/0 on BOTH Linux (home-worker-5, nvenc,vulkan-encode,pyrowave) and Windows (.173, nvenc,amf-qsv — covers the cfg(windows) handlers). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-16 15:54:57 +02:00