# Virtual Steam Deck via USB gadget — true Steam Input recognition **Proven on a real Steam Deck (SteamOS 3.8.11), 2026-06-29.** A `raw_gadget` userspace emulator of a real 3-interface USB Steam Deck (`28DE:1205`) — mouse = interface 0, keyboard = 1, **controller = interface 2** — bound to a `dummy_hcd` loopback UDC, so the host's own Steam sees a genuine interface-2 Deck and **promotes it through Steam Input** (XInput pad emission, glyphs, bindings). ## Why this exists (the interface-2 wall) A virtual Deck created via **UHID** (the `inject/proto/steam_proto.rs` / `steam_controller.rs` path) binds the kernel `hid-steam` driver, but **Steam Input will not manage it**: Steam filters the Deck's controller to USB **interface 2**, and a UHID device has no USB interface number (`Interface: -1` in Steam's `controller.txt`), so Steam enumerates it but never promotes it. A single-interface DualSense is accepted at `-1` (no ambiguity), but the multi-interface Deck specifically needs interface 2. See `design/steam-controller-deck-support.md` §11. A real multi-interface USB device with the controller on interface 2 requires a **USB gadget**. SteamOS ships every piece (`CONFIG_USB_DUMMY_HCD=m`, `CONFIG_USB_RAW_GADGET=m`, `CONFIG_USB_CONFIGFS_F_HID=y`), so this runs on a Deck with no module-building. ## What's here - **`deck_raw_gadget.c`** — the working emulator. Presents the 3-interface Deck with descriptors captured verbatim from a physical Deck (incl. the real 38-byte controller report descriptor), and — crucially — answers **every** control transfer, including the HID feature reports (`f_hid` can't, so it produced a "zombie controller" in Steam). Streams the 64-byte state report on the interface-2 interrupt-IN endpoint. Build static (the Deck has no compiler): ```sh gcc -O2 -static -pthread -o deck_raw_gadget deck_raw_gadget.c ``` Run as root with `dummy_hcd` + `raw_gadget` loaded: `./deck_raw_gadget [seconds]`. - **`configfs_gadget_up.sh` / `_down.sh`** — the simpler **configfs `f_hid`** variant. It proves the structure (interface 2 → `hid-steam` binds → Steam *opens* it + *reserves an XInput slot*) but `f_hid` cannot serve HID feature reports, so Steam can't read controller details and drops it as a zombie. Kept as the minimal reproducer of the interface-2 result. ## Result (raw_gadget, live) ``` hid-steam ... Steam Controller 'PFDECK000' connected input: Steam Deck / Steam Deck Motion Sensors (kernel gamepad + IMU evdevs) controller.txt: Interface: 2 ... device opened for index 14 ... reserving XInput slot 1 input: Microsoft X-Box 360 pad 1 (Steam Input's XInput output — promoted) ``` Stable (1 connect, 0 disconnects), no zombie. The kernel `"Steam Deck"` evdev is then grabbed by Steam Input, which exposes its own X-Box 360 pad — exactly a real Deck's behaviour. ## Key implementation gotchas (all real, all cost time) - `struct usb_endpoint_descriptor` (ch9.h) is **9 bytes** (audio `bRefresh`/`bSynchAddress`); the wire descriptor needs **7** — use a packed 7-byte struct in the config blob or the kernel mis-parses it. - raw_gadget EP0: a **no-data OUT** control (`SET_CONFIGURATION`, `SET_INTERFACE`, `SET_IDLE`, `SET_PROTOCOL`) is completed with a zero-length **`EP0_READ`**, not `EP0_WRITE` (using write → `EBUSY`/`can't set config error -110`). IN controls (`GET_*`) use `EP0_WRITE`. - Don't start the input streamer until after `SET_CONFIGURATION` is fully acked, or its blocking `EP_WRITE` starves the control path. - `dummy_hcd` + `raw_gadget` must both be loaded and `/dev/raw-gadget` present before launch. ## Host backend (shipped, opt-in) The C PoC's transport is ported to a Rust host gamepad backend: `crates/punktfunk-host/src/inject/linux/steam_gadget.rs` (`SteamDeckGadget`), driven by the same `steam_proto` serializer as the UHID `SteamDeckPad`. The Steam-Deck manager (`inject/linux/steam_controller.rs`) now selects per-pad between **UHID** (default, universal) and the **USB gadget** (`PUNKTFUNK_STEAM_GADGET=1`, SteamOS-only — best-effort `modprobe dummy_hcd raw_gadget`, graceful fallback to UHID if `/dev/raw-gadget` is unusable). The Rust transport is **validated on the Deck** (a static musl test binary that `#[path]`-includes the real module): it enumerates the 3-interface Deck, hid-steam binds it + reads our serial + creates the `Steam Deck` + `Motion Sensors` evdevs — identical to the C PoC. A real USB-stack bug it caught: on musl, `ioctl(fd, RUN)` with no third arg passes a garbage `value`, and raw_gadget's `RUN`/`CONFIGURE`/ `EP0_STALL` reject a non-zero `value` with `EINVAL` — so the no-arg ioctls must pass an explicit `0`. ## Feature contract (hardened — churn fixed) Steam's `GetControllerInfo` reads HID **feature reports**; serving the real ones is what stops Steam re-probing (which was destroying + recreating the gamepad evdev — the "churn"). The contract was captured from a physical Deck (`get_deck_attrs.c`, hidraw `HIDIOCGFEATURE`; usbmon truncates to 32B): - **`0x83` GET_ATTRIBUTES_VALUES** — `[83, 2d, 9× (attr-id, u32-LE)]`: product id `0x1205`, a unit serial (`0x0a`/`0x04` — we stamp a per-instance value so a gadget never collides with a real Deck), and capability attrs (`0x09=0x2e`, `0x0b=0x0fa0`, `0x02/0x0c/0x0d/0x0e=0`). **This blob is the fix.** - **`0xAE` GET_STRING_ATTRIBUTE** — `[ae, len, attr, ascii]`: serial (attr 1), board serial (attr 0). - Other commands (e.g. `0x87` settings) read back the last write (echo). Result on the Deck (`feature_reply` in `steam_gadget.rs`): **1 connect / 0 disconnect / 1 gamepad evdev** (was constant churn), and Steam *activates* the controller cleanly (no `GetControllerInfo failed`, no zombie) and emits its **X-Box 360 pad**. usbmon on the gadget's bus confirms our state reports (with the pressed button at byte 8) are delivered on the interrupt-IN and consumed by hid-steam — so the input transport is proven end-to-end. ## Remaining - **Glass confirmation of the XInput mapping** — Steam Input only maps the gadget's raw input onto its X-Box pad while a game using Steam Input is focused; confirm a button reaches a real game, then default the gadget on for SteamOS hosts (it's strictly better than the non-promoted UHID path). - A `punktfunk-host` build for SteamOS to exercise the integrated path end-to-end with a live client.