Re: hidp_output_raw_report, HID_OUTPUT_REPORT and Sixaxis

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

 



On Tue, 30 Nov 2010 18:40:03 +0100
"pascal@xxxxxxxx" <pascal@xxxxxxxx> wrote:

Pascal, you were replying to linux-input only so some of the original
recipients missed your comments.

> 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.
>

OK, I managed to study [1] a little bit, so yes, I also think my patch
is acceptable right now, but just because as you note in another
message hidp_output_raw_report() is relying only on the control channel.
In section 7.9.1 there's no mention of DATA for Output reports on the
Control channel (see also Figure 11: SET_ Flow Chart).

So I am resending it, it shouldn't hurt.

> 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.
> 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.
>

However, even if my patch gets is, Output reports on the Sixaxis will
stop working again as soon as someone implements the behavior you are
suggesting, that is:
  Feature Report -> SET_REPORT on the Control channel
  Output Report  -> DATA on the Interrupt channel

So I am going to submit the hidp_output_raw_report() override in
hid-sony.c as well, does this sound OK?

> 
> [1] http://www.bluetooth.com/Specification%20Documents/HID_SPEC_V10.pdf
> 

Regards,
  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: pgpUdPnEsxxfk.pgp
Description: PGP signature


[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