Re: [PATCH v4 1/2] HID: Add Support for Setting and Getting Feature Reports from hidraw

[Antonio Ospite <ospite@studenti.unina.it>]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Mon, 16 Aug 2010 16:20:58 -0400
Alan Ott <alan@signal11.us> wrote:

> Per the HID Specification, Feature reports must be sent and received on
> the Configuration endpoint (EP 0) through the Set_Report/Get_Report
> interfaces.  This patch adds two ioctls to hidraw to set and get feature
> reports to and from the device.  Modifications were made to hidraw and
> usbhid.
> 
> New hidraw ioctls:
>   HIDIOCSFEATURE - Perform a Set_Report transfer of a Feature report.
>   HIDIOCGFEATURE - Perform a Get_Report transfer of a Feature report.
> 
> Signed-off-by: Alan Ott <alan@signal11.us>
> ---

Some more testing with sixaxis and a question:

HIDIOCGFEATURE on report 0xf5 returns:
<-- 01 00 00 03 c9 87 34 fd
          ^^ a hw addr from here

with the latest six octets being a hw addr; now if I wanted to change
this, *naively*, I'd send this report with HIDIOCSFEATURE:
--> f5 01 00 66 55 44 33 22 11
    ^^ report ID _added_ in front of the whole previous buffer

but then when I get the report again to see if the operation succeeded I
get:
<-- 01 00 00 66 55 44 33 22

I can make it work if I send:
--> f5 00 66 55 44 33 22 11
    ^^ report ID _replaced_ buf[0]

then I get the expected:
<-- 01 00 66 55 44 33 22 11

Am I missing something about the differences about getting a feature
report and setting it?

In the HIDIOCGFEATURE doc I read:
	...
	The report will be returned starting at
	the first byte of the buffer (ie: the report number is not
	returned).

Someone (/me whistling, with hands in pockets) could interpret this
like a buf++ semantic on a quick read, even if this sentence means
"only" that _actual_data_ is from buf[1]; but one question stands: what
is that value returned in buf[0]? Is this unspecified?

Maybe the doc could be made even more explicit about buf[0] to overcame
non native speakers deficiencies.
And while at it, can we get rid of the ambiguity of "first byte" for
"byte 1", the former can even mean buf[0], can't it?

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 #2: Type: application/pgp-signature, Size: 198 bytes --]