Greetings, It made it onto the list the first time. In general maintainers of all sorts prefer having patches PASTED into the email and then getting questions. The mailinglist cleans out attached files so pasting is really the only way to get a allround review. So, please resend with patch pasted into email text. Best wishes Kristoffer Ericson On Sat, 31 Oct 2009 12:01:33 +0000 James Mastros <james@xxxxxxxxxxx> wrote: > [This doesn't appear to have made it to the list the first time I sent > it, so I'm resending. My appologies if you recieve it more then > once.] > > 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Kristoffer Ericson <kristoffer.ericson@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
