[libhid-discuss] HID Usage path

[Charles Lepple]

On Jun 21, 2007, at 8:14 PM, Jorgen Lundman wrote:

> This is probably a common question by now :)  I think it would help if
> you provided the output of hid_dump_tree() in test_hid.c,

I think that's in there already:

   http://boxster.ghz.cc/projects/libhid/browser/trunk/test/ 
test_libhid.c#L93

Which version of libhid are you using?

> since "lsusb" is a Linux only command. (right?)

Right.

Actually, on OS X, you can download Apple's "HID Device Explorer"  
sample project, and combine the "Usage" from the top panel with the  
one from the bottom panel (selected from a dropdown menu).

   http://developer.apple.com/samplecode/HID_Explorer/index.html

For instance, my mouse says "Usage: Generic Desktop Mouse (0x1, 0x2)"  
and "Usage: Button #1 (0x9,0x1)".

That should translate to a "usage path" of { 0x00010002, 0x00090001 }.

> Anyway, when dumping the device I am interested in, I get:

Does it dump the raw descriptor bytes at all?

> Now, test_hid.c seems to imply it should be of length 3, not 2. But
> someone else on this list showed using just 2. Another email said to
> ignore those ending with 0000's. Except all my 0x80 and 0x90 end in  
> 0000's.

The length depends on how many nested elements are in the HID report  
descriptor. Three is more common, but it might be shorter.

The HID parser has problems with array elements (it adds extra  
entries ending in 0000), but it's possible that the first element  
truly does end in 0.

This may all be moot if the device only has one report - the usage  
paths are only to distinguish between multiple reports, and to choose  
the proper report ID.

Bear in mind that libhid was originally targeted at USB UPSes, where  
the PDC (Power Device Class) specification requires devices to have  
several levels of nested elements, corresponding to PATHLEN of at  
least 3 or 4. I can't remember how many report IDs that translates  
into, but it's way more than one or two.

> Am I right to use:
>
> #define PATHLEN 2
>    int const PATH_IN[PATHLEN] = { 0x000b0001, 0x00000000 };
>    int const PATH_OUT[PATHLEN] = { 0x000b0001, 0x00000000 };

If it works...

>
> Sending the 6 test bytes at least say:
>
>    TRACE: hid_set_output_report(): sending report ID 0x00 (length:  
> 6) to
> USB device 005/007-6993-b001-00-00[0]...
>   NOTICE: hid_set_output_report(): successfully sent report to USB
> device 005/007-6993-b001-00-00[0].

I think report ID 0 is reserved. If there is only one report ID, then  
the report ID shouldn't be sent. So you might be sending too many  
bytes (depending on which version of the code this is).

> Finally, is this something static and specific to a device? Can I  
> safely
> embed this value in my sources, or am I supposed to scan for it each
> time as it is dynamic?

It should be static, but firmware developers might end up changing it  
in a future revision (depending on how they expect desktop developers  
to access the device).

> Good news is that libhid appears to run rather well on OsX. Even  
> though
> I do get some warnings about untested code. That it manages to  
> claim the
> device is much further than I got with libusb.

The key on OS X is to make sure that nothing else might want to claim  
the device at the same time.

-- 
Charles Lepple