Re: [PATCH v3] Input: xpad - add support for Beitong KP series controllers

Hi VegetablCat,

Thank you for covering the wider KP device family. My patches overlap
with yours but use a different request to keep the controllers in XInput
mode.

Instead of requesting the Microsoft OS Extended Compat ID directly, my
patch sends the standard USB GET_DESCRIPTOR request for the Microsoft OS
string descriptor at index 0xee during probe.

In the Microsoft OS 1.0 sequence, Windows first requests this string
descriptor, which supplies the vendor code for the subsequent Extended
Compat ID request that returns XUSB10. Your patch issues the second
request directly with bRequest set to 0xee.

In my testing on 20bc:5158 and 20bc:5159, the initial string-descriptor
request alone is sufficient to keep the controller in Xbox 360 mode; a
subsequent Extended Compat ID request is not required on these two
devices. The 5158 device additionally needs a keepalive quirk to prevent
it from resetting when its interrupt-IN endpoint is idle.

Could we use the Microsoft OS string-descriptor request as the common
mechanism while retaining your device coverage and attribution? This
follows the protocol sequence and avoids assuming a fixed vendor code.

For the separate 20dd devices, I suggest using HID_QUIRK_ALWAYS_POLL
instead of registering a HID driver from xpad. I verified this on
20dd:5159; 20dd:515c still needs testing.

Could you test the string-descriptor request on the other KP devices? If
it works, we can consolidate the overlapping submissions and preserve
your device coverage and attribution.

[1] https://lore.kernel.org/linux-input/[email protected]/
[2] https://lore.kernel.org/linux-input/[email protected]/

Thanks,
Aaron