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).
_______________________________________________
libhid-discuss mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
http://libhid.alioth.debian.org/
