[libhid-discuss] Multiple duplicate interfaces?

[Charles Lepple]

On Oct 2, 2010, at 5:41 PM, Frank Rizzo wrote:

>> If you detach it from the OS, you will have to handle all of the  
>> HID keyboard transactions. libhid doesn't do any of that for you.
>
> I'm sure it's obvious by now, but this is my first foray into USB  
> programming, so I'm not sure what you mean.  I want to be the  
> receiver of the barcode data that comes in from the scanner as a  
> string of bytes, terminated by a <CR>.  Currently, whatever program  
> has the "input focus" (for lack of a better term), gets this input.   
> I want to stop that.  It is my belief that the keyboard is mostly a  
> "transmit-only" device, with the exceptions being the commands to  
> toggle the LEDs.
> Is this an incorrect assumption?

Mostly correct, except that the string of bytes will be keyboard  
scancodes, and there is a separate array for things like Shift and  
Control.

There are a number of things that the OS will do to set up a HID  
device, including setting the idle interval. This is covered here:

http://www.usb.org/developers/devclass_docs/HID1_11.pdf

You won't need to worry about the report parsing - for your  
application, it's basically a one-time thing that has mostly been done  
from the output of lsusb. Be on the lookout for the "Boot Protocol"  
portion of the keyboard description - it's a little simpler, but it's  
still like interfacing with the raw scancode information from a PS/2  
keyboard.

>> Right. There is a comment about 3/4th of the way through http://svn.debian.org/wsvn/libhid/trunk/test/test_libhid.c 
>>  that explains how to find the path from lsusb output.
>
> OK, and I am ASSUMING that the correct path for this device is  
> 0x00010006, 0x00070000 because I have this:
>
> Item(Global): Usage Page, data= [ 0x01 ] 1
> Item(Local ): Usage, data= [ 0x06 ] 6
> [...]
> Item(Global): Usage Page, data= [ 0x07 ] 7
>                           Keyboard
> Item(Local ): Usage Minimum, data= [ 0x00 ] 0
>                           No Event
> Item(Local ): Usage Maximum, data= [ 0xff 0x00 ] 255
>                           (null)
> Item(Main  ): Input, data= [ 0x00 ] 0
>
>
> Does this seem sane?  (If not, you have my lsusb dump back a couple  
> of messages ago, could you throw me a pointer?)

That's the path for keyboard scancode 0. (The bug in libhid for  
printing ranges of Usage IDs has something to do with the fact that it  
wasn't written with that aspect of HID in mind.)

Basically, you would need one path for each scancode, which  
corresponds to a key location on an actual keyboard. You might be able  
to get away without tracking the state of the shift keys, if you are  
just looking for alphanumeric values. Either way, it's pretty  
cumbersome with the current libhid API.

You might want to look at hid_interrupt_read(), which gives you the  
raw packet sent back over the interrupt pipe: http://libhid.alioth.debian.org/doc/hid__exchange_8c.html#41152a3e3d6c52a2aa3d7353463dc45b

Another option, which might make things easier in the end, is to use  
usbsnoop to record the transactions for a given scan, and use the  
usbsnoop2libusb script to see what's going on. I only know the  
theoretical side of USB keyboards, so I haven't had to work through  
all of the implementation details of whether the device is sending  
keystrokes over the interrupt pipe, or if you need to fetch them via  
control transfers (less likely).