Xpad Driver Replacement

Xpad Driver Replacement

[Zachary Lund]

I created a new driver to hopefully eventually replace xpad. The driver 
in its current form can be found on github. Things it provides is 
cleaner module unload/load, possibly cleaner/more efficient code, and 
better LED support. There are caveats that I'd like to iron out before I 
submit a patch though.

For one, I do not have the original Xbox controller. I've only tested 
the official Xbox 360 Wired and Wireless controllers. So support for 
that is unfortunately missing. I'm not sure how I feel about ripping it 
out of xpad. What am I supposed to do about devices that I don't own?

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.

Thirdly, I have had no other testers outside of myself. And the only 
products I've tested are the only items in the device_id list. So, if 
anyone can test, that would amazing. I've posted on several forums and 
IRC channels for help testing or new products with unfortunately zero 
results. Anyone who is able to test and just use it extensively, that 
would be much appreciated.

The code in its current form is found on github: 
https://github.com/computerquip/xpad360wr

Any advice or feedback would be much appreciated.

Re: Xpad Driver Replacement

[David Herrmann]

Hi

On Sun, Dec 8, 2013 at 7:18 AM, Zachary Lund <admin@computerquip.com> wrote:
> I created a new driver to hopefully eventually replace xpad. The driver in
> its current form can be found on github. Things it provides is cleaner
> module unload/load, possibly cleaner/more efficient code, and better LED
> support. There are caveats that I'd like to iron out before I submit a patch
> though.

Please submit the patch right away. No-one minds commenting on
preliminary ideas. On the contrary, we can tell you whether the basic
idea makes sense right from the beginning.

> For one, I do not have the original Xbox controller. I've only tested the
> official Xbox 360 Wired and Wireless controllers. So support for that is
> unfortunately missing. I'm not sure how I feel about ripping it out of xpad.
> What am I supposed to do about devices that I don't own?

The old controllers are incompatible with the 360, so I'd keep the old
driver around with only the old VID/PID combinations. Btw., if you
live in the US, you can order one used from amazon for <10$.
Unfortunately, they only ship to the US so I haven't gotten my hands
on one of these.. Maybe you can find someone else if you don't
can/want to buy it?

> 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.
>
> Thirdly, I have had no other testers outside of myself. And the only
> products I've tested are the only items in the device_id list. So, if anyone
> can test, that would amazing. I've posted on several forums and IRC channels
> for help testing or new products with unfortunately zero results. Anyone who
> is able to test and just use it extensively, that would be much appreciated.
>
> The code in its current form is found on github:
> https://github.com/computerquip/xpad360wr
>
> Any advice or feedback would be much appreciated.

Please post it to the list, there's a bunch of stuff that needs to be
changed. And please turn it into an HID driver. You don't need to use
HID reports at all! The hid-wiimote driver for instance just uses raw
I/O on HID without dealing with HID report descriptors at all (just
like hidraw).

For raw HID drivers, you simply use the ->raw_event callback to parse
incoming data and dev->output_raw_report() to send raw data.

Thanks for the work! I will gladly test it with the 360 controller
once you send a proper upstream patch.

Thanks
David

Re: Xpad Driver Replacement

[Zachary Lund]

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?

Re: Xpad Driver Replacement

[Ken Phillis Jr]

On Mon, Dec 9, 2013 at 9:27 PM, Zachary Lund <admin@computerquip.com> 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

Re: Xpad Driver Replacement

[David Herrmann]

Hi

On Tue, Dec 10, 2013 at 4:27 AM, Zachary Lund <admin@computerquip.com> 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?

Try adding it to:
  static const struct usb_device_id hid_usb_ids[]
in drivers/hid/usb-hid/hid-core.c
You should provide a fairly narrow match-line, though. You don't want
to match on all vendor-specific-class devices.

Cheers
David