On Tue, 30 Nov 2010 18:40:03 +0100
"pascal@pabr.org" [off-list ref] wrote:

Antonio Ospite wrote:

quoted

+++ 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;

quoted

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?