docs(steam): VALIDATED — virtual DualSense IS Steam-Input recognized; isolates the Deck wall to interface 2

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) <noreply@anthropic.com>

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