[libhid-discuss] usb_control_msg

[Charles Lepple]

On Jun 26, 2007, at 8:47 PM, Jorgen Lundman wrote:

> Better yet would be to have HID
> API calls that uses the OS underlying API, even if that is just libusb
> on Unix.

This is almost enough to warrant writing a FAQ :-)

http://lists.alioth.debian.org/pipermail/libhid-discuss/2007-April/ 
000119.html

> kextload: extension /System/Library/Extensions/usbb2k.kext is  
> authentic
> kextload: extension /System/Library/Extensions/usbb2k.kext/ has no
> executable
> kextload: loading personalities for extension
> /System/Library/Extensions/usbb2k.kext
> kextload: loading personalities named:
> kextload:     B2K
> kextload: sending 1 personality to the kernel
> kextload: matching started for /System/Library/Extensions/usbb2k.kext/

interesting... and you said the next time you plugged it in, it  
didn't register?

> I skimmed it, and saw calls to things like HIDGetItemValue() and got
> excited, but checking it again, it seems that was just what you called
> your functions, which in turn call usb_get_report().

Yes, the MGE hidparser code does use camelcase identifiers like  
HIDGetItemValue().

> (What are the
> set/get report calls? Any chance I can use them to talk to the device?
> Or presumably they need endpoints enumerated too)

They use the control endpoint. Some devices only respond to interrupt  
endpoints, and others don't fully implement the interrupt endpoints.  
Aren't standards great? :-)

> http://www.ghz.cc/~clepple/libHID/doc/html/libhid-generic_8c- 
> source.html

This is an old URL. "libHID" was version 0.1, and Martin Krafft  
rewrote most of the API and function names in "libhid" 0.2.

-- 
Charles Lepple