Hi Silvan,
> when plugging it in. Simply adding the line
>
> { 0x0738, 0x4a01, "Mad Catz FightStick TE 2", 0, XTYPE_XBOXONE },
>
> (where the two Hex values are VENDOR_ID and PRODUCT_ID) to xpad_device[]
> in xpad.c does not help either (which I naively hoped it would).
If the controller is not 100% proprietary - which I doubt, or it would hardly
work on the Xbox without special vendor support - "abusing" xpad seems
perfectly reasonable.
> I realized that the stick does not conform to the USB HID interface
> after looking more closely at the lsusb -v output (pasted below).
>
> The Fightstick seems to use a "Vendor Specific Class" and not the HID
> interface.
This may be because Xbox One controllers require a special initialisation
sequence to make them send input reports at all.
As far as I know, xpad does this for Xbox One pads, but the commands sent may
not be sufficient for the Mad Catz. This may also be the reason why it doesn't
show up as a HID device: It's possible that the device descriptor changes as
soon as initialisation is complete.
> The device is relatively simple having only about 10 buttons and a digital
> stick and the Xbox One driver for Windows works for it so xpad.c should
> be able to deal with it I assume. Worst case I would have to reverse-
> engineer the USB protocol it uses on my Window installation though I
> hope that will not be necessary given that the much more sophisticated
> Xbox One controller works on Linux already.
I think this is a good idea. Watch the initial data sent closely and compare
what xpad does in the case of a Xbox One controller.
Perhaps the logic is there already, and it just needs to be triggered?
Regards,
Gregor
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
