From: Brian Magnuson <bdmagnuson@gmail.com>
To: Jan Kratochvil <honza@jikos.cz>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
linux-input@atrey.karlin.mff.cuni.cz
Subject: Re: [PATCH 3/4] xpad.c - support for xbox360 wireless receiver
Date: Sun, 3 Jun 2007 11:37:23 -0400 [thread overview]
Message-ID: <20070603153723.GA14913@rcn.com> (raw)
In-Reply-To: <alpine.LRH.0.98.0706031601390.22353@twin.jikos.cz>
* 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
next prev parent reply other threads:[~2007-06-03 15:37 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-03 14:10 [PATCH 3/4] xpad.c - support for xbox360 wireless receiver Jan Kratochvil
2007-06-03 15:37 ` Brian Magnuson [this message]
2007-06-03 15:53 ` Brian Magnuson
2007-06-03 16:23 ` Jan Kratochvil
[not found] ` <bafd4ab0706031003n23c30e1ah3fdf82bf0e586aa8@mail.gmail.com>
2007-06-03 17:03 ` Fwd: " Brian Magnuson
2007-06-03 17:54 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070603153723.GA14913@rcn.com \
--to=bdmagnuson@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=honza@jikos.cz \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.