From c75f39fd8ebd1f1e48ec38a354fc289935ad016c Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Mon, 29 Jun 2026 13:44:37 +0000 Subject: [PATCH] =?UTF-8?q?docs(steam):=20VALIDATED=20=E2=80=94=20virtual?= =?UTF-8?q?=20DualSense=20IS=20Steam-Input=20recognized;=20isolates=20the?= =?UTF-8?q?=20Deck=20wall=20to=20interface=202?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Definitive hardware test (Bazzite running Steam): a virtual DualSense (UHID, 054c:0ce6, Interface: -1) is FULLY promoted by Steam — controller.txt logs "Local Device Found 054c 0ce6 DualSense Wireless Controller", then "Controller using HIDAPI driver vid=0x054c pid=0x0ce6" and loads configset_controller_ps5.vdf (our calibration/pairing/firmware feature blobs read back). The SAME Interface: -1 that the Deck is rejected at is accepted for the DualSense. So the wall is specifically the Deck's MULTI-INTERFACE requirement (Steam must pick interface 2 among kbd/mouse/controller), NOT a UHID limitation. The DualSense path delivers real Steam Input (gyro + touchpad + glyphs + bindings) for a streamed Deck/SC client; it loses only Deck glyphs, the 2nd trackpad, and the 4 back grips as distinct Steam-Input paddles (M5 folds them to buttons). Full Deck-identity Steam Input would need interface 2 -> a USB gadget (dummy_hcd + configfs HID, controller on interface 2). Feasible but heavy/non-portable: dummy_hcd isn't built on Bazzite/Deck/dev-box, so it'd be a per-kernel build + (on immutable SteamOS/Bazzite) a package-layer + reboot per host. Doc-only (design §11). Not pushed. Co-Authored-By: Claude Opus 4.8 (1M context) --- design/steam-controller-deck-support.md | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/design/steam-controller-deck-support.md b/design/steam-controller-deck-support.md index dd5b7b6..cea6a0a 100644 --- a/design/steam-controller-deck-support.md +++ b/design/steam-controller-deck-support.md @@ -693,10 +693,24 @@ configfs) or a kernel USB bus driver — a much larger, less portable lift, and - **The virtual Deck's real value is non-Steam / SDL games on Linux** (emulators, native SDL titles, anything reading the kernel evdev or SDL's HIDAPI Steam driver) — there it delivers grips + trackpads + gyro. It does **not** deliver Steam Input glyphs/bindings. -- **For Steam-Input hosts, the virtual DualSense is the right path** on every platform: Steam *does* - recognize a single-interface DualSense (it needs no interface filtering), giving the client gyro + - a touchpad through Steam Input; the M5 paddle-fold carries the back grips onto standard buttons. - This is why the M6 conflict gate degrades to DualSense, and why `Auto` already prefers it. +- **For Steam-Input hosts, the virtual DualSense is the right path — HARDWARE-VALIDATED (2026-06-29).** + A virtual DualSense (UHID, also `Interface: -1`) run on Bazzite while Steam ran was **fully + promoted**: `controller.txt` logged `Local Device Found type 054c 0ce6 "DualSense Wireless + Controller"`, then **`Controller using HIDAPI driver, vid=0x054c, pid=0x0ce6`** and **loaded + `configset_controller_ps5.vdf`** (it even read back our calibration/pairing/firmware feature blobs). + So the *same* interface `-1` that the Deck is rejected at is **accepted for the DualSense** — proof + the wall is specifically the Deck's multi-interface / interface-2 requirement, *not* a UHID + limitation. The DualSense path therefore delivers **real Steam Input** (gyro + touchpad + glyphs + + bindings) for a streamed Deck/SC client; the M5 paddle-fold carries the back grips onto standard + buttons. This is why the M6 conflict gate degrades to DualSense and `Auto` prefers it. **What the + DualSense identity loses vs a real Deck:** Deck glyphs, the *second* trackpad, and the 4 back grips + as distinct Steam-Input-bindable paddles (they fold to face/shoulder/stick buttons instead). +- **Full Deck-identity Steam Input would need interface 2 → a USB gadget (`dummy_hcd` + configfs HID + functions presenting kbd/mouse/controller, controller on interface 2).** Feasible in principle (it + gives real interface numbers), but heavy and less portable: `dummy_hcd` is not built on Bazzite, the + Deck, or the dev box, so it would have to be built/loaded per-kernel on every Steam host — and an + immutable SteamOS/Bazzite host makes that a package-layer + reboot. The marginal gain over the + validated DualSense path is Deck glyphs + the 2nd trackpad + native back-paddle bindings. - **M7 (a Windows UMDF virtual Steam Deck) is NOT recommended.** Windows Steam applies the same interface filter, and Windows has **no kernel-`hid-steam` evdev fallback** — Windows games consume XInput / RawInput / Windows.Gaming.Input, none of which a non-promoted virtual Deck feeds. So a