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