On Mon, Dec 9, 2013 at 9:27 PM, Zachary Lund <[email protected]> wrote: > > > On 12/08/13 00:18, Zachary Lund wrote: >> >> Secondly, the Xbox 360 controllers claim to be HID compliant... this is not >> an HID driver. That's because the report descriptor is missing and I, >> unfortunately, do not know what to do about that. Some drivers like XBCD and >> the driver found at tattiebogle.net both provide their own report descriptor >> and work from there. While I'd like to do the same eventually, it will take >> me longer than a week to do that as I'd have to educate myself on HID and >> figure out what to do about the missing descriptors. > > I've run into an instant road block. The controller claims bInterfaceClass to > be 0xFF (Vendor-specific) so usbhid won't probe it. I didn't think it would > be so difficult to work around that but I've spent the better part of today > trying to figure out just that. usbhid is a usb_driver that has only one > requirement to be probed: bInterfaceClass be 0x03. Unfortunately, the device > fails this requirement. > > Does anyone know of a way around this mechanism? Or perhaps I should take a > different approach? >
I agree that the XBOX 360 controller support should appear as a separate driver. However the approach for detecting this should instead rely on what microsoft has described as the "Xbox 360 Common Controller class" (XUSB) [1]. The documentation surround the XINPUT covers Audio and Joystick input. However I believe it is possible to just cover the joystick input types ( and sub-controller types ) [2] without overdoing the driver. [1] MSDN Reference - DirectInput and XUSB http://msdn.microsoft.com/en-us/library/windows/desktop/hh405052%28v=vs.85%29.aspx [2] MSDN Reference - XINPUT and sub-controller types. http://msdn.microsoft.com/en-us/library/windows/desktop/hh405050%28v=vs.85%29.aspx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
