[libhid-discuss] Misunderstanding input and output paths

[Charles Lepple]

On Apr 20, 2010, at 2:50 AM, Gary Briggs wrote:

> I'm reading the sample sourcecode on the libhid page, and it tells me
> how to work out the path to access the input and output paths. That
> seems predicated on a single input and output path, but the lsusb dump
> above contains a bunch of each. Right at the end it mentions a  
> specific
> pair of endpoints [0x81, 0x01] but I'm not clear whether that actually
> has any bearing on the path as libhid would find it useful.

The sample only refers to a single input and output path, but the  
original motivation for the "path" concept was that HID devices such  
as UPSes have several items which have the same Usage, but can be  
differentiated by the HID Collections that enclose each Usage. Hence,  
you would have one path per Usage (counting the Usages implicitly  
defined by the Usage Minimum and Usage Maximum ranges), and in your  
case, roughly one path per report.

Endpoints are not tightly coupled with paths and reports. Every device  
always has an Endpoint Zero (EP0) which isn't specifically described  
in the lsusb output (this is how lsusb retrieves all of that  
information). HID devices are supposed to allow you to request reports  
over EP0, and if the libhid function does not have "interrupt" in the  
name, that's how it will do it.

libhid grabs one report at a time, and attempts to parse out the  
individual Usage results. You might want to grab a single report, and  
parse it in your own code.

Later on, you can optimize things by reading from the Interrupt In  
endpoint (less USB protocol overhead than polling EP0), or writing to  
the Interrupt Out endpoint.

> I've written some code [mainly copied outright from the libhid test
> example], here:
> http://icculus.org/~chunky/stuff/dcdcusb/main.c
>
> The output from that program is:
> http://icculus.org/~chunky/stuff/dcdcusb/set_output_report_output.txt

The only thing to note is that there is a bug in the printing routine,  
and if you see a "0x00000000" path element, it is just the 2nd or  
later element of a range. The parser knows what to do internally,  
though.

> Overall, I'm just confused as to what's going on or how to progress  
> and
> make this work. If anyone has any suggestions as to what I should do
> from here, I'd greatly appreciate it.

What are your goals? Shutting down the power supply? Monitoring  
certain parameters? If possible, I would start with something  
innocuous like changing the state of an LED, but if you can power the  
test machine from another power source, that would be best.

I won't have time to look at the Windows source code until later  
tonight at the earliest.

-- 
Charles Lepple