[rfc] xbox360 Big-button controller support for xpad.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, all,

The attached (RFC!) patch adds support for the xbox 360 big-button
controllers to xpad.c.  These seem to be a set of four large CIR
remote controls, with a USB receiver that speaks a modified version of
the normal xbox360 usb remote protocol.

http://en.wikipedia.org/wiki/Xbox_360_accessories#Big_Button_Pad has a
decent image.  You can get a set for about 12GBP, including a game
disk for Scene It (which I haven't even removed the shrink-wrap for,
since I don't actually own a 360).  The reverse-engeneering work is
original here, but it's not terribly complicated -- each input packet
is the constant bytes 0x00 05, followed by a single byte controller
number (0..3), and the button status in two bytes.

There are, however, a few complications that I'd like advice on:

1. Like most CIR sorts of thing, it never gives an all-buttons-off
report, and will give multiple reports for the same combinations of
buttons.

The buttons are all non-overlaping bitmaps, and I see no reason,
other then the physical impossibility of pressing the left and right
buttons at the same time without removing parts of the controller, for
multiple button-presses not to work.

That means that a naive implementation will never generate key-up
events.  Currently, each of the native repeats generates a key down
followed by a key-up, which isn't really ideal either.  Ideally, it'd
create a key-down when the first report happens, and then create a
key-up when a report with a different set comes in, or the next
expected repeat fails to happen.

I did find some code that I could copy-and-paste to implement that in
drivers/input/misc/winbond-cir.c - wbcir_keyup, but it feels to me
like it should be somewhere generic / libraryish.  Is it there,
somewhere I couldn't find it, or should I just copy-and-paste?

2. Another niggle is that the current code simply ignores the "which
controller is this report for" field, so userspace can't tell which of
the four controllers is pressing the button.

This rather mucks up both the origional point, and my use-case, where
each controller (which is a different colour so you can tell them
apart) belongs to a different user.  The right way to do that is to
present them to the input layer as four different devices each of
which has the same set of buttons, but that'd require, I think, some
fairly large changes to the xpad.c infrastructure.

Does the wisdom of the list think I should just abandon xpad.c, and
split this off into it's own driver?  I'm not sure how well that'd
mesh with the way detection is done, but then again, I'm not really
sure how detection is done generally.

  Thank you for your advice,
  -=- James Mastros

Attachment: xbox360bb-1.diff
Description: Binary data


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux