[PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Jan Kratochvil]

Hi,
   this one is tricky because I can't test it.
Brian, there is something I don't understand in your previous patch concerning 
this issue. What is reported data length for wireless receiver when it is sending 
its status report? I thought you are trying to ignore packets about headset 
connection. But it is not working the same way for wired device. In data[1] is 
actual length of packet (20).
Please test this patch (and the previous 2).
Thanks

Author: Brian Magnuson <bdmagnuson@gmail.com>

Device ids for xbox360 wireless receiver.

Signed-off-by: Jan Kratochvil <honza@jikos.cz>
---
  drivers/input/joystick/xpad.c |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 15f9877..1651950 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -137,6 +137,7 @@ static const struct xpad_device {
  	{ 0x12ab, 0x8809, "Xbox DDR dancepad", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
  	{ 0x1430, 0x8888, "TX6500+ Dance Pad (first generation)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX },
  	{ 0x045e, 0x028e, "Microsoft X-Box 360 pad", MAP_DPAD_TO_AXES, XTYPE_XBOX360 },
+	{ 0x045e, 0x0719, "Microsoft X-Box 360 wireless receiver", MAP_DPAD_TO_AXES, XTYPE_XBOX360 },
  	{ 0xffff, 0xffff, "Chinese-made Xbox Controller", MAP_DPAD_TO_AXES, XTYPE_XBOX },
  	{ 0x0000, 0x0000, "Generic X-Box pad", MAP_DPAD_UNKNOWN, XTYPE_XBOX }
  };
@@ -179,6 +180,7 @@ static const signed short xpad_abs_pad[]
  static struct usb_device_id xpad_table [] = {
  	{ USB_INTERFACE_INFO('X', 'B', 0) },	/* X-Box USB-IF not approved class */
  	{ USB_DEVICE_INTERFACE_PROTOCOL(0x045e, 0x028e, 1) },	/* X-Box 360 controller */
+	{ USB_DEVICE_INTERFACE_PROTOCOL(0x045e, 0x0719, 129) },	/* X-Box 360 wireless receiver */
  	{ }
  };

-- 
1.4.3.4

Re: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Brian Magnuson]

* Jan Kratochvil <honza@jikos.cz> [2007-06-03 11:18]:
> Hi,
>   this one is tricky because I can't test it.
> Brian, there is something I don't understand in your previous patch 
> concerning this issue. What is reported data length for wireless receiver 
> when it is sending its status report? I thought you are trying to ignore 
> packets about headset connection. But it is not working the same way for 
> wired device. In data[1] is actual length of packet (20).
> Please test this patch (and the previous 2).
> Thanks

I can tell you without even testing that it's not going to work.  The data
length returned by the wireless controller is alway 29 bytes, but as far
as I can tell there is no field that indicates that length.

However, there is a bit returned that seems to indicate whether the pad
state is valid or not which is what I was testing.  Here's the relevant bit
from my patch.

static void xpad360w_process_packet(struct usb_xpad *xpad, u16 cmd,
unsigned char *data)
{
	struct input_dev *dev = xpad->dev;
	/* Valid pad data */
	if(!(data[1] & 0x1))
		return;
	
	xpad360_process_packet(xpad, cmd, &data[4]);
}

You see that I'm not checking a length here but a particualar bit.   Also,
when I had off to the original xbox360_process_packet I shift the data over by
four bytes.  This is why I made it a seperate function in the first place
since I envioned that something more might happen as the meaning of these
first four bytes becomes more decoded.  The bits that I had figured out
were explanied in the comments preceeding xpad360w_process_packet.

I'll go ahead and test these later but in the meantime [1/4] and [3/4] look
fine but [2/4] will break wireless controllers.

-Brian

Re: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Brian Magnuson]

* Brian Magnuson <bdmagnuson@gmail.com> [2007-06-03 11:37]:
> * Jan Kratochvil <honza@jikos.cz> [2007-06-03 11:18]:
> > Hi,
> >   this one is tricky because I can't test it.
> > Brian, there is something I don't understand in your previous patch 
> > concerning this issue. What is reported data length for wireless receiver 
> > when it is sending its status report? I thought you are trying to ignore 
> > packets about headset connection. But it is not working the same way for 
> > wired device. In data[1] is actual length of packet (20).
> > Please test this patch (and the previous 2).
> > Thanks
> 
> I can tell you without even testing that it's not going to work.  The data
> length returned by the wireless controller is alway 29 bytes, but as far
> as I can tell there is no field that indicates that length.

Ok, looks like I was a bit hasty.  Looking at the data again there does
appear to be a length field in the returned data however.

1) It's 19 bytes rather than 20.  This is a internel data format length
though.  The USB data returned is still 29 bytes long.
2) You still need to apply to four byte shift for it to be in the "right"
place.

-Brian

Re: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Jan Kratochvil]

Hello,

On Sun, 3 Jun 2007, Brian Magnuson wrote:
> * Brian Magnuson <bdmagnuson@gmail.com> [2007-06-03 11:37]:
>> I can tell you without even testing that it's not going to work.  The data
>> length returned by the wireless controller is alway 29 bytes, but as far
>> as I can tell there is no field that indicates that length.
>
> Ok, looks like I was a bit hasty.  Looking at the data again there does
> appear to be a length field in the returned data however.
>
> 1) It's 19 bytes rather than 20.  This is a internel data format length
> though.  The USB data returned is still 29 bytes long.
> 2) You still need to apply to four byte shift for it to be in the "right"
> place.

Oic. I somehow missed the shift. Sorry for that. So in your process packet 
function you got 19 on position 5? And what is on last five bytes? I 
suppose that the rest is the same as in wired controller.

Thanks Jan

Fwd: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Brian Magnuson]

[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]

Accidentally dropped the cc:

---------- Forwarded message ----------
From: Brian Magnuson <bdmagnuson@gmail.com>
Date: Jun 3, 2007 1:03 PM
Subject: Re: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver
To: Jan Kratochvil <honza@jikos.cz>


On 6/3/07, Jan Kratochvil <honza@jikos.cz> wrote:
>
> Hello,
>
> On Sun, 3 Jun 2007, Brian Magnuson wrote:
> > * Brian Magnuson <bdmagnuson@gmail.com> [2007-06-03 11:37]:
> >> I can tell you without even testing that it's not going to work.  The
> data
> >> length returned by the wireless controller is alway 29 bytes, but as
> far
> >> as I can tell there is no field that indicates that length.
> >
> > Ok, looks like I was a bit hasty.  Looking at the data again there does
> > appear to be a length field in the returned data however.
> >
> > 1) It's 19 bytes rather than 20.  This is a internel data format length
> > though.  The USB data returned is still 29 bytes long.
> > 2) You still need to apply to four byte shift for it to be in the
> "right"
> > place.
>
> Oic. I somehow missed the shift. Sorry for that. So in your process packet
> function you got 19 on position 5?


Yup.

And what is on last five bytes? I
> suppose that the rest is the same as in wired controller.


I'm not someplace where I can check for sure right now, but it didn't seem
to
be useful data.  Might have even been all 0s.  I'll be able to check on that
later tonight.

-Brian

[-- Attachment #2: Type: text/html, Size: 2439 bytes --]

Re: Fwd: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver

[Jan Kratochvil]

On Sun, 3 Jun 2007, Brian Magnuson wrote:
>> Hello,
>> 
>> On Sun, 3 Jun 2007, Brian Magnuson wrote:
>> > * Brian Magnuson <bdmagnuson@gmail.com> [2007-06-03 11:37]:
>> >> I can tell you without even testing that it's not going to work.  The
>> data
>> >> length returned by the wireless controller is alway 29 bytes, but as
>> far
>> >> as I can tell there is no field that indicates that length.
>> >
>> > Ok, looks like I was a bit hasty.  Looking at the data again there does
>> > appear to be a length field in the returned data however.
>> >
>> > 1) It's 19 bytes rather than 20.  This is a internel data format length
>> > though.  The USB data returned is still 29 bytes long.
>> > 2) You still need to apply to four byte shift for it to be in the
>> "right"
>> > place.
>> 
>> Oic. I somehow missed the shift. Sorry for that. So in your process packet
>> function you got 19 on position 5?
>
>
> Yup.

Ok. So if we'll change the [PATCH 2/4] to have
 	if (data[1] < 14)
 		return;
You will be probably happy, right?

And because of the four bytes shift I suppose to drop this (3/4) patch and 
use yours instead. If you wan't add
Signed-off-by: Jan Kratochvil <honza@jikos.cz>
to your patch.

Jan

>
> And what is on last five bytes? I
>> suppose that the rest is the same as in wired controller.
>
>
> I'm not someplace where I can check for sure right now, but it didn't seem
> to
> be useful data.  Might have even been all 0s.  I'll be able to check on that
> later tonight.
>
> -Brian
>