Steam Controller 2026: identify + parse via WebHID without Steam Input

[petegordon]

Tracking the technical hurdle for getting the 2026 Steam Controller working in the lab. Valve's official integration path is Steam Input, but we want raw WebHID access so the controller works in the overlay without requiring Steam to be running.

What we know

• Valve USB vendor ID: 0x28de
• 2026 Steam Controller product ID: TBD — needs capture from a real device. Original 2015 Steam Controller was 0x1102 (USB) / 0x1142 (wireless dongle); Steam Deck's embedded controller is 0x1205. The 2026 device is likely a new pid.
• CAD already in hand: gitlab.steamos.cloud/SteamHardware/SteamController (CC BY-NC-SA 4.0). GLB conversion + visualizer profile shipped in PR Steam Controller 2026 visualizer (Valve CAD → optimized GLB) #6 (steam-controller.glb, body-only).
• Driver stub already in repo: packages/core/src/drivers/steam-controller-driver.js — currently identity-only, no protocol parsing.
• Pending DEVICES entry: PENDING_DEVICES['Steam Controller 2026'] in devices.js waits for the captured pid to be promoted to DEVICES.

What we don't know

• Whether the controller is exposed to WebHID at all when Steam is running (Steam Input typically grabs exclusive HID access).
• Whether the new device speaks Valve's Steam Input HID protocol (custom binary, well-documented for the 2015 Steam Controller) or something else.
• Whether the Gamepad API sees it natively in any mode (without Steam Input, Chromium probably doesn't have a built-in mapping for the Valve layout).
• The product-id under each operating mode (the controller may have multiple modes — Steam Input mode, BLE mode, dongle, etc.).

Approach options

1. Field a Test Report capture (current ask): open the overlay with the controller plugged in, run the Test Report wizard if it triggers, or capture the raw HID input reports via a one-off DevTools console probe. Goal: learn the vid:pid + report shape.
2. Reuse the 2015 Steam Controller HID protocol as a starting point if the 2026 device shares the layout. Linux kernel has hid-steam.c as a reference; community documentation at https://gitlab.com/open-source-devices/steam-controller.
3. Steam-running compatibility: document whether the user needs to kill Steam / disable Steam Input gamepad detection for the lab to see the device. May not be solvable from our side.
4. BLE mode: 2026 device supports Bluetooth — BLE-GATT exposure may differ from USB HID; needs separate investigation.

Acceptance criteria

• Captured a Test Report (or raw HID dump) for the Steam Controller in a real plug-in scenario
• vid:pid documented in PENDING_DEVICES comment + promoted to DEVICES once verified
• SteamControllerDriver stub extended with at least button/stick parsing from the 2015-style protocol (if applicable) or a documented "identity-only, Gamepad-API for everything" decision
• Docs note in ADDING-A-CONTROLLER.md covering the Steam Input coexistence story

[petegordon]

vid:pid captured for the 2026 Steam Controller

PowerShell scan of present HID devices with Valve's vendor ID, with the controller plugged in over USB and Steam stopped:

```
FriendlyName InstanceId

---

USB Input Device USB\VID_28DE&PID_1304&MI_03\6&20E46D5A&0&0003
HID-compliant vendor-defined device HID\VID_28DE&PID_1304&MI_05&COL03\7&6625A10&0&0002
USB Input Device USB\VID_28DE&PID_1304&MI_04\6&20E46D5A&0&0004
USB Input Device USB\VID_28DE&PID_1304&MI_05\6&20E46D5A&0&0005
HID-compliant vendor-defined device HID\VID_28DE&PID_1304&MI_02&COL03\7&16E2589C&0&0002
HID-compliant vendor-defined device HID\VID_28DE&PID_1304&MI_06\7&1E25E655&0&0000
USB Input Device USB\VID_28DE&PID_1304&MI_06\6&20E46D5A&0&0006
HID-compliant vendor-defined device HID\VID_28DE&PID_1304&MI_03&COL03\7&3AB9965E&0&0002
HID-compliant vendor-defined device HID\VID_28DE&PID_1304&MI_04&COL03\7&2A3997D2&0&0002
USB Input Device USB\VID_28DE&PID_1304&MI_06\6&20E46D5A&0&0002
```

Product ID: `0x1304` (composite USB device with at least 5 HID interfaces: MI_02 / 03 / 04 / 05 / 06).

All interfaces are "HID-compliant vendor-defined" — none use the standard gamepad usage page (0x0001 / 0x0005). Implications:

• Chromium's Gamepad API likely won't enumerate this as a gamepad → the overlay's main detection path (gamepadconnected event + navigator.getGamepads()) won't see it.
• WebHID enumeration will find each interface, but parsing requires the actual report descriptor / Valve's protocol knowledge per interface (MI_02 might be the gamepad emulation interface, MI_05 might be the Steam Input native protocol, etc.).
• The composite layout matches the 2015 Steam Controller's pattern (which had ~5 interfaces too).

Next steps:

• Update PENDING_DEVICES['Steam Controller 2026'] in devices.js with the captured pid 0x1304.
• Try the Test Report wizard against it to see what (if anything) reaches the overlay.
• For protocol parsing, follow the Linux `hid-steam.c` driver as the reference: https://github.com/torvalds/linux/blob/master/drivers/hid/hid-steam.c.

[petegordon]

WebHID enumeration confirms it's the Puck (dongle), not the controller body

From DevTools in the overlay with Steam stopped:

```js
navigator.hid.getDevices().then(devices =>
devices.filter(d => d.vendorId === 0x28de)
.forEach(d => console.log(d.productName, d.vendorId.toString(16), d.productId.toString(16), 'collections:', d.collections.length))
)
```

Output (5 entries — matches the 5 USB interfaces from the PowerShell scan):

```
Steam Controller Puck 28de 1304 collections: 3
Steam Controller Puck 28de 1304 collections: 1
Steam Controller Puck 28de 1304 collections: 3 (3×)
```

Key finding: productName === \"Steam Controller Puck\". The USB-plugged device is the wireless dongle (Puck), and the actual Steam Controller body talks to it over RF. So:

• 0x28DE:0x1304 identifies the Puck, not the controller
• The Gamepad API ignores all 5 interfaces (vendor-defined HID, no standard gamepad usage page)
• Chromium's `bootstrapFromHID` returns "no granted gyro-capable device found" — the overlay's normal detection paths don't fire

Implications:

• Even after promoting to DEVICES with pid 0x1304, the overlay's current code paths (driven by Gamepad-API detection) won't activate. Need a Puck-aware code path that enumerates via WebHID directly.
• The Steam Controller body's own vid:pid (if it has one separate from the Puck) is unknown — it never connects over USB. May only be discoverable via Bluetooth pairing or by inspecting the Puck's RF reports.
• Steam Input on Windows likely talks to the Puck (which then forwards RF) — that's why the Puck has 5 interfaces (probably: 1 for the controller passthrough, 1 for keyboard emulation, 1 for mouse emulation, 1 for Steam's IPC, 1 for firmware update).

Next investigation step: pick each interface in turn, subscribe to `inputreport` events with the controller body powered + paired, see which interface(s) emit reports. The interface with active reports = the gamepad data channel.

[petegordon]

Input data channel identified: iface[3], reportId=0x45, 53 bytes

Using the WebHID inputreport probe (controller body powered + paired wirelessly to the Puck), only one of the 5 interfaces emits reports:

```
iface[3] colls=3 report#1 reportId=0x45 len=53 bytes[0..32]:
38 00 00 00 00 00 00 00 00 51 ff e8 03 30 01 0e 04
00 00 00 00 00 00 00 00 00 00 00 00 3c a8 a8

iface[3] colls=3 report#50 reportId=0x45 len=53 bytes[0..32]:
68 00 00 00 00 00 00 00 00 38 ff a1 03 48 01 f6 03
00 00 00 00 00 00 00 00 00 00 00 00 cb 34 ab
```

Other interfaces (0, 1, 2, 4) emitted zero reports during the 10-second test → they're for non-controller functions (keyboard/mouse emulation, Steam IPC, firmware update, etc.).

Byte layout (preliminary, from no-input rest captures)

Bytes	Likely role
0	counter / timestamp (38 → 68 between samples 1 and 50)
1–8	button bitfield + stick analog (all zero with no inputs)
9–10	int16 ≈ -175 to -200 (gyro axis bias?)
11–16	three int16s in the ~300–1100 range — almost certainly IMU (3-axis gyro or accel)
17–28	zeros — reserved / trackpad data when not touched?
29–31	varying — possibly CRC, or trackpad position when touched

Format hypothesis

53-byte report + counter + bitfield + IMU + CRC structure matches Valve's Steam Input HID protocol family (Linux `hid-steam.c`). The 2015 Steam Controller used reportId 0x01 len 64; 2026 uses 0x45 len 53 — a variant, not a new family. Decoding the rest will require:

1. Cross-reference with the Linux driver's button bitfield + IMU offset constants
2. Diff captures with each individual input pressed (face buttons, sticks, triggers, trackpads, back paddles, gyro)
3. Likely a fresh Test Report wizard run specific to this device once we have an inferred profile

Action items

• Promote PENDING_DEVICES['Steam Controller 2026'] → DEVICES with productId: 0x1304, mark it as the Puck (note in comment)
• Decide on data path: extend SteamControllerDriver to talk directly to WebHID iface[3] (bypasses Chromium Gamepad API entirely, which never sees this device)
• Capture per-input diffs to decode the byte layout (could extend the Test Report wizard's "Unknown" path to subscribe to WebHID reports directly when Gamepad API has nothing)
• Acknowledge in docs that Steam Input cannot be running simultaneously

[petegordon]

10-second probe summary — iface[3] confirmed as the sole active channel

```
iface[0] colls=3 reports=0
iface[1] colls=1 reports=0
iface[2] colls=3 reports=0
iface[3] colls=3 reports=2711 ← ~271 Hz
iface[4] colls=3 reports=0
```

Other four interfaces emit zero reports under any input. So the protocol target is unambiguous:

• vid:pid: `0x28DE:0x1304` (Puck)
• Interface index: 3 (collections = 3)
• Report ID: `0x45`
• Report length: 53 bytes
• Rate: ~271 Hz steady (about 3.7 ms between reports) — comparable to a real DualSense's 250–500 Hz USB rate

When parser work starts, the inputreport subscription only needs to listen on this one interface; the other four can be ignored (they're for keyboard/mouse emulation, Steam IPC, firmware update, etc.).

[petegordon]

Why the ad-hoc capture returned zero reports: controller is in keyboard/mouse fallback mode

After running an ad-hoc Test Report-style capture against iface[3], zero reports came back across all 14 steps. But during the capture, the controller's button presses + trackpad drags were visibly driving the OS as keyboard + mouse input (cursor moving, OS shortcuts firing, etc.).

That confirms the Puck has two operating modes:

1. Keyboard/mouse fallback mode (default when Steam Input isn't claiming the device): the Puck firmware exposes interfaces emulating a standard HID keyboard + HID mouse. iface[3] (the Steam Input native HID channel) is silent in this mode. This is what makes the controller usable on any computer without Steam installed.

2. Steam Input native mode: when Steam is running, it sends a specific HID feature/output report to the Puck telling it to suppress keyboard/mouse emulation and start streaming raw gamepad state on iface[3]. The 271 Hz reports we saw in the first probe were caught in this mode — likely a residual state from a recent Steam session.

Implication for the lab

A working SteamControllerDriver needs more than byte-layout reverse-engineering. The driver has to:

1. Send the mode-switch command (an output or feature report) to put the Puck into Steam Input mode. Specific magic bytes TBD — Linux `hid-steam.c` has the 2015 device's switch, but the 2026 version is unverified.
2. Suppress / coexist with Steam Input — if Steam launches mid-session and claims the device, our driver needs to detect that and gracefully drop. Conversely, if our driver claims first, Steam may fail to find the controller.
3. Reset the mode on disconnect so the user's controller goes back to keyboard/mouse fallback when our app exits (otherwise they'd have a useless controller until they relaunch Steam).

Reference

• 2015 Steam Controller protocol (Linux): https://github.com/torvalds/linux/blob/master/drivers/hid/hid-steam.c
• Community SC docs: https://gitlab.com/open-source-devices/steam-controller
• 2026 device differs at least in: vid:pid (28de:1304 Puck), reportId (0x45 vs 0x01), report length (53 vs 64). Probably also differs in feature-report magic numbers.

Acceptance criteria update

Adding a step before the existing parser work:

• Reverse-engineer + document the Puck's Steam Input mode-switch feature/output report (capture from a fresh Steam launch with Wireshark/usbpcap)
• `SteamControllerDriver.init()` sends the mode-switch
• `SteamControllerDriver.destroy()` reverts to keyboard/mouse fallback
• Then: byte-layout decode + `parseReport()` (the original ask)

[petegordon]

Major: direct USB-C connection skips the keyboard/mouse fallback + emits raw Steam Input HID immediately

Plugging the Steam Controller directly into USB-C (bypassing the wireless Puck dongle) exposes a different USB device that emits the Valve Steam Input HID format with no mode-switch required.

Identity comparison

Connection	vid:pid	What it is	USB interfaces	Default behavior
Wireless via Puck	`0x28DE:0x1304`	Puck dongle (forwards RF)	5 vendor-defined HID	Keyboard/mouse fallback unless Steam sends mode-switch; iface[3] silent in fallback
USB-C direct	`0x28DE:0x1302`	Controller body	1 HID interface	Steam Input HID flows immediately at ~249 Hz alongside the keyboard/mouse emulation

Serial number on the direct connection: `FXA9960201505` (printed in the USB `InstanceId`).

Sample reports (direct USB-C, no inputs)

```
reportId=0x45, len=53

sample[0]: 05 00 00 00 00 00 00 00 00 38 ff 77 04 1b 02 bc 02
00 00 00 00 00 00 00 00 00 00 00 00 81 ba 4f 05
cd f8 e5 f3 fc 42 00 00 1a 00 05 00 00 00 00 00
00 00 00
sample[1]: 06 ... 0a 03 ... ae c9 4f 05 4e 03 61 f4 80 42 ...
sample[2]: 07 ... 8f 04 ... db d8 4f 05 74 00 65 f5 4b 3d ...
```

Preliminary byte layout (verified-at-rest)

Bytes	Role	Notes
0	Counter	+1 per report
1–8	Button bitfield + stick analog	All zero at rest, no inputs
9–16	IMU (3 int16s + 1 int16?)	Small noise values
17–28	Reserved / trackpad when touched	All zero at rest
29–32	uint32 timestamp (LE, ~1.25 MHz clock)	Confirmed: 89308289 → 89313198 → 89321691
33–38	Secondary IMU? Trackpad?	Active even with no input
39–52	Possibly CRC + extras	Active even with no input — interesting

Implication for driver work

The mode-switch reverse-engineering prereq from the previous comment only applies to the Puck. For USB-C direct, the driver path is simpler:

1. `SteamControllerDriver` listens on the single HID interface of `0x28DE:0x1302`
2. parseReport decodes the 53-byte Valve format
3. No feature-report magic needed

The Puck path is still desirable (wireless is the typical use case), but USB-C-only support is a much smaller deliverable and would let the driver actually work without Wireshark / mode-switch reverse engineering.

Updated acceptance criteria

• Add `0x28DE:0x1302` as a separate DEVICES entry ("Steam Controller 2026 (direct USB)") — capabilities can be `{gyro:true,accel:true,touchpad:true}` since the Valve protocol delivers all of those
• Structured byte-diff capture (per-input ad-hoc test against `0x1302` — needs a refined capture script targeting this pid specifically)
• `SteamControllerDriver.parseReport` for the byte layout
• Then (separately): Puck mode-switch reverse engineering for the wireless path

[petegordon]

Steam Controller direct-USB (pid 0x1302): preliminary 53-byte report layout

Structured 19-step capture (994 reports/step × 19 steps = 18,650 reports total at 248Hz) analyzed via per-byte stddev vs at-rest baseline + per-byte top-step ownership. Output of `tools/` byte-diff scripts.

Confirmed byte map (high confidence)

Bytes	Role	Notes
0	Counter	+1 per report, mod 256
1	Back paddle bits	Range 0..128, ~3 distinct values → top bit + a couple paddle bits
3	R2 digital + face bits	Range 0..128, also activates with face-X (bit 4 = 0x10)
5	L2 trigger analog	Full 0..255 sweep during left-trigger pull
7	R2 trigger analog	Full 0..255 sweep during right-trigger pull
9–10	Left stick X (uint16 LE)	byte 10 dominant high byte; byte 9 low byte
11–12	Left stick Y (uint16 LE)	shoulders + grip on byte 11 likely IMU bleed, not stick
13–14	Right stick X (uint16 LE)	byte 14 high byte
15–16	Right stick Y (uint16 LE)	byte 16 high byte
17	Left trackpad: touched flag	0 at rest, non-zero during drag (stddev 83)
18–19	Left trackpad X (uint16 LE)	Full sweep during drag
20–21	Left trackpad Y (uint16 LE)	Full sweep during drag
23	Right trackpad: touched flag	Symmetric with left
24–25	Right trackpad X (uint16 LE)
26–27	Right trackpad Y (uint16 LE)
29–32	uint32 timestamp (LE, ~1.25 MHz tick)	Already confirmed via earlier samples; byte 32 = 0x05 stable high byte
33–38	IMU (gyro 3-axis, int16 LE per axis)	byte 36 high-stddev across pitch/roll/yaw; bytes 33-34 and 37-38 also active per axis (exact X/Y/Z mapping TBD)
45–52	Always zero	Padding / reserved

Open questions / next captures

• Face button bits (A/B/X/Y): face-A capture showed no byte changes above threshold. Either A is in a byte that already has high natural variance (likely a CRC byte) or the button-press wasn't held long enough during capture. Need a targeted re-capture: hold each face button down for the full 4 seconds, not tap.
• L1/R1 (shoulders): shoulders step's top owner is byte 11 (IMU bleed from grip) rather than a button byte. Need a no-grip shoulders capture (controller resting on a desk, press shoulders only).
• Steam/Home button: shows up in byte 34 + byte 36, both already CRC-like / IMU-bleed. Same as face buttons — needs a held-press isolated capture.
• Trackpad pressure: byte 31 jumps massively during right-trackpad (110 stddev vs 16 rest). Likely pressure or another trackpad axis. Worth a hard-press vs light-touch differentiation step.
• Bytes 39–44: high stddev across ALL steps including rest, but not clearly tied to any one input. Likely CRC (varies with everything) or per-frame entropy. Compute CRC32/CRC16/CRC8 over bytes 0-38 of a few samples to verify.
• Bytes 35–38 IMU axis mapping: pitch activates 36+38, roll activates 35+36+38, yaw activates 36 only. Suggests gyro at bytes 33-38 as 3 int16s but the per-axis attribution needs single-axis-only isolation (hold the controller against a desk on the other two axes).

What this enables

This is enough to write the first 60% of `SteamControllerDriver.parseReport` for the direct USB-C connection (pid 0x1302):

• Sticks + triggers + trackpads + timestamp all decode-able right now
• Buttons (face + shoulders + Steam) still need targeted re-capture
• IMU axis-mapping needs more isolation

The Puck-mode-switch reverse-engineering work (separate prereq for wireless) is still pending, but isn't on the critical path for getting something working over wired USB.

[petegordon]

Level-B DevTools demo result: parser confirmed working, three findings

Ran the level-B DevTools script (Steam Controller direct USB-C → parse 53-byte report → drive Button HUD). Result:

What worked

• L2/R2 trigger analog values parse correctly from bytes 5 / 7. Console log showed `L2=0.00` → `L2=1.00` cleanly with full trigger pulls.
• Left and right stick axes track movement smoothly. Bytes 9-10 (LX), 11-12 (LY), 13-14 (RX), 15-16 (RY) — high confidence on those 8 bytes.
• Popout HUD reacts immediately to all of the above via the existing button-hud-state IPC channel.

Findings worth recording

1. Y axes are inverted vs the Gamepad-API convention the HUD expects. The lab's stick dots use "up = negative Y" (standard Gamepad API); Steam Controller's int16 LE values at bytes 11-12 and 15-16 use the opposite sign. Fix for the level-C driver: negate `ly` and `ry` after parsing, OR have the visualizer profile's gyroTransform-style hook apply the sign flip. Single-character change.

2. In-overlay HUD doesn't react to script-injected state — only the popout does. Diagnosed in the demo:

   • The popout receives state via the `button-hud-state-update` IPC channel and applies it directly to its DOM.
   • The in-overlay HUD is driven by app.js's animation loop, which calls `updateButtonHud(gamepad)` every frame with whatever `readGamepad()` returned. Steam Controller has no Gamepad-API presence → `readGamepad()` returns null → loop overwrites my DOM updates with "nothing pressed" each frame.
   • Implication for level-C: SteamControllerDriver needs to feed a synthetic Gamepad-shaped object through the existing manager.js path so `readGamepad()` returns it. Once that's wired, both HUDs animate from the same source. The synthetic-gamepad pattern already exists in DualSense's BT path (`syntheticGamepad` in app.js); same model would work.

3. Demo bypassed any byte-mapping ambiguity for sticks/triggers — those decoded cleanly on the first try. The remaining gaps are exactly as the byte-map comment notes: face buttons (need held-press isolation captures), shoulders, Steam button, IMU per-axis mapping, bytes 39-44 CRC verification.

Concretely, level-C driver TODO is now well-scoped:

• Sign-flip `ly` and `ry` (negate)
• Build synthetic Gamepad object in `SteamControllerDriver.parseReport` from the decoded bytes
• Surface the synthetic gamepad through manager.js so `readGamepad()` returns it (model the BT-DualSense fallback path)
• Targeted captures for face buttons, shoulders, Steam button (isolate each press from grip / motion / trigger interference)
• IMU per-axis mapping captures
• Bytes 39-44: verify CRC32/16/8 over bytes 0-38

[petegordon]

📋 Full implementation roadmap

Captured from today's investigation — three phases, sized for planning. Each phase delivers standalone value; you can stop after any of them.

---

Phase 1 — Direct USB-C minimum viable driver (~4–6 hours)

Gets you a Steam Controller fully usable via USB-C cable, no Steam dependency, no special tools needed beyond DevTools.

Why this works without special tools: the controller body (pid `0x1302`) streams the Steam Input HID format on iface[3] immediately upon connection — no mode-switch required. Today's level-B demo proved this. The protocol is all observable from WebHID + DevTools.

Task	Effort	Detail
Targeted held-press captures for face buttons, shoulders, Steam button	~1 hr	Re-run the wizard-style script with each input held for the full step (not tapped), controller resting on a desk to remove grip / IMU noise. Identifies which byte/bit each button uses.
IMU per-axis isolation captures	~30 min	Pitch / roll / yaw one at a time with the other two axes clamped against a desk. Decodes the gyro X/Y/Z mapping within bytes 33-38.
CRC verification on bytes 39-44	~15 min	Compute CRC32 / CRC16 / CRC8 over bytes 0-38 of sample reports and compare to bytes 39-44. Confirms checksum and tells us the algorithm — needed for input validation.
Write SteamControllerDriver.parseReport	~1 hr	Bytes documented in the byte-map comment, with Y-axis sign flip on sticks. Output matches DualSense's shape: {sticks, triggers, buttons, gyro, accel, touchpad}.
Build synthetic Gamepad path	~1 hr	Model on app.js's existing syntheticGamepad (DualSense BT fallback path). readGamepad() returns the synthetic; updateButtonHud(gamepad) sees it; in-overlay HUD finally reacts (not just popout).
Update DEVICES entry capabilities	~5 min	Flip NO_CAPS to {gyro: true, accel: true, touchpad: true} once driver works. Activates the existing auto-connect WebHID filter path.
Test + tune sign-flips, axis remaps	~30 min	Match physical motion to on-screen rotation; tune stick deadzones + trigger curves; verify gyro convention matches DualSense's gyroTransform expectation.

Deliverable: cable-connected Steam Controller renders 3D model + animates button/stick/trigger/trackpad/gyro in both the in-overlay HUD AND popout HUD. All the same animations DualSense gets.

---

Phase 2 — Wireless Puck path (~6–10 hours, requires USB sniffer tooling)

Adds wireless support via the Puck dongle (pid `0x1304`).

Why this is harder: the Puck (when Steam isn't running) defaults to keyboard/mouse emulation. iface[3] is silent. To make it stream Steam Input HID data, we have to send the Puck a "switch to Steam Input native mode" feature/output report. We don't know what that report contains. The only way to discover it is to capture USB traffic when Steam launches, isolate the feature reports Steam sends to the Puck, and replicate them from our driver.

Task	Effort	Detail
Install USB packet capture tooling	~30 min	Wireshark + USBPcap on Windows (or usbmon on Linux, IORegistryExplorer patterns on macOS).
Capture Steam Input mode-switch	~1–2 hr	Start USBPcap on the Puck's USB bus, plug in Puck (no other Steam-related processes running), launch Steam, watch reports go by. Filter to HID feature/output reports. Identify the ones Steam sends right before iface[3] starts emitting.
Decode the mode-switch report shape	~1 hr	Captured bytes need interpretation — what command, what data, what response is expected. May need multiple capture passes to confirm.
Implement driver.init() mode-switch send	~1 hr	Send the same magic bytes via device.sendFeatureReport() or device.sendReport() during driver init. Verify iface[3] starts emitting.
Implement driver.destroy() revert	~1 hr	Send the unswitch command on disconnect, otherwise user's controller is stuck in Steam Input mode after our app exits — they'd be unable to use it elsewhere until they replug or relaunch Steam.
Handle iface[3] selection on the Puck	~30 min	Same byte layout from Phase 1 applies; just pick the right interface (the one with 3 collections per the earlier probe).
Coexistence with running Steam	~1–2 hr	If Steam launches mid-session, both apps fight for the device. Need detection ("Steam is running, give up gracefully") or some mediation.

Deliverable: wireless Steam Controller works in the lab when Steam isn't running, with clean recovery if user launches Steam later.

---

Phase 3 — Polish (~3–5 hours, optional)

Rounds out the experience to parity with DualSense.

Task	Effort	Detail
Rumble + LED output reports	~1–2 hr	Same Valve protocol family, send-side bytes still need reverse engineering — but Linux hid-steam.c may have the 2015 version as a reference.
Gyro bias auto-calibration	~1 hr	Model on the existing SensorFusion calibration loop in manager.js.
Settings: explicit Puck vs direct-USB choice when both present	~30 min	Dictionary lookup picks first match today; could add a settings dropdown when both 0x1302 and 0x1304 are enumerated.
Trackpad widgets in HUD	~2 hr	Cross-tracked in #7.
3D model with separated meshes for per-button animation	~3 hr	Blender pass on the STEP CAD file (already in Valve's GitLab repo). Documented in OPTIMIZING-GLB.md.

---

Critical-path totals

• Useful Steam Controller via USB-C only: Phase 1 (~4–6 hours, all WebHID-observable, no special tooling)
• Useful wireless Steam Controller: Phase 1 + Phase 2 (~10–16 hours, Phase 2 requires Wireshark + patience)
• DualSense-parity polish: All three phases (~13–21 hours)

The reverse-engineering risk is concentrated in Phase 2's mode-switch capture. Everything else is incremental work against known-shaped data. Recommended order: Phase 1 first regardless of long-term scope; it's the highest value per hour and is what proves the byte map and driver-shape decisions before they're spread across both paths.

[petegordon]

🎯 Prior art survey — most of Phase 2 is no longer needed

Researched what other open-source projects have already done for the 2026 Steam Controller. Two ready-to-borrow implementations found:

Tier 1 — Borrow code directly

ddeverill/SteamlessController (v1.1, May 11 2026, C++)

• Explicitly targets the 2026 device — both `0x1302` (wired Ibex) and `0x1304` (Proteus dongle / what we've been calling the Puck).
• `src/steam/SteamController.h` contains the full 53-byte input report layout, decoded.
• Documents the lizard-mode-disable feature report we were going to need Wireshark for:
  • `buf[0]=0x01, buf[1]=0x81` = CLEAR_DIGITAL_MAPPINGS
  • `buf[0]=0x01, buf[1]=0x87` = SET_SETTINGS (trackpad mode = 0x00)
  • Heartbeat: re-send CLEAR_DIGITAL_MAPPINGS every 800ms to keep the controller in Steam Input mode (otherwise it reverts to keyboard/mouse fallback after the timeout).
• Byte layout summary: seq counter @1 · button bitfields @2-5 · triggers (int16 LE 0-0x7FFF) @6-9 · L stick @10-13 · R stick @14-17 · L pad XY+area @18-23 · R pad XY+area @24-29 · magic `0x03 0x46` @30-31 · IMU quaternion (4× int16) @32-39 · battery @44-45.
• License check first, then vendor the parsing.

libsdl-org/SDL (`src/joystick/hidapi/SDL_hidapi_steam.c`, last touched May 23 2026)

• Valve-independent 2026 support landed days ago. Phoronix confirmation ("SDL Library Adds Support For The New Steam Controller Without Depending On Steam").
• PIDs in `src/joystick/usb_ids.h`: `STEAM_PROTEUS_DONGLE = 0x1304` (our Puck), `STEAM_NEREID_DONGLE = 0x1305` (likely future BLE).
• Internal struct `SteamControllerStateInternal_t` has full IMU quaternion handling.
• Feature-report enum: `ID_LOAD_DEFAULT_SETTINGS`, `ID_CLEAR_DIGITAL_MAPPINGS`, `ID_GET_ATTRIBUTES_VALUES` — confirms SteamlessController's bytes are correct.
• MIT-style license; can vendor / port to JS.

Tier 2 — Watch only

• Linux kernel `hid-steam.c` (source) — no 2026 commits yet (last Aug 2025). Worth subscribing; maintainer `endrift` (Valve-adjacent) is the likely committer.
• OpenSteamController/Ibex-Firmware — archives Valve's shipped firmware blobs. Useful if firmware-level RE ever lands; not for HID parsing today.

Tier 3 — Ignore (2015 device only)

• greggersaurus/OpenSteamController + forks, cvuchener/steamcontroller-linux-kernel, kolrabi/steamcontroller, mitchmikusek/steam_controller_tools — original 2015 LPC11U37F era, no 2026 work.

Negative findings

• Chromium: no 2026 Steam Controller PIDs in `device/gamepad/`. Will continue to route via OS APIs (which means via Steam Input on Windows). WebHID is the only Chromium path.
• WebHID libraries (`dualsense-ts`, `jsDualsense`): nothing for Steam Controller. Greenfield for our work — we'd be the first WebHID-based Steam Controller driver.
• Valve GitLab (`gitlab.steamos.cloud`): no public Ibex/Proteus repos beyond the CAD drop we already used.

Revised roadmap

Phase	Original	Revised	What changed
1 — Direct USB-C driver	4–6 hr	2–3 hr	Borrow SteamlessController's verified byte layout instead of capture-and-decode
2 — Wireless Puck	6–10 hr	2–3 hr	Lizard-mode bytes known; Wireshark no longer needed
3 — Polish	3–5 hr	unchanged

Total: ~7–11 hours for a fully working Steam Controller driver (was 13–21).

Corrections to earlier analysis

Two facts the prior art clarifies:

1. Input report ID: SteamlessController + SDL say `0x42`. Our capture saw `0x45`. Could be off-by-one device variant, or both IDs exist for different report shapes. Verify against our raw capture by checking the actual ID field in the saved JSON before writing parser code.

2. IMU is a quaternion (4× int16 starting at byte 32), not three independent gyro axes. Our "bytes 33-38 active in pitch/roll/yaw" observation was reading three of the four quaternion components. Why pitch + roll both lit up byte 36: it's the W (scalar) component, which changes with any rotation regardless of axis. Better than 3-axis gyro for our visualizer — orientation is available directly without integration; same path as the existing DualSense quaternion fusion can consume it.

Updated action items

• Verify SteamlessController is MIT-or-compatibly licensed → vendor `SteamController.h` into our repo as a reference
• Cross-reference our direct-USB capture against SteamlessController's byte layout to verify; resolve the 0x42 vs 0x45 reportId discrepancy
• Implement `SteamControllerDriver.init()` to send the two lizard-mode-disable feature reports + start 800ms heartbeat
• Implement `SteamControllerDriver.destroy()` to stop the heartbeat (controller reverts to keyboard/mouse after ~800ms naturally — no explicit unswitch needed)
• parseReport using the documented layout, with IMU as a quaternion (skip the per-axis gyro decomposition we were planning)
• Watch `libsdl-org/SDL` and `torvalds/linux` for further commits; `SteamController.h` for any v1.2+ updates

[petegordon]

🗺️ Canonical byte map (sourced from SteamlessController/SteamController.h)

Fetched the actual header file. Locking the byte layout here so future work has a single reference.

Input report IDs the device emits

ID	Name	Bytes	Purpose
`0x42`	REPORT_STATE	53	Full controller state — sticks, buttons, triggers, trackpads, IMU
`0x43`	REPORT_SECONDARY	14	Gyro / secondary state
`0x44`	REPORT_STATUS	5	Battery / connection status
`0x45`	REPORT_EXTENDED	45	Extended sensor state
`0x7B`	TBD	12	Unknown
`0x79`	TBD	1	Unknown

⚠️ Discrepancy with our capture: we saw `reportId=0x45` with 53 bytes of data — but SteamlessController documents 0x45 as 45 bytes and the 53-byte STATE report as ID 0x42. Two possibilities: (a) the 2026 device renumbered the IDs from the 2015 device SteamlessController was originally built around, or (b) our DevTools script's `if (e.reportId !== 0x45) return;` filter dropped the 0x42 STATE reports silently. Easy to verify: re-probe with no filter and log every unique reportId.

Full 53-byte STATE report layout

(`buf[0]` = reportId in the source repo's indexing; WebHID's `event.data` strips reportId so subtract 1 to get the WebHID offset)

Source buf[]	WebHID data[]	Field	Encoding
1	0	Sequence counter	uint8, wraps 0xFF → 0x00
2	1	Buttons byte 0	bits: A=0x01, B=0x02, X=0x04, Y=0x08, R3=0x20, Menu=0x40, R4=0x80
3	2	Buttons byte 1	R5=0x01, RB=0x02, dpadDn=0x04, dpadRt=0x08, dpadLt=0x10, dpadUp=0x20, View=0x40, L3=0x80
4	3	Buttons byte 2	Steam=0x01, L4=0x02, L5=0x04, LB=0x08, RStickTouch=0x10, RTrackpadActive=0x20, RTrigFull=0x80
5	4	Flags byte	LStickTouch=0x01, LTrackpadActive=0x02, LTrackpadHardClick=0x04, GripRt=0x10, GripLt=0x20
6-7	5-6	Left trigger	int16 LE, 0..0x7FFF
8-9	7-8	Right trigger	int16 LE, 0..0x7FFF
10-11	9-10	Left stick X	int16 LE signed, center 0, ±0x7FFF
12-13	11-12	Left stick Y	int16 LE signed
14-15	13-14	Right stick X	int16 LE signed
16-17	15-16	Right stick Y	int16 LE signed
18-19	17-18	Left trackpad X	int16 LE signed, 0x0000 when not touching
20-21	19-20	Left trackpad Y	int16 LE signed
22-23	21-22	Left trackpad contact area	int16 LE, 0 = no contact, higher = more area/pressure
24-25	23-24	Right trackpad X	int16 LE signed
26-27	25-26	Right trackpad Y	int16 LE signed
28-29	27-28	Right trackpad contact area	int16 LE
30-31	29-30	Constant `0x03 0x46`	Firmware info?
32-39	31-38	IMU quaternion	4× int16 LE — orientation directly, no integration needed
40-43	39-42	Unknown / always zero
44-45	43-44	Battery (0xFF 0xFF = full)	uint16 LE
46-53	45-52	Gyro at rest	constant when stationary

Lizard-mode-disable feature reports

Send via WebHID `device.sendFeatureReport(0x01, payload)`:

CLEAR_DIGITAL_MAPPINGS:  buf[0]=0x01 (feature report ID), buf[1]=0x81 (cmd byte)
SET_SETTINGS:            buf[0]=0x01, buf[1]=0x87, payload sets right trackpad mode (key 0x07) = NONE (0x00)
                                                   and left trackpad mode (key 0x08) = NONE (0x00)

Send both at init. Re-send CLEAR_DIGITAL_MAPPINGS every 800ms as a heartbeat — without it, the controller reverts to keyboard/mouse fallback after the timeout.

Fallback feature report ID is `0x02` if 0x01 fails.

Restore on exit: `buf[0]=0x01, buf[1]=0x85` (CMD_SET_DEFAULT_MAPPINGS) — controller goes back to keyboard/mouse fallback so the user's not stuck.

Reconciliation with our existing analysis

Our earlier byte-diff analysis aligns well with the canonical layout:

• ✅ Sticks identified at correct offsets (bytes 9-16 in WebHID indexing)
• ✅ Triggers at bytes 5-8 (we saw bytes 5 and 7 vary as "uint8" — actually low bytes of int16 LE, and the high bytes 6/8 only kicked in when trigger > 50%)
• ✅ Trackpads at bytes 17-28
• ✅ Constant `0x03 0x46` at bytes 29-30 — we noted byte 32 stayed at 0x05 stable, but our offset analysis was slightly off — the actual constant is one byte earlier
• ❌ Our "uint32 timestamp" hypothesis at bytes 29-32 was wrong — those are actually the firmware-info constant (29-30) + the start of the IMU quaternion (31-32 is the W or X component)
• ⚠️ IMU is a quaternion (4× int16), not 3-axis gyro+accel — much better for the visualizer (orientation directly available)
• ⚠️ Byte 17 isn't a "touched flag" — it's the low byte of trackpad X, which reads 0 when not touched. Same visual behavior for the demo but properly parsed as part of an int16 XY pair

SDL issue #15471 — relevant comment

Kuratius noted: on the 2015 device at least, the Steam client does NOT take exclusive HID access — SDL apps can read input in parallel with Steam running. If this holds for the 2026 device, the "coexistence with running Steam" line item in Phase 2 may be a non-issue. Worth testing once a driver lands.

[Kuratius]

You proably shouldn't copy Claude output and pretend you wrote it.
The SDL code is fine to read manually once you get more familiar with it.
It might be worth checking if the driver can just be built via emscripten instead of doing duplicate work.
The 2026 controller shares the same behavior as the 2015 one, though you may need a bleeding edge build of SDL since they recently swapped the report layout to the BLE one in a controller firmware update.

[petegordon]

You proably shouldn't copy Claude output and pretend you wrote it. The SDL code is fine to read manually once you get more familiar with it. It might be worth checking if the driver can just be built via emscripten instead of doing duplicate work. The 2026 controller shares the same behavior as the 2015 one, though you may need a bleeding edge build of SDL since they recently swapped the report layout to the BLE one in a controller firmware update.

Fair point — Claude helped summarize and connect some of the SDL issue context, including your comments on #15471. I wasn't trying to present that research as entirely my own work.

I can reword or remove the reference if you'd prefer.

The SDL/BLE report layout info is genuinely helpful though, especially since I'm mainly trying to get WebHID + Electron working cleanly with the Steam Controller first before deciding whether a Wasm/Emscripten path makes sense.