On 11/14/21 13:51, Benjamin Valentin wrote:
> On Sat, 13 Nov 2021 19:34:54 -0600
> Cameron Gutman <aicommander@xxxxxxxxx> wrote:
>
>> For 1, the way Windows does it is via the Microsoft OS descriptor [0].
>> AFAIK, the specific OS descriptor strings are "XUSB20" for Xbox 360
>> and "XGIP10" for Xbox One.
>>
>> That functionality is handled by xpad_table[] and the
>> bInterfaceProtocol detection logic in xpad_probe(). The xpad_device[]
>> entry isn't required for detection or functionality of devices,
>> unless those devices need special treatment like
>> MAP_TRIGGERS_TO_BUTTONS or something.
>
> The problem is that the gamepad then gets assigned the type
> XTYPE_UNKNOWN which excludes it from all run-time code path switches.
>
> E.g. if I comment out
>
> // { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
>
> my X-Box 360 pad will not only lose any LED or rumble support, it will
> also not report any input events with jstest because
> xpad360_process_packet() is no longer called.
>
XTYPE_UNKNOWN is a special value that should always be overridden by
the check in xpad_probe() to be the proper XTYPE value at runtime:
if (xpad->xtype == XTYPE_UNKNOWN) {
if (intf->cur_altsetting->desc.bInterfaceClass == USB_CLASS_VENDOR_SPEC) {
if (intf->cur_altsetting->desc.bInterfaceProtocol == 129)
xpad->xtype = XTYPE_XBOX360W;
else if (intf->cur_altsetting->desc.bInterfaceProtocol == 208)
xpad->xtype = XTYPE_XBOXONE;
else
xpad->xtype = XTYPE_XBOX360;
} else {
xpad->xtype = XTYPE_XBOX;
}
...
Those values should definitely be correct, because they're what we
use in the xpad_table[] itself. If they don't match, xpad_probe()
won't get called at all.
Can you see what's going on in xpad_probe() when you comment out
that line for your gamepad?
> I'll try to check on how to read out the OS descriptor string, maybe
> that allows us to detect the type on init and provide a better default
> experience.
That type derivation code above already handles determining the type for
unknown gamepads (assuming it actually works). The problem is having to
maintain the xpad_table[] list with every vendor that produces an Xbox
gamepad. That's where an extension to usb_device_id and something like
a USB_MS_OS_DESCRIPTOR("XUSB20") macro would come in, if the USB core
had first-class support for Microsoft OS descriptors.
The problem is that adding that Microsoft OS descriptor query may cause
compatibility issues for other devices. Windows actually keeps track of
whether the OS descriptor query fails to avoid querying it again [0].
[0]: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors
>
> Best,
> Benjamin
>
Regards,
Cameron
