111 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	77f0a25d18	feat(drivers/pf-gamepad): ship the xinputhid bus filter, so Windows finally promotes our Xbox pad ... The field report that started this work was an Xbox controller that no game could see on a Windows host for two weeks. Root cause was that our Xbox pad reaches no Windows input API a modern title uses. This is the fix, and it is two registry values. Windows promotes Xbox pads with `xinputhid`, whose INF is an explicit hardware-id ALLOW-LIST — its own comment says "we can not use a Compatability ID for the loading of this driver, and so rely on individual hardware IDs". A software-enumerated devnode can never match those ids, so we write what the matching install sections would have written. `045E:0B13`, the PID this identity already claimed, is on that allow-list twice, so the identity choice turned out to be exactly right. 🛑 THE PAIRING IS THE WHOLE FINDING, AND THE TWO VALUES GO IN DIFFERENT KEYS. `UpperFilters` is a `.HW` AddReg (hardware key); `DevicePropertyFlags` is a DDInstall AddReg (software key). A live A/B on .173: removing `DevicePropertyFlags` alone reverts EVERYTHING — no `IG_00`, no XUSB interface, no XInput, no WGI entry — while `UpperFilters` alone is completely inert. `1` = `BusDevice`, which Microsoft glosses as "a focused bus filter driver for the IG_ problem". It is not a description of the device, it is the switch. An earlier session installed the filter WITHOUT it, measured a device that produced nothing, and recorded "never ship it". The filter was never broken; it had never been switched on. That conclusion is now retracted. ⚠️ The Xbox line gets its OWN DDInstall section, `pfGamepadXbox`. All five identities previously shared `pfGamepad`, so an AddReg there would have handed a DualSense, DualShock 4, Edge and Steam Deck to Microsoft's Xbox translator. The regression check below exists for exactly that. MEASURED ON .173 (Win11 26200), INF-SHIPPED — no hand-written registry values: * `UpperFilters=xinputhid` lands on the hardware key and `DevicePropertyFlags=1` on the software key, applied by the INF at install. * The HID child gains the `IG_00` token: `HID\PUNKTFUNK&IG_00\...`. * An XUSB interface appears: `\\?\hid#punktfunk&ig_00#...#{ec87f1e3-...}`. * classic XInput reads it live — packets ADVANCING, `buttons=0x1000` (the devtest's A), and the stick sweeping. XInput had NEVER seen this backend before. * `XInputSetState` rumble round-trips: `rumble from game: pad=0 low=65535 high=32767`. * REGRESSION CHECK PASSED: with the DualSense identity up, its devnode has an EMPTY `UpperFilters` and no `DevicePropertyFlags`. The PlayStation pads are untouched. WGI `Gamepad` lists the pad but reads `ts=0`. That is NOT ours: a real Xbox Elite Series 2, promoted by Microsoft's own driver on the same box, reads `ts=0` in WGI at the very moment classic XInput is reading live data from it (`buttons=0x1000 LY=-32768`). Our pad is behaviourally indistinguishable from real hardware here; the row is a property of the non-interactive session. NOT VERIFIED * On-glass in a console session. Everything above ran over ssh, which is what makes the WGI row unreadable; the real-Elite control is what settles it, not a clean WGI reading. * GameInput — no binding in the `windows` crate, still unmeasured for this backend. * `PUNKTFUNK_XBOX_BACKEND` still defaults to XUSB. This changes what the HID backend CAN do; it does not change which backend is chosen. That is WP-E and it is a separate decision. * Trigger-actuator enable bits, still conjecture — `XINPUT_VIBRATION` has two members and cannot exercise them.	2026-08-09 20:18:49 +02:00
enricobuehler	f9fe496dbc	feat(drivers/pf-gamepad): declare the rumble output report, and the Xbox pad gets rumble at all ... `XBOX_RDESC` declared no OUTPUT item — zero `0x91` bytes. hidclass routes an output report only if the descriptor declares one, so `on_output_report` never fired, `publish_output` never wrote the out-ring, and `parse_xbox_output` in `inject/windows/xbox_windows.rs` was unreachable code. The entire host-side rumble plane was already built, wired and tested, and was simply never fed. The HID Xbox pad therefore had NO rumble whatsoever, not merely no trigger rumble. This appends the PID-page `Set Effect Report` collection, report id `0x03`, 8 payload bytes, sized to exactly the layout `parse_xbox_output` and `design/trigger-rumble-plane.md` §2.1 already specify. It is declared AFTER the final Input item and re-states every global it uses, so the 16-byte input layout `xbox_proto`'s tests pin is untouched. ⚠️ PROVENANCE: hand-written, and it could not be otherwise. The Elite capture taken for WP-A reports `OUTPUT items: 0` — Windows exposes no literal descriptor bytes and the reconstruction carries no output collection for that pad — so there was nothing to copy. The comment says so and asks for a Linux hidraw capture to replace it. Also adds a compile-time assert pairing every descriptor with its HID-descriptor `wReportLength`. Those are two copies of one length, edited in different places, and a mismatch fails SILENTLY: hidclass asks for `wReportLength` bytes, parses whatever it got, and the pad either enumerates truncated or not at all with nothing naming the cause. It now cannot build out of step. This caught nothing today because I updated both by hand, but it is exactly the trap this descriptor has already sprung twice in other forms. MEASURED ON .173 (Win11 26200), with the pad promoted via the WP-B0 xinputhid bus-filter config: * `XInputSetState(0xFFFF, 0x8000)` produced, on the host side, `rumble from game: pad=0 low=65535 high=32767` `rumble from game: pad=0 low=0 high=0` i.e. XInputSetState -> xinputhid -> HID output report 0x03 -> on_output_report -> out-ring -> parse_xbox_output -> PadFeedback. First rumble this backend has ever delivered. * The round-trip values confirm the descriptor's `Logical Maximum (100)` percent domain is right: 0x8000 -> 50% -> 32767. A 0..255 domain would have produced different numbers. * This also answers `trigger-rumble-plane.md`'s WP0 gate — YES, Windows writes output reports to a synthesized 045E:0B13 — which was blocking the whole trigger plane. * classic XInput reads the pad fully: packets advancing, `buttons=0x1000` (the devtest's A), and `LX [-32768..31744]`, the complete sweep. LY/RX/RY frozen is correct; the devtest drives only LS-X and A. VERIFIED * `cargo test -p pf-inject --lib xbox` 11/11 — the input layout is byte-identical, as intended. * `hid-descriptor-dump --rust-source ... --symbol XBOX_RDESC` decodes it clean: input report 0x01 unchanged at 16 bytes and the same offsets, new output report 0x03 at 9 bytes on the wire, feature 0x85 unchanged, `structure: OK`. * Driver builds and signs on .173 with the WDK; the new const asserts compile, so all five descriptor/wReportLength pairs agree. * fmt clean on both tools; .173 fully reverted afterwards. NOT VERIFIED * The enable-mask bit assignments for the two TRIGGER actuators. `XINPUT_VIBRATION` has only two members, so XInput can never drive them and this run could not exercise them. Still open, as trigger-rumble-plane.md WP0 says. * That this equals the real pad's output collection, byte for byte. Needs Linux hidraw. * Nothing about the INF is changed: `pf_gamepad.inx` still has no AddReg, so none of the promotion config ships. The rumble descriptor is inert until something drives it.	2026-08-09 20:07:34 +02:00
enricobuehler	ae35e8b4d7	test(tools): capture the real Xbox descriptor, because ours was invented and disagrees with it ... `XBOX_RDESC` is the only report descriptor in `pf-gamepad` that was hand-written rather than captured off hardware, and its own provenance warning has now come true three times. The fix for that class of bug is not another careful reading — it is a tool that goes and asks the device. `tools/hid-descriptor-dump` does that: it dumps a real HID device's report descriptor, decodes it into an annotated item listing plus a bit-offset LAYOUT TABLE, and can decode a blob we already ship through the same decoder (`--rust-source <file> --symbol <NAME>`) so the two are diffable line for line. `--read N` pulls live wire bytes, which is the only ground truth a reconstructed descriptor cannot give you. Deliberately NOT a workspace member — it pulls `hidapi`, a C library wanting libudev on Linux, which has no business in `cargo build --workspace` or on a CI leg with no pad attached. It is a bring-your-own-hardware tool and it is excluded in the root manifest, so CI never sees it. The captured Elite disagrees with our blob in four ways, and the dangerous one is field ORDER: the real pad reports sticks, ONE combined 16-bit Z trigger, then BUTTONS, then the hat, in an UNNUMBERED 15-byte report; ours declares Report ID 1, two Simulation-page trigger axes, then the hat, then 15 buttons. Since we claim a genuine Microsoft VID/PID and SDL/Steam/Windows all apply stock mappings keyed on it, that ordering difference is exactly how every control silently lands on the wrong action. The driver comment now records the diff and the two blockers that stop the capture from simply being pasted in. VERIFIED * `cargo fmt --check` clean, `cargo clippy --all-targets -- -D warnings` clean (macOS). * The tool builds and runs on macOS and on .173 (Windows 11 26200, cargo 1.96, MSVC, no WDK). * TOOL VALIDATED AGAINST A KNOWN-GOOD CONTROL: pointed at the live DualSense on .173, it reproduces the real `DUALSENSE_RDESC` layout exactly (input 0x01, 64 B, X,Y,Z,Rz,Rx,Ry at bytes 1..6, hat 8.0, 15 buttons 8.4, output 0x02, the full feature ladder), and `--read` returned live len=64 reports with sticks centred at 80 80 80 80 and the counter incrementing. * `cargo metadata` on the root workspace still resolves and does NOT list this crate. * The Elite capture is reproducible: `--vid 045E --pid 0B22`. NOT VERIFIED * That the capture equals the pad's NATIVE report map. Windows exposes no API for a device's literal descriptor bytes, so hidapi reconstructs from `HidD_GetPreparsedData` — faithful in structure, item order and bit offsets, not byte-exact (measured: the DualSense's real 273-byte descriptor reconstructs to 467). `xinputhid` also filters that pad, and the captured shape is the legacy DirectInput view. A byte-exact answer needs Linux hidraw. * Why the Elite returned ZERO input reports across two runs (72 s and 90 s) while the DualSense streamed fine on the same code path — untouched pad, or exclusive claim by the XInput translator. Unresolved. * Nothing here was built on Windows as a driver: `XBOX_RDESC` itself is UNCHANGED, so no behaviour changes. The only edit to the driver is its provenance comment.	2026-08-09 19:02:13 +02:00
enricobuehler	f34acf1d73	fix(drivers/pf-gamepad): the Xbox descriptor never declared the channel-proof report, so the pad served neutral forever ... `XBOX_RDESC` declared only Input report 1. The sealed pad channel delivers its DATA section over a vendor Feature report `0x85` (`ProofTransport::HidFeatureReport`), and the proof handler's own comment records the assumption that made this invisible — "0x85 is already declared as a Feature report in all three captured descriptors". True of the captured PlayStation blobs; false of this hand-constructed one. So hidclass rejected the host's `HidD_GetFeature` before the driver ever saw it, the host refused to hand over the section, and the pad answered every read with its neutral report. The HID Xbox pad had never delivered a single input report since it was written. Declaring `0x85` with a 63-byte payload (1 id + 63 = 64 = FeatureReportByteLength) fixes it. Verified on glass on .173: `gamepad driver attached to the shared section proto=3 late=false`, and WGI's RawGameController path then reads the pad live — advancing timestamps, the devtest's left-stick sweep, buttons toggling. Before the fix: 12 consecutive samples, one frozen timestamp, every axis at dead centre. This is the descriptor-provenance warning in this file coming true. It is still CONSTRUCTED rather than captured, and that remains the open risk — `xinputhid` appears to validate the descriptor and refuses ours, and a real Elite is a multi-collection device where ours has one. Codec layout tests still 11/11; fmt clean. Only device_type 4 is affected, which nothing shipping uses yet.	2026-08-09 18:16:24 +02:00
enricobuehler	d2a2bcc25d	feat(drivers/pf-xusb): answer the async input wait, and put xinputhid on the stack ... The two things this driver's README has always listed as the missing WGI/GameInput work, both user-mode, neither needing a bus driver: `IOCTL_XUSB_WAIT_FOR_INPUT` is now pended on a manual queue and completed by the periodic timer on a dwPacketNumber edge, answering with the same 29-byte GET_STATE payload the synchronous path serves. Declining it was enough for classic xinput1_4, which just falls back to sync GET_STATE polling — that is why the pad has always worked there. It is not enough for WGI/GameInput, which poll asynchronously: to them a decline is a refusal, not a fallback. Completion is edge-gated because releasing a waiter on an unchanged packet spins its caller at timer rate. WAIT_GUIDE_BUTTON stays declined — we have no state to signal on. The INF adds UpperFilters=xinputhid on the XUSB devnode. Note the earlier attempt put that filter on the HID child of the *other* backend, which was simply the wrong devnode: XInput does not read HID at all, it enumerates GUID_DEVINTERFACE_XUSB, which is what this driver registers. Verified on .173: build + sign + catalog exit 0; infverif "INF is VALID"; the devnode starts Status OK with UpperFilters=xinputhid readable back from its enum key; and XInput still sees the pad (slot 1 live alongside the box's real Elite in slot 0), so the async queue is no regression to the path that already worked. NOT yet measured: whether WGI/GameInput now admit the pad. `IG_` is the wrong probe for this driver — it is a HID-path artifact and pf-xusb is System-class with no HID child, so its absence says nothing either way. That needs a real WinRT/GameInput enumeration test.	2026-08-09 17:29:10 +02:00
enricobuehler	d498ff4a60	test(drivers): give the Xbox identity a root-enumerated id, and verify the whole thing on Windows ... `root\pf_xboxwireless` alongside the plain id, mirroring the DualSense model line — the INF already documents that variant as the one devgen/devcon tests bind, and without it the Xbox identity could only be exercised through a running host. Verified end to end on .173 (Windows 11 26200, WDK 10.0.26100.0): - build-gamepad-drivers.ps1 builds + signs + catalogs the driver, exit 0 - infverif /v /w on the generated pf_gamepad.inf: "INF is VALID" - pnputil stages the package; devgen creates the devnode; it starts clean: Status OK, Class HIDClass, "Punktfunk Virtual Xbox Wireless Controller" - it enumerates a HID child, Status OK, carrying HID_DEVICE_SYSTEM_GAME and HID_DEVICE_UP:0001_U:0005 — Windows parsed the constructed report descriptor and classified the pad as a Game Pad (usage page 0x01, usage 0x05), which is precisely what pf-xusb could never do Test devnode, phantom child, driver package and both certs were removed afterwards. Two build gotchas worth knowing, both already handled inside build-gamepad-drivers.ps1 and both of which cost a cycle here: CARGO_TARGET_DIR pointing outside the workspace breaks wdk-sys (wdk-build walks up from OUT_DIR looking for a Cargo.lock and finds none), and the WDK version must be pinned via Version_Number=10.0.26100.0 or bindgen picks SDK 10.0.28000.0, which ships no km/crt headers. Still open: the SwDeviceCreate USB identity (HID\VID_045E&PID_0B13) cannot be checked through a devgen node, which has no USB hardware ids — that needs the host path. So the WGI-promotion question is still unanswered, and host routing is still unwritten.	2026-08-09 16:54:00 +02:00
enricobuehler	f266636392	feat(host/pads): an Xbox pad on Windows becomes a real HID device, so Steam can see it ... `pf-xusb` registers only GUID_DEVINTERFACE_XUSB and exposes no HID collection, so Steam's hidapi enumeration, DirectInput, joy.cpl and WGI/GameInput cannot see the pad at all — only classic XInputGetState via xinput1_4's interface walk ever does. A reporter spent two weeks on a dead controller for exactly that reason; switching the client to DualSense, a real HID pad through the pf-gamepad UMDF driver, fixed it in seconds. This gives the Xbox pad that same footing: a new device_type 4 on the existing HID minidriver, identified as a Bluetooth Xbox Wireless Controller (045E:0B13). The wired ids the tree already uses (045E:028E, 045E:02EA) are vendor-class XUSB/GIP devices with no HID interface on real hardware, so a HID child claiming one is a device that has never existed and has nothing for Windows to promote. Driver: identity, a constructed 132-byte Game Pad report descriptor, neutral report, strings and the pf_xboxwireless hardware id. Host: `xbox_proto`, the byte-exact codec mirroring that descriptor, with 11 layout tests. One shared-path fix falls out. The timer completed every pended READ_REPORT with the full 64-byte slot, and `copy_to_output` REFUSES a source longer than hidclass's buffer rather than truncating it — so a pad declaring a shorter report would have failed every read and looked dead. Report length is now per-identity; it returns 64 for all four pre-existing pads, so their behaviour is provably unchanged. NOT BUILT AND NOT RUN ON WINDOWS — no box was reachable. The Rust codec and its tests pass on macOS; the driver, the INF and the report descriptor have never been compiled, infverif'd, or seen by a real pad. The descriptor is constructed rather than captured, which matters because we claim a real Microsoft VID/PID and SDL/Steam/Windows carry stock mappings keyed off it — diff it against a capture before shipping.	2026-08-09 12:11:04 +02:00
enricobuehler	ce5047f3ad	fix(host/pads): the Windows driver stops halving motion and stops serving torn reports ... G6 + G15 of the gyro program. G6 — the UMDF gamepad driver's input path. Its timer ran at 8 ms and completed one pended READ_REPORT per tick, so a game could observe at most ~125 Hz while clients stream motion at ~250 Hz: every other sample was overwritten in the slot before anything read it, and the ones that survived carried up to 8 ms of extra latency. For gyro, a dropped sample is not a dropped frame — it is rotation that never reaches the game. The timer now ticks at 2 ms (about a real DualShock 4's Bluetooth cadence). Only the cheap half runs on every tick: read the input slot, complete one pended read. The channel handshake and the health marks stay on their historical ~8 ms, because they cost more, nothing wants them faster, and `driver_heartbeat`'s documented "+1 per ~8 ms tick" is what the host reads as liveness. The same slot is a single unqueued buffer that both sides touch without a lock, so a driver read landing mid-copy handed the game a report that was half the previous frame and half the next. For a button that is a one-tick glitch; for motion it is a spike in angular velocity, which an integrator turns into aim movement. `PadShm` gains an `input_gen` seqlock (v2.3, carved from reserved space inside the v2 legacy region): the host takes it odd, fences, writes the 64 bytes, and stores it even; the driver samples it either side of its read and retries once. The old code's own comment called this out as a known residual — it is now closed rather than documented. Version posture matches the ring's, with one simplification: no capability stamp is needed, because an old host never writes the field and a constant 0 is indistinguishable from "no write in flight", so a new driver against an old host behaves exactly as it does today, and an old driver ignores the field entirely. The Steam Deck write path had neither the seqlock nor even the trailing Release its DualSense sibling carried; all three Windows backends now publish through one `publish_input`. G15 — motion-cadence observability. The host already computed the measurement a "gyro feels floaty" report needs (client inter-arrival percentiles), but kept ONE global accumulator, so two motion-capable pads in a session interleaved into each other's gaps and produced a number describing neither. It also sat at `debug` behind a `tracing::enabled!` check, so a field log arrived with nothing in it and the only way to get the measurement was to ask for a re-run. Now per-pad and always on, summarized at `info` when the session ends — the moment a field report is being written. It costs one subtraction and one array increment per sample: percentiles come from a fixed log2 histogram instead of a growing sorted Vec, so there is no allocation, no per-window sort, and no way for a client streaming as fast as the link allows to make the instrument expensive. Percentiles are reported as bucket upper bounds (`_le`), which is a factor-of-two answer to a question whose answers are orders of magnitude apart. Gaps of 500 ms or more are counted as stalls rather than folded into the percentiles — an interruption is not a cadence, and averaging it in would report a healthy feed as a terrible one. Gates. Windows CI runner .133, the drivers workspace on the real WDK: cargo build, clippy -D warnings (which enforces the unsafe-audit lints), and fmt — all green, against a source whose SHA-256 matches this commit's. Linux CI image: fmt, build, clippy --all-targets -D warnings over pf-inject / punktfunk-core / punktfunk-probe / pf-client-core / pf-driver-proto / punktfunk-host, and the test suites including the 5 new motion-cadence tests — all green. Not measured on glass. G6's stated gate is a sensor-rate reading (SDL testcontroller or Steam's calibration screen) that matches the client's send rate; that is still owed, and a driver change only a compile has seen deserves it before anyone trusts the number.	2026-08-07 13:44:54 +02:00
enricobuehler	4834c2ee51	fix(host/pads): DualShock 4 gyro ran 40× fast, and no pad ever stopped turning ... Phase 1 of the gyro program (design/gyro-program.md, G1-G5) — the five correctness fixes under it. Gyro aim integrates angular velocity over time, so each of these is not a cosmetic wrongness: a wrong scale is every rotation being the wrong size, a wrong clock is every rotation being integrated against a fictional dt, and a stale sample is rotation that never happened. G1 — the DualShock 4 calibration blob. A Sony pad does not assume a motion scale, it reads one out of a fixed calibration feature report. Ours declared 0.5 LSB per °/s and 8192 LSB/g while the wire delivers 20 and 10000, so every DS4-type session decoded gyro 40× too fast and acceleration 1.22× hot — since the backend shipped. The blob now states the wire's own units (the DualSense blob's numbers, deliberately: both pads consume the identical wire sample). Its interleaved per-axis order is NOT a bug and stays: the virtual pad declares BUS_USB, where interleaved is the correct layout; grouped is Bluetooth's. The same blob lives a second time in the UMDF driver, which is a separate WDK workspace that cannot depend on pf-inject — one wrong table in two files, where fixing one reads as fixing it. Both are fixed, and the DS4 feature reports now live in dualshock4_proto beside the DualSense's rather than in the Linux backend, so there is one canonical copy to point at. Field hosts keep the old blob until they update the host package. G2 — the gate that would have caught it. Nothing pinned any backend's declaration against the wire, so tests/motion_contract.rs now applies the CONSUMER's arithmetic (the kernel's, and SDL's, which differ) to each backend and asserts the result lands back on the wire constants — for the DualSense and DS4 blobs, and for the Deck and Switch Pro rescales. It also parses the driver's Rust source and re-derives the units from THAT, so the two copies cannot drift. Verified non-vacuous both ways: re-introducing the old blob fails with "declares a fractional 32/64 LSB per °/s", and reverting only the driver's copy fails with "the UMDF driver's DS4_FEATURE_CALIBRATION has drifted from pf-inject's". The wire units themselves move to punktfunk_core::input::gamepad, referenced by the client's capture scale, the Deck/Switch rescales, and the probe — whose at-rest vector said 16384 (a driver's number, not the wire's) and now says 1 g. G3 — real sensor clocks. The DualSense advanced its sensor timestamp by +1 raw unit per report (0.33 µs — a frozen clock) and the DS4 by a flat +188 (~1 ms) regardless of the real 4-8 ms cadence. Anything integrating rate × dt off that field got nonsense. All four backends now stamp elapsed monotonic time in their own units via a shared SensorClock, anchored to the pad's first report so an irregular publish loop cannot make it drift, and truncated to the field width — which reproduces the wrap real hardware does. G4 — motion is level-triggered and had no watchdog. merge_frame preserves the last sample and the heartbeat re-emits it, so a feed that stops leaves the pad rotating forever — and with G3's honest clock, at a dt that keeps growing. Rumble and the pen plane each have an idle timeout; motion now has one too, at 100 ms. Angular velocity only: acceleration is kept, because gravity is legitimately persistent and blanking it reads as free-fall. The SDL client parks its gyro at zero when a slot closes, which is the case we can flush rather than wait out. (The Apple half of this rides in PR #88.) G5 — a pad returning inside the 300 ms replug grace keeps the same device and skips the create path, so a different controller inherits the previous one's touch contact and rotation — and a pad with no gyro never sends a sample to correct it. sweep() now reports re-claims separately from drops, and the manager clears the rich plane on one. Rich fields only: rumble and hidout dedup deliberately survive a removal. Gates (Linux, CI image): fmt, build, clippy --all-targets -D warnings over pf-inject/punktfunk-core/punktfunk-probe/pf-client-core, and the test suites — 110 pf-inject unit + 6 contract + 29 pf-client-core gamepad, all green. Not yet verified on glass; the on-glass sign/scale session is G16.	2026-08-07 12:47:26 +02:00
enricobuehler	e6bcac8770	chore(license): name the copyright holder "unom - Enrico Bühler" ... "unom" alone is not the legal entity name. Updated the copyright line in all nine first-party license files -- the root MIT/Apache pair and the hand-maintained copies under clients/apple, clients/decky, packaging/windows/drivers and packaging/windows/pf-vkhdr-layer (there is no script that syncs these, so each is edited directly). The Linux and Windows clients' About screens pick this up automatically: both `include_str!` the root LICENSE-MIT / LICENSE-APACHE at compile time. Deliberately untouched: - Third-party license texts (Geist OFL, FFmpeg, VB-CABLE, the vendored pyrowave/Granite tree, KDE protocol XMLs, the os-icon licenses) -- those are other parties' copyrights. - Publisher/author/maintainer metadata, which is identity rather than license text and is reported separately for a decision.	2026-08-06 23:16:16 +02:00
enricobuehler	31b5f90b12	fix(host/windows): two virtual pads stop tearing each other's reports ... Three faults on the Windows pad path, two of them races that only bite when a game drives a pad hard enough for two callbacks to overlap. pf-gamepad's output ring could hand the host a torn report. Publishing is a read-modify-write — read the cursor, write the slot it names, advance it — and the framework dispatches output callbacks in parallel, so two could be inside it at once: both read the same head, both wrote the SAME slot, and both stored head+1, so the cursor moved once for two reports and the host read a single entry with two reports mixed into it. An atomic fetch_add does not fix this. It hands each writer its own slot but advances the cursor before the bytes exist, so the host is then invited to read a slot still being filled. Serializing the publish is what makes the cursor bump mean "the slot below is complete". The ring exists to stop a rumble STOP being coalesced away, and a torn slot can eat that STOP with no idle watchdog behind it. Both drivers also promised the host an ordering they never established. The host loads out_seq and rumble_seq with Acquire and says so in its own comments — "Acquire pairs with the driver's publish-then-bump store order" — but the drivers bumped both with plain writes, and an Acquire load pairs with a Release store and nothing else. On a weakly-ordered core the host could see a fresh seq against stale bytes. pf-xusb's rumble seq was racy in the same way as the ring: two SET_STATE calls could both read one value and both write back value+1, so the host saw one bump for two writes and skipped a level. A skipped stop is the one that hurts — the pad buzzes until the ~2.5 s idle force-off notices the game went quiet, which is what bounds the damage. Diagnosing an unattached driver stalled the session. The pad service thread — the one feeding input and rumble — waited up to two seconds for a pnputil enumeration, per unattached pad, at exactly the moment a session was already going wrong. The diagnosis now runs on its own thread. Off the hot path the wait no longer has to be a compromise, so it is generous enough to report what it actually found instead of giving up with "still enumerating" — which, given pnputil routinely takes longer than the old budget, is what it usually did.	2026-08-04 19:20:01 +02:00
enricobuehlerandClaude Fable 5	02a5bdb965	fix(gamepad): the virtual DualSense stops demanding a firmware update it cannot take ... The emulated pad's firmware-info feature report (0x20) advertised update version 0x0154 — a 2021-era number. PlayStation Accessories compares it against Sony's latest (0x0630 as of 2026-08) and offers an Update that can only end in "can't complete the update", since the virtual pad speaks no DFU; libScePad titles (Stellar Blade) surface the same nag in-game. A real pad plugged in directly reads up to date, which made the prompt look like punktfunk corrupting the controller. The old value was chosen to keep the kernel and SDL on the flag0 COMPATIBLE_VIBRATION convention, but parse_ds_output has since learned the firmware-≥2.24 COMPATIBLE_VIBRATION2 flag as well, so nothing depends on looking old anymore. Advertise 0x0999 — above anything Sony has shipped and comfortably ahead of their ~yearly cadence — instead of chasing their exact latest, which would resurrect the prompt on every Sony release. Writers that read the version now use the v2 flag; both conventions land in the same rumble plane. Bumped in both copies of the blob (host uhid + Windows driver); the DualSense Edge shares them, and its own versioning (0x0217 latest) sits below the new value too. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 10:24:20 +02:00
enricobuehlerandClaude Fable 5	15361b0091	fix(drivers/gamepad): drop the 1 s enumeration wait its own premise doomed, and gate the logger ... The PnP-identity fix established that the sealed channel is STRUCTURALLY unavailable while hidclass enumerates (the DATA section arrives over the HID interface those very queries create) — so device_type()'s bounded 1 s pump loop, reachable only for a devnode whose hardware ids matched nothing, could never succeed there: it burned a second of a WUDFHost dispatch thread mid-enumeration and then fell back to LAST_DEVTYPE anyway. The fallback chain is now wait-free (attached section → PnP identity → LAST_DEVTYPE), and the 8 ms timer refreshes LAST_DEVTYPE whenever the section is attached, so the last resort is always current. The logger also joins its siblings behind file_log_enabled(): a RELEASE driver without the opt-in no longer OutputDebugStringA's (+ CString + format! allocs) per logged event — the rumble OUTPUT hex dumps and the cyclic GET_STRING polls were sustained paths. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-31 00:59:50 +02:00
enricobuehler	2748b84933	style(vdisplay/driver): rustfmt one line the audit bundle left unwrapped ... `5742ec95` landed `create_monitor`'s EDID call split across two lines where it now fits on one, so the drivers workspace fails `cargo fmt --all --check`. Whitespace only — separated from the gamepad work it happened to block.	2026-07-30 23:40:35 +02:00
enricobuehler	00c29f82f2	fix(gamepad/windows): a pad enumerates as the controller it IS, not always a DualSense ... A Steam Deck client streaming to a Windows host had a stuck stick and a stuck d-pad. The virtual pad was enumerating with the DualSense VID/PID **and the DualSense report descriptor**, so Windows parsed the 64-byte Deck frame as DualSense report 0x01: LX = report[1] = 0x00 (stick hard left), LY = report[2] = 0x09 (hard up), and a d-pad hat of 0 — which is UP, held forever. The driver picked its identity from `device_type` in the sealed section, but hidclass asks for the descriptors and attributes while it STARTS the device, and the section can only be delivered over the HID device interface — which does not exist until those queries are answered. The channel was structurally unavailable at the only moment it was needed, so `device_type()`'s bounded wait always timed out and every identity fell back to DualSense. Not a race: DualShock 4 and the Edge enumerated as DualSenses too (verified on .173 — both report 054C:0CE6 with a 64-byte DualSense input report, while their on-demand strings read correctly). The devnode's own hardware ids carry the identity and are readable at EvtDeviceAdd, before anything is asked, so resolve it there. The section stays authoritative once attached; the old wait survives only for a devnode whose ids match nothing. `hwid_devtype_table_matches_the_driver` pins the host's hwid → device_type mapping against the driver's table, including the ordering trap that `pf_dualsense` is a prefix of `pf_dualsenseedge`.	2026-07-30 23:40:35 +02:00
enricobuehlerandClaude Fable 5	5742ec9548	fix(vdisplay/driver): the audit bundle — one timing formula, honest EDID, scoped watchdog, lock-free drain, D0-resume re-init, knobbed RT priority ... One signing pass over the 2026-07-30 audit findings: - Timing math unified (D4): monitor-description and target modes now come from ONE IddSampleDriver-exact builder differing only in vSyncFreqDivider; the virtual-display-rs legacy formula (width-less pixel rate, deliberately fractional vSync) is gone. - EDID (D5): the preferred-timing DTD is built from the SESSION's mode when it fits the encoding (pf-driver-proto's tested builder; 1080p60 stays the fallback); the range-limits descriptor covers everything the driver can advertise (max clock 150 MHz → 2550 MHz, max-H +255 — the old limits were violated by the driver's own 1080p120 default); product code 0 → 1. Deliberately still no HDMI VSDB — documented in the module doc. - INF (D6): UmdfFileObjectPolicy=AllowNullAndUnknownFileObjects added (the sibling drivers all carry it); the dead DeviceGroupId (inert under ProcessSharingDisabled) dropped; the IddCx0102-vs- IddMinimumVersionRequired=10 pairing documented as deliberate — 0102 is the extension's registered identity, not a version request. - Watchdog lifecycle (D7): device cleanup now stops the host-liveness thread (it ran forever and its reap raced device teardown over the same monitor list). - Drain path off the mutex (D8): the per-frame has/take_frame_channel checks (≥60 locks/s per worker on the mutex the whole control plane, the mode DDIs and the watchdog contend) are gated by a delivery generation counter — the steady state takes no lock. - Adapter cache (D9): last-write-wins slot instead of a OnceLock, and a D0 re-entry from a REAL low-power state clears + re-inits — the stale pre-power-cycle handle used to wedge every later IOCTL_ADD. - Realtime GPU priority (D10): IddCxSetRealtimeGPUPriority is now A/B-able without a rebuild (PFVD_NO_RT_GPU, machine env) — no canonical IDD driver raises it, and it preempts the game's and DWM's queues at a level apps can't reach. - Logging (D2): the logger rides file_log_enabled() as a whole — a RELEASE driver without the opt-in no longer OutputDebugStringA's (+2 allocs) per logged event. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:35:32 +02:00
enricobuehlerandClaude Fable 5	1c15ba89c3	fix(drivers/pads): the XInput path stops re-mapping the mailbox, and release logging gets a real off switch ... pf-xusb pumped the sealed-channel bootstrap mailbox — an open+map+close+ unmap plus two heap allocs — on EVERY XInput IOCTL, per pad. A periodic WDF timer (the pf-gamepad pattern) now owns the pump: adoption, re-delivery and host-gone detection happen there, and the IOCTL path reads the cached view. A vanished host still reads as a neutral pad within one 8 ms tick, and the heartbeat mark still advances per serviced IOCTL, so the host keeps seeing the GAME-visible polling path move. Both pad drivers' log() also called OutputDebugStringA unconditionally — a syscall + CString + format! alloc per logged event in RELEASE builds, on per-IOCTL paths (SET_STATE hex dumps during rumble, the cyclic GET_STRING polls). The whole logger now rides the existing file_log_enabled() gate (debug builds, or PF*_DEBUG_LOG), and dbglog! skips its format! too. (pf-gamepad's identical log shape is deliberately untouched: the unpushed fix/deck-hid-identity branch owns that file right now.) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 23:35:32 +02:00
enricobuehlerandClaude Fable 5	e90c5d5bcd	fix(gamepad): the output-report ring absorbs haptics-rate writers (PadShm v2.2) ... A field log (2026-07-30) showed a game driving the virtual DualSense's output endpoint at >2 kHz sustained for tens of seconds. The 8-slot ring — sized on the assumption that 2 kHz is double any real HID output rate — overflowed every 4 ms poll, which force-silenced rumble for each storm's whole duration and flooded the log at ~230 WARN lines/s (96 % of the user's 5000-line web-console export, evicting the session history it was needed to diagnose). Three legs, negotiated so every old/new host×driver pairing keeps working: - pf-driver-proto: the ring grows in place 8 -> 56 slots; PadShm becomes exactly one page (4096 B), the hard ceiling that keeps cross-generation section views mappable. A new out_ring_len field carries the driver's side of the length negotiation. Deliberately NOT a GAMEPAD_PROTO_VERSION bump (that fails closed - no pad at all). - pf-gamepad driver: picks its ring length from the host's out_ring_ver stamp (>= 2 + a full-size map -> 56) and echoes it before every ring_head bump (now a Release store), so an Acquire-observing drain always reads the modulo that indexed the slots it copies. - host drain: follows the echo (0 = old driver = 8); on genuine overflow it now salvages the legacy latest-report slot - the freshest coalesced state - instead of total silence, and the per-poll overflow WARN is rate-limited to 1 line/s per pad with a suppressed count. Verified on the Windows CI runner (drivers workspace build + clippy -D warnings against the WDK; 64 pf-inject tests incl. the new negotiation/ salvage/limiter tests; pf-inject clippy -D warnings) and on Linux via the CI docker image (82 pf-inject tests). DriverVer needs no manual bump - the installer stamps a strictly-increasing build timestamp per release. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-30 18:36:47 +02:00
enricobuehlerandClaude Opus 5	553676282a	feat(windows): the brand reads Punktfunk on every device Windows shows ... Device Manager, the firewall list and the monitor name all said "punktfunk". The brand is Punktfunk. Renamed: the [Strings] blocks of all four driver INFs (device descriptions, install disks, provider, manufacturer), the `description` on every SwDeviceProfile the host creates, pf-mouse's HID manufacturer + product strings, pf-vdisplay's IddCx endpoint friendly + manufacturer names, the EDID 0xFC display-name descriptor — so Windows now shows `Generic Monitor (Punktfunk)` — and the netsh firewall rule names. The EDID edit is a single byte (0x70 -> 0x50) and needs no hand-patched checksum: Edid::generate_with already recomputes both block checksums after patching the serial. Deliberately left lowercase, because these are IDENTITIES rather than display names and renaming them would orphan installed state: * the SwDeviceCreate enumerator `w!("punktfunk")` — it IS the SWD\PUNKTFUNK\... path every pad instance id is built from * pf-paths' `join("punktfunk")` — C:\ProgramData\punktfunk * the CN=punktfunk-driver cert subject, which purge_driver_certs and both driver build scripts match by string * install.rs' `lo.contains("punktfunk virtual display")` probes, whose haystack is to_ascii_lowercase()d, so they already match the capitalised name Nothing is orphaned by the renames that DID happen either: netsh rule names, Get-NetFirewallRule -DisplayName and PowerShell's -match are all case-insensitive, so the firewall delete paths and reset-pf-vdisplay.ps1's -AdapterName / -GhostMatch defaults still reap what every release up to 0.22.1 created. Cosmetic, with two consequences worth knowing: it takes a driver rebuild + re-sign to appear at all, and an existing devnode keeps its cached FriendlyName until it is recreated. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:30:46 +02:00
enricobuehlerandClaude Fable 5	b2168dae6a	feat(vdisplay): stall attribution v1 — the driver testifies which leg lost the frames ... Every IDD-push capture stall now carries a VERDICT instead of a hypothesis list. The shared ring header grows a v2 telemetry tail (drain-loop heartbeat QPC, last-acquire QPC, full-width offered counter) the driver stamps on every drain pass; the host samples it between fresh frames and attributes each stall: worker-stalled (our thread starved) / compose-silence (DWM composed nothing — the disturbance is below capture) / delivery-leg (frames existed, our publish/ring/consume lost them). The metronomic WARN prints the running tally, so one pasted log line settles the Branch-1/Branch-2 fork of the vdisplay-disturbance-immunity program per session, per box. Both directions stay version-safe: the tail is gated on the HOST-stamped header version (a v2 driver never writes past a v1 host's 64-byte layout — it maps the whole section instead of a fixed 88 bytes), and a v2 host reads a zero heartbeat as pre-telemetry driver, no verdict. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 23:44:35 +02:00
enricobuehlerandClaude Fable 5	5d018eea7c	ci: the supply chain accounts for itself — per-release SBOM, full-tree audits, a real license gate ... CRA Annex I Part II groundwork (see punktfunk-planning design/cra-readiness.md, Phase 1): * sbom.yml + scripts/ci/gen-sbom.sh: every vX.Y.Z release gets a CycloneDX SBOM attached — syft over both Cargo.locks, all Bun/pnpm trees and the Swift Package.resolved (2,667 components), merged with compliance/sbom/manual-components.cdx.json for what no lockfile records (pyrowave/Granite/volk/Vulkan-Headers pins, libvpl, FFmpeg, SDL3, VB-CABLE, punktfunk-gamescope). * audit.yml: bun audit now covers sdk + plugin-kit (not just web), decky's pnpm tree is scanned, and docs-site runs non-blocking until its known CMS-chain advisories are cleared. All shipping trees verified green today. * license-gate: about.toml's allowlist claim is finally enforced — cargo-about 0.9.1 with --fail over BOTH workspaces. The old [crate.clarify] license-only syntax fails to deserialize under 0.9; migrated ring to a per-crate accepted extension and dropped the stale aws-lc-sys entry (workspace is ring-only). Both gates validated green locally. * drivers/Cargo.lock: sync the pf-dualsense→pf-gamepad rename — the crate rename updated the manifest but the Windows-only lockfile was never regenerated; cargo-about's metadata pass caught it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-29 00:59:29 +02:00
enricobuehler	d2b6f5b65f	docs(unsafe): audit all 49 unsafe impl — one proof was wrong, four were missing ... `unsafe impl Send`/`Sync` is the highest-risk unsafe category here and the one this program had never looked at: a wrong one is cross-thread UB that is invisible at every call site, with no `unsafe` block to catch a reviewer's eye. 49 of them (41 Send, 8 Sync). Two results. **`MappedView`'s `Sync` proof was factually wrong.** It read "only exposes accessors that are safe under concurrent use" — they are not. `read_u8`/`write_u8`/`read_u16` are plain unaligned accesses through `&self`, and `&MappedView` really is shared across threads: `ChannelState::data()` hands out `&'static MappedView`, and pf-xusb, pf-mouse and pf-gamepad all dispatch `WdfIoQueueDispatchParallel` with `NumberOfPresentedRequests = u32::MAX`. The struct's own doc had the right story — consistency is the channel protocol's job — but the `unsafe impl` stated a different, stronger claim, which is the one a reviewer checking that line would rely on. The impl is still sound, for a reason worth writing down: these bytes are mapped into ANOTHER PROCESS that writes them concurrently, so Rust-level exclusivity over them is unachievable no matter what this type does. Sync fields go through the atomic accessors; the plain ones cover only protocol-fenced bytes. The proof now says that, and states the rule it implies for accessors added later — plain path only for bytes the protocol already fences. **Four `Send` impls carried a one-line aside instead of a proof** — the pf-client-core decoders and `DrmFrameGuard`. All four are sound, and each now says why, including the two facts that make them work and were nowhere stated: libav permits a codec context to be used from a thread other than its creator provided use is serialised (`&mut self` is that serialisation), and D3D11's immediate context is thread-AGNOSTIC rather than thread-safe — it wants serialised use, not one fixed thread. Each also records that it is deliberately not `Sync`, which is the invariant a future `impl Sync` would silently break. Every one of the 49 now carries reasoning. Verified: Linux .21 fmt + both CI clippy steps rc=0; Windows .47 `-p pf-client-core` clippy `-D warnings` rc=0 (it compiles the `video_d3d11` proof the Linux run cannot see). The pf-umdf-util edit is comment-only — confirmed by diff, since that crate needs the WDK, which .47 does not have.	2026-07-29 00:37:14 +02:00
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 Fable 5	ab58fd2f0e	feat(vdisplay/driver): DDC/CI against the virtual monitor fails fast ... In exclusive topology the virtual display is the ONLY monitor on the desktop, so monitor-control software (the Twinkle Tray / PowerToys PowerDisplay / Monitorian class) aims its entire DDC traffic — brightness polls, capabilities-string requests — at OUR monitor. There is no bus and no sink; the only wrong answer is a slow one (a timeout-shaped failure occupies win32k's physical-monitor path, serialized per monitor, for its full duration). Register EvtIddCxMonitorI2CTransmit/Receive and answer every probe with an immediate STATUS_NOT_SUPPORTED, making the virtual monitor the cheapest thing on the "bus" to poll. (The receive DDI has no out-arg at the callback — refusing synchronously refuses the whole transaction.) EDID needs no equivalent: the OS serves descriptor queries from the blob supplied at monitor creation without calling the driver. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:37:06 +02:00
enricobuehlerandClaude Fable 5	19d6f79d2d	feat(vdisplay/driver): the frame pump survives MMCSS refusal and outranks GPU contention ... Two stall-immunity hardenings for the swap-chain drain thread (branch-2 of the disturbance-immunity program — failures in OUR delivery leg, as opposed to adapter-wide display servicing, which no priority survives): - MMCSS registration fails under the restricted WUDFHost token on some boxes; the drain thread then ran UNPRIORITIZED — the whole display's frame pump at normal priority, starvable by DDC/HPD-servicing DPC pressure into multi-hundred-ms delivery holes. Fall back to TIME_CRITICAL. - IddCxSetRealtimeGPUPriority (IddCx 1.9) raises the processing device above every regular application's GPU priority. Slot availability comes from raising the exported IddMinimumVersionRequired 4 → 10, which was overdue independently: the drain loop already calls ReleaseAndAcquireBuffer2 (1.10) unconditionally, so binding a pre-1.10 framework would dispatch past the populated IddFunctions table — with 10 an old framework fails the bind cleanly instead. The product floor is already Win11 22H2 (installer MinVersion=10.0.22621, whose framework is 1.10), so no supported system changes behavior. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-27 15:24:10 +02:00
enricobuehlerandClaude Opus 5	0d9d78398c	fix(drivers/windows): name each virtual pad for what it is — one shared description read as "the setting did nothing" ... `pf_dualsense.inx` gave all four hardware ids a single %DeviceDesc%, so Device Manager labelled an emulated DualShock 4, DualSense Edge and Steam Deck pad "punktfunk Virtual DualSense". The HID layer was always per-type — device_type picks the PID (09CC for DS4), the report descriptor and the product string — but the one place a user goes to check said DualSense for every choice, which reads exactly like the controller-type setting being ignored. Split into four model lines over the same install section, one description each. No binding, service or descriptor change; stampinf's 9.9.MMdd.HHmm DriverVer increments on every build, so pnputil takes the update. InfVerif on the WDK runner: INF is VALID. Also correct the Slot.pref comment from the previous commit: emulating a DualShock 4 gives up adaptive triggers by construction. HidOutput::Trigger is emitted only by dualsense_proto, and a DS4 has no trigger-effect reports — the host never generates any to send. Rumble and the lightbar remain. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 16:56:44 +02:00
enricobuehlerandClaude Fable 5	248e1cbf08	fix(pf-vdisplay/driver): report cursor_excluded adapter-wide — the declare's exclusion is not per-target ... Field report (iPad via GameStream, 2026-07-23): cursor missing from the stream. The session's fresh target 257 reported cursor_excluded=false (DECLARED_TARGETS is keyed per target and only 259 had declared), so the host skipped forced-composite — but DWM's pointer exclusion after an IddCx hardware-cursor declare reaches EVERY later monitor of the adapter, not just the declaring target (proven on-glass: declare on 259 under WUDFHost 2192, then 257's frames streamed pointer-free with CURSOR_SHOWING set and SM_MOUSEPRESENT true). GameStream/Moonlight clients cannot draw a forwarded cursor, so those sessions were silently cursor-less. ADD replies now report any-declare-this-WUDFHost-life (the state's real scope — it dies with the adapter reset, same as before); per-target ids stay only as the dbglog audit trail. Channel-less sessions on a declared adapter then hit the existing forced-composite gate (GDI poller + blend) and carry the pointer in-video. Host code unchanged. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 15:58:54 +02:00
enricobuehlerandClaude Fable 5	7058647264	fix(vdisplay/capture): channel-less sessions composite the pointer on a sticky-declared target ... A declared IddCx hardware cursor is IRREVOCABLE for its OS target's life (§8.6), and the sticky exclusion survives monitor REMOVE→ADD because each client gets a STABLE target id — so once any desktop-mode session declared, every later pure-capture session on that target streamed a cursor-less desktop: DWM excluded the pointer, no channel forwarded it, no blend drew it (the exact no-regression gap §8.6's per-session cap gate cannot see). Driver: track every successful SetupHardwareCursor per target (DECLARED_TARGETS — scoped to the WUDFHost's life, exactly the sticky state's scope) and report it in a new AddReply::cursor_excluded tail field (dual-size discipline, both skews degrade cleanly; no proto bump). Host: the flag rides AddedMonitor → Monitor → WinCaptureTarget; a session WITHOUT the cursor channel on a flagged target forces composite mode in the IDD-push capturer — GDI poller + blend for the session's life, pinned on (set_cursor_forward cannot clear it: with no client drawing, un-compositing would erase the pointer entirely). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:47:53 +02:00
enricobuehlerandClaude Opus 4.8	89cfef429e	fix(windows/vdisplay): cursor-render state sticky per TARGET across monitor generations ... On-glass: 're-setup on swap-chain assign -> 0x0' fired AFTER 'enable=0 stored' — duplicate/successor monitor entries (re-arrival churn) kept their default-true flag and re-declared the hardware cursor right after the composite flip's re-commit, undoing it. The desired state now lives in a per-target static (CURSOR_FORWARD_DESIRED): every arrival inherits it (no generation can resurrect a declare the session turned off), and the flip stamps EVERY live entry matching the target, declaring against whichever has the live worker. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	b50e4767de	fix(windows/cursor-flip): flag + forced same-mode re-commit — the working un-declare ... The empty-caps un-declare is REJECTED by IddCx (STATUS_INVALID_PARAMETER, on-glass driver 9.9.0722.1407) — there is no un-declare DDI. The composite flip now works with the only lever the OS gives us: every mode COMMIT reverts the path to the software cursor, and the driver skips its per-commit re-declare while cursor_forward_on is off. So: - driver: disable stores the flag only (no DDI call); enable still declares immediately against the live worker's event. - host capturer: after a successful disable flip, force a same-mode re-commit (win_display::force_mode_reenumeration) — DWM composites the pointer from the very next commit; the swap-chain flap is the class the driver's preserved-publisher machinery already rides out. - state now survives re-arrivals end-to-end: the capturer caches the APPLIED state (cleared on every channel (re)delivery, which re-created driver entries need — their flag defaults to declared), and the stream loop re-applies every tick instead of edge-gating (steady-state cost: one Option compare). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	6a8df2ba97	fix(windows/cursor-flip): survive driver-side monitor re-arrival — flag-based flip + channel re-delivery ... On-glass (.173, match-window session): every window-size convergence re-creates the driver-side monitor (re-arrival resize / sibling-session slot churn), destroying the cursor worker the channel was delivered to — the flip then died NOT_FOUND (no entry with target_id ∧ worker) and the declared state was lost entirely. Driver: set_cursor_forward becomes STATE, not an edge on one monitor generation — find by target_id ∧ hw_cursor, store cursor_forward_on even without a live worker (it steers the next delivery/re-setup); declare/un-declare only when a worker exists. Channel delivery honors the flag: setup_and_spawn(declare=false) adopts + spawns WITHOUT declaring (composite mode), so a later enable-flip declares against the worker's event. Host: retain the SET_CURSOR_CHANNEL sender; extract deliver_cursor_channel and RE-deliver the surviving section on every ring recreate and — with one retry — when a flip IOCTL fails (the re-arrived entry gets a fresh worker, declared per its flag). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	030a779391	feat(windows/vdisplay): the driver leg of the mid-stream cursor-render flip ... Belongs to 493f4fae (which shipped only the crates/ side — this packaging/ half was left unstaged, so the deployed driver silently lacked the IOCTL and every flip died NOT_FOUND at dispatch): IOCTL_SET_CURSOR_FORWARD dispatch + monitor::set_cursor_forward (cursor_forward_on flag, resetup gate) + cursor_worker:: unsetup_hardware_cursor (empty-caps un-declare experiment). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	9162e7b451	fix(windows/vdisplay): drop now-unused INFINITE import (poll-loop wait) ... Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Opus 4.8	d2cc770938	fix(windows/vdisplay): QueryHardwareCursor3 + per-mode-commit cursor re-setup — M2c findings ... Durable results of the M2c on-glass bring-up (.173, 2026-07-22): - The base IddCxMonitorQueryHardwareCursor DDI slot is stubbed to STATUS_NOT_SUPPORTED on WDK 26100 — add the ...QueryHardwareCursor3 wrapper (wdk-iddcx) and drain it instead; v3 X/Y are only meaningful when PositionValid, so a position-invalid tick keeps the prior position. - Hardware-cursor setup is per-mode-commit: the OS silently reverts to a software cursor on every mode commit, so re-issue the setup on each swap-chain assignment (monitor::resetup_cursor, called from assign_swap_chain) or the query fails NOT_SUPPORTED forever. - One caps definition for initial setup and re-setup, resting at XOR FULL: the query delivers ONLY alpha shapes in every configuration (all three ColorXorCursorSupport levels, event-driven and 30 Hz polled) — masked/monochrome cursors never arrive. FULL keeps the frame cursor-free for ALL cursor types; the full-fidelity shape comes from the session-side cursor source in the host (design/remote-desktop-sweep.md §8). - Poll the query at ~30 Hz instead of pure event-wait: masked cursors never fire the data event, and the seqlock's position/visibility should stay fresh regardless. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	3a34440a6b	feat(windows): IddCx hardware-cursor channel — remote-desktop sweep M2c ... Brings the cursor channel to Windows hosts. The pf-vdisplay driver declares an IddCx hardware cursor for sessions that negotiated cursor-forward — DWM then EXCLUDES the pointer from the IDD frame and delivers shape/position out-of-band, into the same CursorOverlay → forwarder → wire → client pipeline the Linux portal path uses. - pf-driver-proto v5 (additive, host floor stays 3): AddRequest's spare tail becomes hw_cursor (same size/offsets); IOCTL_SET_CURSOR_CHANNEL delivers a host-created CursorShm section (64-byte seqlock header + 256² shape buffer, layout pinned + tested). No event crosses the boundary — the host polls at encode-tick pace. - driver: wdk-iddcx grows the two cursor DDI wrappers; a per-monitor cursor worker (event wait → QueryHardwareCursor → seqlock publish) starts only when BOTH the ADD asked and the channel arrived, so a failed delivery leaves DWM compositing as today. Shape bytes ship raw (BGRA/masked + pitch); the host converts. - host: the section rides the existing sealed-channel broker (least- privilege dup, remote reap on failure); IddPushCapturer::cursor() seqlock-reads → CursorOverlay (BGRA→RGBA, masked-color approximation, desktop→frame origin shift, per-shape conversion cache). New Capturer::cursor() trait hook — the encode loop prefers it over the frame-attached overlay because hardware-cursor moves produce NO new frame on a static desktop. hw_cursor survives the re-arrival resize (carried on the manager's Monitor). - negotiation: cursor_forward grows the Windows arm (client cap ∧ driver proto ≥ 5, probed once via the control device); SessionPlan carries cursor_forward → OutputFormat.hw_cursor. - drive-by: wdk-probe's two pre-existing same-type casts (clippy) and pf-vdisplay's stale spike-test refs (crate::win_display moved to pf-win-display; tracing-subscriber was never a dep) repaired. Verified: proto tests on Mac AND MSVC (15/15 incl. the CursorShm layout pin); clippy -D warnings for proto/frame/capture/vdisplay/host on Linux (.21) and native Windows (.173); the DRIVER workspace clippy -D warnings green against the real WDK 10.0.26100 bindgen (DDI names, enum variants and IDARG layouts all bind). On-box driver deploy + on-glass validation follow. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-22 23:43:23 +02:00
enricobuehlerandClaude Fable 5	600693914f	fix(security): land the 2026-07 audit fixes — SSRF guards, roster lane, SYSTEM path hygiene ... The low/medium findings from the July host+Windows security review, as implemented in the audit session's working tree: - Webhooks and library-art fetches refuse loopback/link-local/metadata targets and no longer follow redirects (SSRF pivots from the privileged host process). - The paired-client rosters (/clients, /native/clients) move off the streaming-client auth lane — one paired device could enumerate every other device's name + fingerprint; only the bearer/loopback console keeps them. - Device-name sanitizing extends to bidi/format control characters (spoofable rendering) via the shared native_pairing::is_spoofy_char; stream-marker quoting uses the same set. - The SYSTEM service resolves powershell by its full System32 path — CreateProcess checks the launching EXE's own directory first, so a planted powershell.exe beside the host binary would have run as SYSTEM. - The pf-vdisplay driver's opt-in file log moves from world-writable C:\Users\Public to WUDFHost's own temp dir. - GameStream pairing sessions are single-use (removed whatever the outcome). - Uninstall also removes the pf_mouse driver-store entry (rider from the virtual-HID-mouse work). - openapi.json regenerated (hardened-config-dir doc wording). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 17:20:15 +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	9e6fc6e071	fix(host/inject,drivers): rumble root fixes A-C — lossless report ring + rumble-keyed idle watchdogs ... B: PadFeedback.game_drove -> rumble_drove, keyed on vibration-asserting reports — an LED/adaptive-trigger stream can no longer feed the abandoned-rumble force-off while a coalesced stop never re-asserts (the confirmed unbounded stuck-ON path). C: Linux parity — every UHID backend now arms the shared watchdog (Steam Input drives these pads over hidraw with Windows abandonment semantics) and the uinput mixer force-stops abandoned infinite-replay FF effects (FfState, unit-tested). Shared PUNKTFUNK_RUMBLE_IDLE_MS hatch (0 = off; non-zero floored above SDL's ~2 s rumble resend). A: PadShm v2.1 — a 1024 B tail extension carrying an 8-slot lossless output-report ring, feature-negotiated via zeroed reserved fields (out_ring_ver; deliberately NO GAMEPAD_PROTO_VERSION bump — mixed generations degrade to the legacy latest-report slot instead of failing closed). The pf-dualsense driver dual-writes both planes (publish_output); the host's shared OutputDrain drains oldest->newest with a torn-read recheck and an overflow->resync path (PadFeedback.resync force-stops + re-arms dedups). pf-umdf-util grows a min_data_size map fallback. Ds*Feedback.fresh removed (dead). design/rumble-root-fix.md par. A-C. Verified: pf-inject tests+clippy Linux+Windows (53/53 on winbox incl. the stop-coalesce repro); drivers ws check+clippy on the CI runner. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 14:07:32 +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 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 Fable 5	45c29a99d5	perf(host+driver): in-place resize = advertised-mode fast path + mode-history union ... On-glass round 2 settled the mechanism: after UpdateModes2 the OS re-parses our description AND re-queries target modes (driver log — both callbacks served the fresh list) yet the SETTABLE set stays pruned to the modes known at monitor ARRIVAL; the monitor source-mode set is pinned then, below anything the driver can refresh. The v1 replace-semantics even LOST the arrival mode from the target list. Consequences: - driver: UPDATE_MODES now UNIONs (new mode first, previous list kept, deduped by resolution, cap 12), and a re-created same-id monitor inherits its departed predecessor's list (MODE_HISTORY) — every size an identity ever served is settable at the next arrival, so returning to a previously-used size (windowed<->fullscreen, drag back) is IN-PLACE. - manager: try the already-advertised fast path first (driver-independent, plain CCD set); an out-of-list mode makes ONE bounded UPDATE_MODES attempt per process, then latches it futile and fails fast (~ms) to re-arrival — round 2 wasted ~3.1 s per arbitrary resize on the doomed wait. Fallback log demoted warn->info (expected-normal for first-seen sizes). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 18:01:36 +02:00
enricobuehlerandClaude Fable 5	a738de6cd8	fix(host): force a CCD mode re-enumeration after UPDATE_MODES (in-place resize) ... First on-glass run: the driver accepted every UpdateModes2 (0x0 in the driver log) but the OS never re-enumerated the target's settable modes on its own — 'OS did not advertise 800x1050 within 2s' → re-arrival fallback every time. Re-commit the current config with SDC_FORCE_MODE_ENUMERATION (the same nudge the isolate/layout paths already rely on) before the advertised-wait, re-kick up to 3x, and log the actually-offered resolutions when it still misses. Driver: dbglog the *2 mode-query/parse callbacks so the re-enumeration story is visible in pfvd-driver.log. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 17:48:44 +02:00
enricobuehlerandClaude Fable 5	0899e53903	feat(driver): pf-vdisplay IOCTL_UPDATE_MODES — live monitor mode-list refresh (proto v4) ... Latency plan P2.1 (design/first-frame-and-resize-latency.md): a new additive control-plane op lets the host refresh a LIVE monitor's advertised target-mode list to lead with an arbitrary new mode (IddCxMonitorUpdateModes2 — the same IddCx 1.10 *2 family this driver already requires, so no new OS floor). This removes the 'mode list frozen at ADD' constraint that forced the mid-stream resize through a REMOVE->ADD monitor hotplug: the monitor's OS identity, its swap-chain worker and the retained FrameStash all survive an in-place mode set. Protocol v4 is ADDITIVE over v3: the host's handshake floor stays at v3 (MIN_DRIVER_PROTOCOL_VERSION) and gates the in-place path on the reported version, keeping re-arrival as the permanent fallback. The driver's stored mode list is swapped before the DDI and reverted if it fails, so the OS and the mode-DDI callbacks always agree. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 17:12:13 +02:00
enricobuehlerandClaude Fable 5	ce085b8e3b	style(vdisplay): dedupe the attach-block comment (first-frame stash follow-up) ... Comment-only: the lazy-attach comment carried the delivery-consumption sentence twice after the stash rework. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 15:24:36 +02:00
enricobuehlerandClaude Fable 5	89a08f83af	fix(vdisplay): first-frame guarantee — republish a retained frame at ring attach ... DWM composes a display only when something dirties it, so a session opened onto an idle desktop never produced a first frame: the host's synthetic-input "compose kick" (cursor wiggle / sibling-display jump) was the only source, and it is inherently unreliable — blocked on the secure desktop, defeated by a fullscreen game's ClipCursor, user-visible, and dead in service contexts. The field symptom: connect → black stream until something repaints the desktop. Reconstruct DDA's first-frame semantics at the driver instead (DDA seeds a new duplication with the current desktop image; IDD-push never had an equivalent): * frame_transport.rs: new FrameStash — the retained last composed frame, a driver-private copy-only texture. publish() now reports Published / DescMismatch / Dropped, and harvest_into() pulls the last-published ring slot into the stash (keyed-mutex guarded, freshness-checked) before a superseded publisher is dropped — between sessions the driver keeps writing the host-side-dead old ring, so that slot IS the current desktop image. * swap_chain_processor.rs: the worker stashes every frame the ring can NOT take (unattached, or descriptor-mismatched during a mode/HDR-flip race), harvests before a supersede, and REPUBLISHES the stash into every freshly attached ring — the host sees a normal seq=1 publish milliseconds after channel delivery, no compose needed. Zero steady-state cost: matched publishes touch only the ring. The frame-channel stash is now polled every iteration (attach latency = first-frame latency; it was 1-in-30). * monitor.rs: preserved_stash (LUID-tagged) so the retained frame survives swap-chain unassign→reassign flaps, alongside the preserved publisher. * host idd_push.rs: kick_dwm_compose demoted to documented last-resort fallback for pre-stash drivers; a debug log now fires when a kick actually runs so field logs show whether the stash path is working. No proto change: the republish is an ordinary publish, so old host + new driver and new host + old driver both keep working (the latter via the kick). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-16 15:16:36 +02:00
enricobuehlerandClaude Fable 5	32e5594a9a	fix(drivers): per-pad MAC + USB serial in pf-dualsense — SDL/Steam dedup by serial ... Windows counterpart of 5c7e0afa's Linux per-pad pairing MAC: every virtual DualSense / Edge / DualShock 4 presented ONE hardcoded serial, so SDL/Steam (which dedup controllers by serial) could merge a second pad into the first. * GET_FEATURE pairing replies (DS/Edge 0x09, DS4 0x12) now carry the pad index the host stamps into the sealed section in the MAC's low octet. * GET_STRING serial strings (HidD_GetSerialNumberString — what SDL actually reads on Windows) get the same per-pad low octet, agreeing with the feature MAC. The Edge's 0x09 reply moves onto its serial-string base (0x75 = DS base + 1), fixing the pre-existing feature-vs-string mismatch. * The Deck identity already did this per-pad; its two inline index reads now share the new `pad_index()` helper. Pad 0 keeps today's serial values for DS / DS4 / Deck (no identity churn for existing single-pad setups). Verified on the windows-amd64 runner: cargo build + clippy -D warnings (pf-umdf-util / pf-xusb / pf-dualsense) + fmt clean on the pinned 1.96.0. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 23:31:40 +02:00
enricobuehlerandClaude Fable 5	f3b6ccaa7f	fix(gamepad/windows): Steam-accepted Deck unit serial un-mangles the controller name ... Steam validates the Deck unit serial's format before accepting it. Our "PFDK..." serial was REJECTED ("Invalid or missing unit serial number"), so Steam substituted a hash identity and mangled the displayed name to "Steam Deck Controllerggg" on every host tested. An 'F'-leading serial passes, so switch to "FVPF..." — keeps the PunktFunk marker one slot in, still distinct from a real Deck's "FVZZ..." for the Linux self-detection in physical_steam_controller_present(). The name now shows a clean "Steam Deck Controller" with a serial-derived handle (verified on .173). Also fix the UMDF driver's 0xAE GET_STRING_ATTRIBUTE handler to echo the requested attribute id faithfully instead of collapsing board-serial (0x00) requests to unit-serial (0x01). Steam still logs a benign "Deck Controller PCB Serial# invalid" for the board serial — it validates that against a Valve-internal format for ANY value, including an empty one (verified) — but that line does not mangle the name, change the handle, or block promotion. Applied to both transports: host inject/proto/steam_proto.rs::deck_serial (Linux gadget/usbip) and the pf-dualsense UMDF driver (Windows), which mirror each other's serial format. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 16:31:07 +02:00
enricobuehlerandClaude Fable 5	d8e8529cd7	feat(gamepad): Windows Steam Deck backend — Steam-Input-promoted UMDF virtual Deck ... The N4 GO verdict, productized. GamepadPref::SteamDeck on a Windows host now builds a real virtual Deck instead of folding to DualSense: games get native Deck glyphs + both trackpads + gyro + all four back grips through Steam Input's own remapping. - steam_deck_windows.rs: DeckWinPad/DeckWinProto/SteamDeckWindowsManager over the sealed shm channel, sharing the whole Linux Deck codec (steam_proto now compiles on Windows too — it was already pure). The SwDevice identity carries usb_mi: Some(2): the &MI_02 hardware-id token hidclass mirrors into the HID child and Steam parses as the wired controller interface — the promotion gate. - Driver: DEVTYPE_STEAMDECK (3) graduates from the spike — SET_FEATURE 0xEB rumble / 0x8F haptic pulses are republished to the host through the output slot (report-id-0 prefixed, so parse_steam_output sees the Linux wire shape), and the 0xAE/GET_STRING serial + 0x83 unit id are per-pad (read from the section's pad_index; PFDK<unit-id> matches steam_proto::deck_serial). - Router: SteamDeck arms in the Windows Pads paths; pick_gamepad flips SteamDeck-if-windows -> SteamDeck (the DualSense fold retires); dualsense-windows-test grows --deck. ON-GLASS VALIDATED on .173 (rebuilt signed driver 9.9.0714.12xx installed, Steam live): the manager-created pad (index 1) enumerates with per-pad serial PFDK50460001, Steam logs Interface: 2 -> '!! Steam controller device opened' -> 'Steam Controller reserving XInput slot 0' -> PollState 2 (actively polling our cycling input frames) -> mapping activated; clean teardown on exit. Rumble round-trip through a real game remains an on-glass debt (nothing sent 0xEB during the idle hold). Known gap vs Linux: no physical-Steam-controller conflict degrade on Windows yet (degrade_steam_on_conflict is Linux-only — /sys scan); a Windows equivalent needs SetupDi enumeration and is deferred. Verified: .21 clippy -D warnings + 304/0 tests + fmt --all; .133 clippy -D warnings + the WDK driver-workspace check. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 12:36:26 +02:00
enricobuehlerandClaude Fable 5	69f30f30b6	style(pf-dualsense): rustfmt the N4-spike additions (CI fmt gate) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:55:47 +02:00
enricobuehlerandClaude Fable 5	8d8168b0e0	feat(gamepad): N4 spike kit — software-devnode Steam Deck probe for Windows ... The gamepad-new-types §6 go/no-go rig, ready to run the moment .173 is back (the box is currently down, so the observation itself is still owed): does Steam Input on Windows promote a software-devnode HID Deck (28DE:1205), or does it need a real USB bus identity (the documented GameInput instance-path gap — the Linux 'Interface: -1' lesson)? - Driver: scratch device_type=3 serves the Deck identity — the captured 38-byte controller-interface descriptor, 28DE:1205 attributes, Valve strings, the Deck neutral frame, and the Steam 0x83/0xAE feature contract (SET_FEATURE latches the command, GET_FEATURE answers it — attribute blob + unit serial mirroring steam_proto::feature_reply). Never stamped by a session. INF gains pf_steamdeck. - Host: deck_spike_hold() + the `deck-windows-spike` subcommand — stamps devtype 3, spawns the devnode under VID_28DE&PID_1205, streams the neutral frame, prints what to observe (Steam logs/controller.txt, controller settings) and logs any output reports Steam writes. Run recipe (on .173, once the updated signed driver is staged): install driver, start Steam, `punktfunk-host.exe deck-windows-spike`, watch controller.txt. GO -> plan a proper N4 phase (the Deck codec is already shared); NO-GO -> document next to the Linux Interface:-1 note and keep the SteamDeck->DualSense Windows fold. Verified: .133 clippy -D warnings + the driver workspace cargo check (WDK) both green; .21 clippy + 304/0 tests unaffected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-14 11:44:59 +02:00