forked from unom/punktfunk
enricobuehler
00c29f82f2
A Steam Deck client streaming to a Windows host had a stuck stick and a stuck d-pad. The virtual pad was enumerating with the DualSense VID/PID **and the DualSense report descriptor**, so Windows parsed the 64-byte Deck frame as DualSense report 0x01: LX = report[1] = 0x00 (stick hard left), LY = report[2] = 0x09 (hard up), and a d-pad hat of 0 — which is UP, held forever. The driver picked its identity from `device_type` in the sealed section, but hidclass asks for the descriptors and attributes while it STARTS the device, and the section can only be delivered over the HID device interface — which does not exist until those queries are answered. The channel was structurally unavailable at the only moment it was needed, so `device_type()`'s bounded wait always timed out and every identity fell back to DualSense. Not a race: DualShock 4 and the Edge enumerated as DualSenses too (verified on .173 — both report 054C:0CE6 with a 64-byte DualSense input report, while their on-demand strings read correctly). The devnode's own hardware ids carry the identity and are readable at EvtDeviceAdd, before anything is asked, so resolve it there. The section stays authoritative once attached; the old wait survives only for a devnode whose ids match nothing. `hwid_devtype_table_matches_the_driver` pins the host's hwid → device_type mapping against the driver's table, including the ordering trap that `pf_dualsense` is a prefix of `pf_dualsenseedge`.