23 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	2b1843ed1c	fix(drivers/pf-gamepad): the right stick is Z/Rz — as declared, it was dead ... Found on glass, first real streaming session: everything worked except the right stick, and Steam correctly showed "Xbox One S Controller". `XBOX_RDESC` declared the right stick as `Rx`/`Ry`. `xinputhid`, which translates our HID collection into XUSB, maps `Z`/`Rz` to the right stick and does not treat `Rx`/`Ry` as one, so those two axes reached nothing. Two usage bytes. Left and right were declared identically here — same collection, same globals, same size and count — so the usages were the entire difference, which is what makes the diagnosis airtight rather than plausible. Note `DUALSENSE_RDESC`, a real capture, also uses `Z`/`Rz` for its right stick and puts the TRIGGERS on `Rx`/`Ry`; that is most likely where the original mistake came from. ⚠️ Byte offsets are unchanged — still 16×2 at bit 5.0 — so `xbox_proto`'s layout tests and the host-side packing are untouched. This is a pure relabelling. 🛑 THE REAL LESSON IS THE HARNESS, AND IT IS FIXED HERE TOO. This survived every bench measurement because `dualsense-windows-test` drove LS-X and the A button and left the other five analogue axes at zero. `XInputGetState` read `RX [0..0]`, which I read as "the devtest doesn't move it" — true, and useless: a harness that exercises one axis cannot tell "this axis is not mapped" from "nothing is driving it", and the two are indistinguishable in every consumer. The devtest now sweeps all six axes on distinct phases and ramps both triggers, so one run shows which axes arrive AND that they are not crosstalking onto each other's bytes. MEASURED ON .173, same run shape before and after, devtest sweeping all six axes: before: LX [-11264..24576] LY [-32768..31744] RX [0..0] RY [-1..-1] LT [0..248] RT [7..255] after: LX [-8192..26624] LY [-32768..31744] RX [-32768..31744] RY [-24576..10240] LT [0..248] RT [7..255] VERIFIED * `cargo test -p pf-inject --lib` 104/104 on Windows; `xbox` subset 11/11 on macOS — the layout tests still pass because nothing moved. * Driver rebuilds and signs; the descriptor is still 223 bytes so the `wReportLength` const assert is undisturbed. * `cargo fmt --all --check` clean. NOT VERIFIED * Not yet re-tested in a real streaming session — that is the next on-glass run. * ⚠️ A leftover finding from the same session, unrelated to this fix and NOT investigated: the session's pad devnode SURVIVES client disconnect and keeps the `Global\pfds-boot-0` bootstrap mailbox, so a devtest run afterwards fails with `Zugriff verweigert (0x80070005)` and silently measures the stale pad instead. Restarting the service releases it. Worth its own look.	2026-08-09 22:19:25 +02:00
enricobuehler	4f9071b980	feat(pads/windows): three Xbox identities — Wireless, One S and Elite Series 2 ... Until now there was one Xbox identity, `device_type = 4` / `045E:0B13`, and Windows folded a client's `XboxOne` request onto it because the only Windows Xbox backend was the XUSB companion, which presents one fixed 360 identity and cannot vary it. The HID backend can, so the fold goes and two identities join it: devtype 4 045E:0B13 pf_xboxwireless Xbox Wireless Controller devtype 5 045E:02FD pf_xboxones Xbox Wireless Controller (One S) devtype 6 045E:0B22 pf_xboxelite Xbox Elite Wireless Controller Series 2 `GamepadPref::XboxElite` takes wire byte 11 — the first unassigned one, and the round-trip test previously asserted `from_u8(11) == Auto` with a comment saying assigning it must update that; the sentinel moved to 12. The C ABI mirror and the generated header moved with it. ⭐ ALL THREE SHARE ONE REPORT DESCRIPTOR, deliberately. In HID terms they are the same pad; the descriptor is the report shape, not the identity. §3 of the handoff records that our single hand-written descriptor already cost three separate bugs, and inventing two more would multiply that debt for no measured gain. They differ in VID/PID, product string, hardware id and Device Manager description only. ⚠️ All three install `pfGamepadXbox`, the section that attaches the `xinputhid` bus filter. That was the open risk: Microsoft's `xinputhid.inf` promotes by an explicit hardware-id allow-list containing `02D1, 02DD, 02E3, 02EA, 0B00, 0B0A, 0B13, 02FF` — and NEITHER `02FD` NOR `0B22` is on it. Measured on .173: promotion does not care, because it comes from our own AddReg rather than from matching Microsoft's ids. All three gain `IG_00`, register an XUSB interface, and are read live by classic XInput. Had this gone the other way the two new identities would have been strictly worse than the one they joined. The XUSB escape hatch needed a runtime degrade to stay honest. `pick_gamepad` is compile-time only, so with `PUNKTFUNK_XBOX_BACKEND=xusb` the host would have resolved and echoed `xboxelite` in its `Welcome` while actually building a 360 pad. `degrade_xbox_identity` folds the identity back at runtime, mirroring `degrade_if_no_uhid`. VERIFIED ON WINDOWS (.173 — none of this compiles on macOS; the driver needs the WDK and the rest is `cfg(windows)`): * `cargo test -p pf-inject --lib` 104/104 — including `hwid_matches_inf`, `hwid_devtype_table_matches_the_driver` and `only_the_xbox_identity_installs_the_xinputhid_section`, all now sweeping the whole identity set and asserting the section split in both directions. * `cargo test -p punktfunk-core --lib gamepad` 7/7; `cargo check -p punktfunk-host` clean. * Driver builds and signs; the descriptor/`wReportLength` const asserts still hold with the descriptor shared three ways. * ON GLASS, per identity, via the new `--xboxones` / `--xboxelite` devtest legs: each gets its own devnode (`PF_XBOX_0` / `PF_XBOX_ONES_0` / `PF_XBOX_ELITE_0`), each HID child gains `IG_00`, each registers an XUSB interface, and XInput reads each live (packets advancing, `buttons=0x1000`). * macOS: `cargo fmt --all --check` clean in both workspaces. NOT VERIFIED / NOT DONE * **Elite paddles are NOT implemented.** `BTN_PADDLE1..4` would need descriptor buttons, and once `xinputhid` promotes the pad it claims the HID collection exclusively — XInput has no paddle fields and the HID consumers that do may be locked out, so the buttons would likely reach nobody. The decisive measurement is cheap and named in the code: hold a paddle bit set and see whether a user-mode HID reader still gets reports. Until then the Edge remains the only virtual pad with native back-button slots and nothing should be advertised otherwise. * **No client picker offers the Elite**, and none can auto-detect it — SDL3's `GamepadType` has no Elite variant. It is reachable today only via `PUNKTFUNK_GAMEPAD=xboxelite` or a hand-edited client setting. All five clients ship the same curated six options by deliberate parity, so adding one is a cross-client UX change, not part of this. * Nothing here has run in a real streaming session; every measurement came from the devtest.	2026-08-09 21:41:53 +02:00
enricobuehler	bd5735b803	feat(pads/windows): make the HID Xbox pad the default, and carry the trigger motors on the wire ... Three changes that only make sense together: the HID backend becomes the default now that it is a superset of the XUSB one, the rumble datagram grows the two Xbox impulse-trigger motors, and the INF-shape tests learn about the Xbox identity's own install section. WP-E — `PUNKTFUNK_XBOX_BACKEND` now defaults to `hid`; `=xusb` is the escape hatch. The knob existed for exactly one reason, recorded in its own doc comment: the HID pad could not reach classic XInput, so defaulting to it would trade a known-working path for an unproven one. That objection is gone — with the `xinputhid` bus filter the INF now attaches, the HID pad is promoted like real hardware and keeps classic XInput while gaining everything XUSB never had (Steam, SDL, RawInput, DirectInput, joy.cpl, WGI) plus rumble, which XUSB could not source at all. The escape hatch stays because promotion leans on Microsoft's inbox `xinputhid.inf`; if a servicing update changes it, one env var restores the old behaviour with no reinstall. An unrecognised value takes the DEFAULT rather than the opt-out, so a typo cannot silently drop a user onto the path with no HID collection. WP-D — the `0xCA` rumble datagram gains a v3 form: v1 7 B: [0xCA][u16 pad][u16 low][u16 high] v2 10 B: … [u8 seq][u16 ttl_ms] v3 14 B: … [u16 lt][u16 rt] v3 is built FROM v2's bytes rather than restating the layout, so the prefix relationship is structural instead of a convention two encoders have to keep agreeing on, and every reader gates with `>=`. The four levels share one seq and one ttl on purpose: they are one statement of the pad's feedback at one instant, and sharing means the whole v2 apparatus — renewal cadence, stop burst, the client's seq gate, the lease clamp — governs the triggers with no new code. The new `RumbleUpdate` fields are plain `u16`, not `Option`: on a level-triggered plane "absent" must mean zero, because "absent → keep the previous value" is the stuck-rumble bug in a new costume. Only one backend can ever source them — the Windows HID Xbox pad, whose output report 0x03 carries them. `XINPUT_VIBRATION` and evdev `FF_RUMBLE` have two members and no third, so every other producer sends `lt = rt = 0`. ⚠️ The two TRIGGER `enable`-mask bits remain CONJECTURE. Bits 2/3 = left/right handle are measured; bit 0/1 = the triggers are inferred from field order and nothing else. `parse_xbox_output` says so inline, and no test asserts them — every test vector uses masks (0xFF, 0x00, 0x0C, 0xF3) whose expectations hold whichever bits turn out to be right. XInput cannot settle this: it has two motors. The INF tests — `hwid_matches_inf` matched the install section by the exact string `=pfGamepad,` and so stopped seeing the Xbox hardware ids the moment that identity moved to its own `pfGamepadXbox` section. It failed loudly, which is the good outcome; it is now prefix-matched and tolerant of further per-identity sections. Added `only_the_xbox_identity_installs_the_xinputhid_section`, which asserts the split in BOTH directions: the Xbox line must not install the shared section, and no other line may install the Xbox one. Merging them back is a one-line edit that looks like tidying and would hand a DualSense to Microsoft's Xbox translator. VERIFIED * ON WINDOWS (.173, the only place this code compiles): `cargo test -p pf-inject --lib` 104/104, including the new trigger tests and both INF tests; `cargo check -p punktfunk-host` clean. * macOS: `cargo fmt --all --check` clean; `cargo test -p punktfunk-core --features quic` rumble suite 22/22, including v3 round-trip and v3<->v2 cross-version parsing. * The pre-existing `c_abi_harness_round_trips` failure on macOS is `ld: library 'opus' not found` and reproduces with these changes stashed. NOT VERIFIED * No trigger rumble has ever been observed end to end — nothing can drive it yet (see the conjecture note above), and no client renders it. * The default flip has NOT been exercised in a real streaming session; every measurement so far came from the devtest harness. That is the on-glass run. * Non-Rust clients do not decode v3. They are blocked on a C ABI entry point first (`punktfunk_connection_next_rumble_cmd` has fixed out-params, ABI_VERSION 17); Apple could render it via GCHapticsLocality.leftTrigger/.rightTrigger, Android structurally cannot (its packed jlong is full) and has no trigger actuators anyway.	2026-08-09 21:10:08 +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	0b160a4e22	feat(host/audio): minted Punktfunk endpoints become the wiring plan's tier-0 ... The audio-substrate program's Phase 2 (spikes S2+S3 measured green on the target box): the host mints its OWN instances of Valve's streaming-audio drivers and wires by IDENTITY instead of borrowing Steam's primaries — minted.rs the provider: one devnode per role ('Punktfunk Speakers' from SteamStreamingSpeakers.inf, 'Punktfunk Microphone' from SteamStreamingMicrophone.inf), marker-matched across restarts (PunktfunkAudioRole in Device Parameters — names are NOT identity, a minted instance is name-identical to the primaries), provisioned on a startup worker like pad audio, retried with a 60 s cool-down from wiring passes, defaults restored when a fresh endpoint grabs them. wiring_plan MintedIds tier-0: the mic takes its minted device outright (capture side paired by the provider's id — a name search cannot tell it from the primary), the loopback prefers the minted sink at the head of the silent tier, an operator override still beats everything, a narrowing minted sink demotes below real hardware, and stale ids fall back to the ladder unchanged. Plus AudioReadiness — the full/audio-only/mic-only/nothing classification, logged with every plan change (§C4's seed). audio-probe 'mint' runs the provider synchronously; 'plan' prints one real wiring pass + readiness — the field-triage command. Without Steam's drivers nothing changes: provisioning degrades to absent ids and the plan keeps the name-based ladder (primaries → cable → real hardware) exactly as before.	2026-08-07 11:22:06 +02:00
enricobuehler	03ee3e55d7	feat(host/devtest): audio-probe — the audio-substrate spike measurements ... The S1-S3 spikes from windows-audio-endpoints-and-vbcable.md as one runnable devtest (no game, no client, ssh-drivable): audio-probe ssm S3, the decision gate: mint a SECOND devnode of Valve's Steam Streaming Microphone driver and prove the pair end to end (tone into its render endpoint must come back out of its capture endpoint). Pass = a punktfunk-owned virtual mic needs no VB-Cable wherever Steam is installed. audio-probe sink S2: mint a Speakers instance, park the DEFAULT playback on it, tone through the default device, WASAPI-loopback the instance - the desktop-audio capture path minus the game. audio-probe sss-primary S1: the primary Speakers' known-silent loopback, re-measured, with mix format + steam.exe state. audio-probe cleanup remove every probe-minted devnode (marker value in Device Parameters, never name-guessing). pad_endpoint grows the first slice of the design's §C1 shared minting surface: create_media_devnode(desc, hwid, mark), bind_driver(hwid, inf), find_capture_endpoint_for_devnode — the pad provisioner now calls the same functions. The probe restores whatever default devices the minting disturbed before it exits.	2026-08-07 10:47:00 +02:00
enricobuehler	5be494f490	merge: bring main into the pad-audio branch ... Main had moved 34 commits past the merge-base and 13 files had diverged. Resolving now rather than later, since the force-feedback sweep work is landing in the same files. Five conflicts needed hand resolution. Four were "each side added something different" and keep both: the Forwarding and PadAudioPrefs control variants with their handlers and setters (pf-client-core/gamepad.rs), both of the session's pre-attach declarations (forwarding first, so slots still declare their pad-audio caps at open time), main's WiredPlan/fingerprint alongside the branch's pad_render_ids (audio_control.rs), and main's judge_default signature (wasapi_cap.rs). wiring_plan.rs was not mechanical. Main's 652abeb3 added a flagged last-resort loopback tier; the branch had added a fifth `plan` parameter excluding pad endpoints from every role. Taking either side alone loses the other, and combining them carelessly is worse than both: the new last-resort tier would happily select the pad's own speaker endpoint, which is stamped "DualSense Wireless Controller" with no virtual marker precisely so games read it as the pad's speaker — routing the entire desktop mix into the controller's voice coils. The branch's exclusion shadows `renders` before any tier runs, so the last resort inherits it; `a_pad_is_never_the_last_resort` pins that, including that a pad-only candidate set stays honestly unsatisfiable rather than falling back onto the coils. Verified: clippy -p punktfunk-host -p pf-client-core --all-targets --locked -D warnings = 0; pf-client-core 93/93; punktfunk-host 387 passed with only the known-environmental gamestream sender_delivers_batches UDP-loopback flake; wiring_plan 21/21; fmt clean. NOT verified: audio_control.rs and wasapi_cap.rs are cfg(windows), so neither the Linux container nor xcheck.sh compiles them. Those two resolutions have had review only and need the Windows runner before this merges.	2026-08-03 19:11:26 +02:00
enricobuehlerandClaude Opus 5	3a48cc2470	test(host/pad-audio): drive either channel pair, so the speaker leg can be proven too ... `pad-endpoint tone` only ever drove the BACK pair, which meant the pad's speaker — the FRONT pair, the other half of the 4-channel split — had never carried a signal end to end. The capture probe's verdict was shaped the same way, and called a perfectly good front-pair run "silent". `--pair front|back|both` picks the pair, and the verdict now reports which pair it SAW rather than judging against an assumed one. Measured on .173, an exact mirror in both directions and no crosstalk either way: --pair back peak_front=0.0000 peak_back=0.5000 back only, channel-exact --pair front peak_front=0.5000 peak_back=0.0000 front only, channel-exact --pair both peak_front=0.5000 peak_back=0.5000 both So the host half of the speaker path is proven to the same standard the haptics path was. What is still unproven is the client rendering the front pair into the pad's own speaker; that needs the phone unlocked, which it no longer is. Host clippy clean; 360 tests pass, the one mgmt display failure reproduces on a clean tree. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 12:38:06 +02:00
enricobuehlerandClaude Opus 5	64a392634e	test(host/pad-audio): prove the endpoint actually carries audio, channel-exact ... `pad-endpoint tone` only ever proved a render client could open the endpoint. Whether anything came back out of the loopback — and in the right channel pair — was still taken on faith, which is exactly the gap that let a stamped-but- unservable endpoint look healthy while a client sat on an empty plane. `pad-endpoint capture [seconds]` opens the real PadLoopbackCapturer and reports frames plus per-pair peaks, so the two halves together exercise render -> engine -> loopback -> pair routing with no game and no client attached. Run against each other on .173: pad-endpoint capture: 157920 frames over 7s, peak_front=0.0000 peak_back=0.5000 VERDICT: PASS - back pair only, front pair silent (channel-exact). 0.5 is the tone's own amplitude and the front pair is dead silent, which is the signal the 0xD1 framer routes to the voice coils. Same figure the program notes recorded on 2026-08-01 and nothing has been able to reproduce since. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 12:09:38 +02:00
enricobuehlerandClaude Opus 5	9409d0a04c	fix(host/pad-audio): provisioning stops corrupting the heap, and the endpoint stops being resolved by a freed string ... Two defects sat between the pad-audio endpoint and any sound. Neither was where the symptom pointed. `windows 0.62` implements `Drop for PROPVARIANT` as `PropVariantClear(self)`. Every variant `set_store_value` builds borrows memory Rust owns — a `Vec<u16>`, a `&GUID`, a `&'static [u8]` — so each stamp handed that pointer to `CoTaskMemFree`. The file said the opposite in a comment, which is why it looked safe. The damage surfaced late: `pad-endpoint ensure` died with STATUS_HEAP_CORRUPTION (0xC0000374) partway through stamping, leaving the endpoint with whatever subset had landed and `needs_aeb_kick` stuck true forever. With the variants held in `ManuallyDrop`, `ensure` exits 0 and all seven stamps read back served for the first time. `wasapi 0.23`'s `DeviceEnumerator::get_device` builds its argument as `PCWSTR::from_raw(HSTRING::from(id).as_ptr())`; the `HSTRING` is a temporary, so `GetDevice` reads freed memory. That is where the `IAudioClient: 0x80070002` came from — not from the endpoint, which activates fine. Resolving through `open_mmdevice`, which keeps its buffer alive, retires the error in both the tone devtest and the loopback capture. Also adds the instrument that separated these: the tone path now reports the raw `IMMDevice::Activate` result alongside the crate's, and `pad-endpoint tone --endpoint <id>` can drive any endpoint, so "this process cannot activate anything" and "this endpoint is broken" stop looking identical. Verified on .173: ensure exit=0, 7/7 stamps served, needs_aeb_kick=false, 0x80070002 gone. Host clippy clean; 360 tests pass (the one mgmt display failure reproduces on a clean tree). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 11:01:22 +02:00
enricobuehler	212bdc3b08	fix(devtest): resolve the pad endpoint by system lookup, not the service's cache	2026-08-03 10:09:49 +02:00
enricobuehler	45cb525035	wip(host): pad-endpoint tone devtest	2026-08-03 10:05:52 +02:00
enricobuehlerandClaude Fable 5	5174a59832	fix(capture/kwin): a hidden cursor leaves the stream — KWin's id-0 meta is the hide ... Since the 0.22.0 cursor work (the seat-pointer park + the metadata composite), a KWin capture-model stream always has a cursor — and it never went away again: not in game, not in Big Picture, not with a controller in hand (field report, 2026-08-01). The host blended the arrow forever because pf-capture deliberately ignores SPA_META_Cursor id 0, and once `visible` latched true nothing on Linux ever cleared it. Two producer contracts meet on id 0, and one flag now carries which one a stream follows. KWin rewrites the cursor meta on EVERY enqueued buffer and writes id 0 whenever Cursor::isOnOutput says the pointer is not in this stream — which covers both a globally hidden cursor and a client null-cursor surface (empty geometry intersects nothing). There id 0 IS the hide, and honoring it is what lets a game hide the pointer mid-stream. Mutter only rewrites a buffer's meta when the cursor changed, so recycled buffers carry stale id-0 regions between damage frames — honoring those flickered the cursor off between hovers (on-glass round 5), and that path keeps its last-known-state behavior. The flag rides from the backend that created the output (correct for registry-pooled reuse too — a kept display only ever matches its own backend) through capture_virtual_output into the parser's CursorState. The portal-monitor path stays on the stale-meta contract: the only thing routed through it today is Mutter's HDR mirror. Verified on .25: pf-capture 45/45, punktfunk-host 369/369, clippy -D warnings clean (pf-capture, punktfunk-host, cursor-probe), fmt clean. On-glass KDE validation still owed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-02 21:54:09 +02:00
enricobuehlerandClaude Fable 5	ed3d236ab8	feat(pad-audio): DualSense audio haptics + speaker, host->client end to end ... The 0xD1 pad-audio plane streams a DualSense's voice-coil haptics (back channel pair, 5 ms Opus frames) and speaker (front pair, 10 ms) per pad from a Windows host to the SDL clients, which render them into a USB DualSense's own 4-channel audio device. Wire (punktfunk-core, ABI v15): PAD_AUDIO_MAGIC 0xD1 [pad][kind][seq][pts] [opus]; CLIENT_CAP_PAD_AUDIO 0x04 / HOST_CAP_PAD_AUDIO 0x20; per-pad render capability rides GamepadArrival flags bits 8/9, sent only toward a host that advertised its cap so old hosts see byte-identical arrivals; silence is a frozen seq (mic-mute discipline), loss is a seq gap concealed via AudioGapTracker. HidOutput::AudioCtl (0xCD kind 0x06) forwards the 0x02 report's audio-control bytes 5..=10 change-only, value-deduped, with a once-per-pad "title asserted haptics-select" diagnosis log. Windows host endpoint provider (audio/windows/pad_endpoint.rs): per-pad render endpoints are additional devnode instances of Valve's Steam Streaming Speakers driver (SetupDiRegisterDeviceInfo, NOT the class installer - it needs an interactive window station), stamped with DualSense identity: desc "Wireless Controller", device name "DualSense Wireless Controller", ContainerId = the virtual pad's PFDS GUID, 4ch/48k format triplet. IPropertyStore route first, ACL-repaired registry fallback (the MMDevices keys deny writes even to SYSTEM; the owner's implicit WRITE_DAC + an ACE for S-1-5-18 resolved by SID is the way in). Provisioned at host startup (PUNKTFUNK_PAD_AUDIO, PUNKTFUNK_PAD_AUDIO_SLOTS, default 1), idempotent via a persisted PunktfunkPadIndex marker; pad endpoints are structurally ineligible for the mic/loopback wiring plan and guarded against default- device theft; capture is WASAPI loopback on the stamped endpoint. Devtest: punktfunk-host pad-endpoint ensure|remove|status. Host service (native/pad_audio.rs): per-(session,pad) thread, loopback 4ch -> pair splitter -> per-kind stereo Opus (48k LowDelay CBR 64k) -> per-kind silence gate (opens at peak>=1e-3, 250 ms hangover, gated = no send + frozen seq) -> datagrams. Spawned from the native input pump when a DualSense/Edge arrival carries audio bits and both caps negotiated; idempotent re-arrivals; reaped on remove and teardown. Client tier A (pf-client-core/pad_audio.rs): settings pad_haptics (default on) and pad_speaker (default "pad"); tier A = wired USB DS5/Edge via SDL connection state with an audio-sibling fallback; correlation maps the SDL HID path to the pad's own render endpoint (Windows: ContainerId match + 4ch gate via registry; Linux: Sony sink signature); renderer decodes both kinds into a quad interleave and plays it on the pad's endpoint (WASAPI autoconvert / PipeWire target.object, 240-2400 frame ring floor, dont-reconnect so an unplug never re-routes haptics to the desktop speakers). SDL's DualSense driver sets "disable audio haptics" whenever it drives rumble emulation, so tier-A pads suppress wire rumble and send one cleared-enable-bits effects packet to keep the actuators live; AudioCtl bytes fold back into the effects packet at report-minus-one offsets. Verification: punktfunk-core 265 tests (macOS) + clippy -D warnings (mac + Linux docker); pf-inject 85 tests (Linux docker); punktfunk-host cargo check + clippy + 19 pad tests + 46 audio-module tests (Windows box); pf-client-core 30 tests + clippy (Linux docker CI image) + cargo check (Windows box); punktfunk-client-session clippy (Linux) + check (Windows); cargo fmt --all --check clean on the final tree. NOT yet verified: any on-glass run (host deploy + real title + physical pad), the stamp-route split at runtime, exclusive-mode Initialize isolation, Linux-host emission (the per-pad PipeWire sink is not in this change - Windows hosts only). Scope excluded deliberately: tier B (Apple CoreHaptics) and tier C (haptics->rumble derivation), pad_speaker="mix", Android leg, settings UI surfaces (keys are serde-defaulted), GameStream-plane arrivals (audio_caps always 0 there). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 12:07:06 +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 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