On Tue, 30 Nov 2010 18:40:03 +0100 "pascal@xxxxxxxx" <pascal@xxxxxxxx> wrote: > Antonio Ospite wrote: > > +++ b/net/bluetooth/hidp/core.c > > case HID_OUTPUT_REPORT: > > - report_type = HIDP_TRANS_DATA | HIDP_DATA_RTYPE_OUPUT; > > + report_type = HIDP_TRANS_SET_REPORT | HIDP_DATA_RTYPE_OUPUT; > > > Is it only the Sixaxis which needs the output report as a SET_REPORT > > operation, or the change above is an actual fix? > > My understanding of the Bluetooth HID Profile specification [1], > section 7.4.9, is that on the control channel DATA is only for > responding to an incoming GET_REPORT. Since Linux is the HID > Host, it will probably never need to reply to a GET_REPORT. > So your patch looks good. > Hi Pascal, I'll check with the specification you pointed at, and try to come up with a meaningful commit message then. > Note that usbhid_output_raw_report() seems to send OUTPUT > reports as USB interrupt messages and FEATURE reports as > USB SET_REPORT control messages, which makes sense too. Well, but that does not work for sixaxis, it only accepts output reports on the control endpoint, look at a recent hid-sony.c overriding usbhid_output_raw_report(). > It would be nice if hidraw behaved the same over USB and > over Bluetooth. Unfortunately I don't think you can drive > the sixaxis leds with DATA on the Bluetooth interrupt channel. > The non-standard USB behavior made me think that the patch proposed could not be an actual fix but another non-standard sixaxis quirk; as I said, I'll need to check this assumption against the document in [1]. > Pascal > > [1] http://www.bluetooth.com/Specification%20Documents/HID_SPEC_V10.pdf > Thanks, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?
Attachment:
pgpUWLrCXHcBg.pgp
Description: PGP signature
