Files

T

enricobuehler 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

src

feat(gamepad): N4 spike kit — software-devnode Steam Deck probe for Windows

2026-07-14 11:44:59 +02:00

Cargo.toml

refactor: rename pf-vdisplay-proto -> pf-driver-proto (it spans all drivers)

2026-06-26 05:38:21 +00:00

README.md

docs: repo-wide housekeeping — sync README & docs with the code as shipped

2026-07-10 09:13:42 +02:00

README.md

pf-driver-proto

The shared host ↔ driver binary contract for punktfunk's Windows pf-vdisplay virtual display — the control IOCTLs and the IDD-push frame transport, defined exactly once.

It's a path dependency of both the host workspace (crates/punktfunk-host) and the out-of-workspace driver workspace (packaging/windows/drivers/), so it must resolve identically from either build graph. That's why it's deliberately self-contained: no_std (+ alloc), platform-neutral (GUID/LUID are plain integers each side converts to its own OS type), and free of *.workspace = true inheritance.

Defining every wire struct here — with const size/offset asserts and bytemuck round-trips — turns host↔driver ABI drift into a compile error instead of a silent frame or IOCTL corruption.

See the crate root (src/) for the wire types; the Windows virtual-display design is in the internal planning repo (punktfunk-planning: windows-virtual-display-rust-port.md).