[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
