[libhid-discuss] Digital Arts & Crafts Studio - HID help needed

[Charles Lepple]

On Nov 8, 2007, at 3:21 AM, Bill Kendrick wrote:

> On Tue, Nov 06, 2007 at 08:00:35PM -0500, Charles Lepple wrote:
>> Also, if you were just doing a simple read() on /dev/usb/hiddev0, it
>> was probably doing interrupt transfers, and hid_get_input_report()
>> uses control transfers.
>
> Ah, I see.  Obviously, I haven't had time to properly learn about USB,
> and was struggling from the top-down with libraries first. :)

The libusb and libhid documentation do not really cover the mechanics  
of USB or HID.

However, chapter 9 of the USB spec (the suggested API that libusb  
follows), and the USB HID Class specification, are handy reference  
guides, and are not completely unreadable. You can download them from:

http://www.usb.org/developers/docs/

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

> Indeed.  I've decided to start using libusb directly, but currently  
> have
> two problems:
>
> (1) Reads fail :)

Which error code? (Once you detach the device, you should be able to  
do anything with libusb/libhid that you can do with the /dev/usb/ 
hiddev* interface, but it's a matter of finding out exactly what to do)

> (2) I have not successfully detatched the device from the kernel.
>   libhid did this for me via the 'force' open call.
>   For now, I need to use the 'libhid-detatch-device' (I think?)  
> tool first. :(

All of the magic is contained in hid_os_force_claim() in linux.c. The  
loop is a good idea for robustness, because sometimes the kernel does  
not let go of the device immediately. Two or three retries should  
suffice.

> I'm guessing this list wouldn't be the appropriate place to ask  
> libusb-related
> questions, if I'm not using libhid at all, would it?

Short answer: keep asking until people get annoyed :-)

I think it depends on how you approach it. In the past, I have  
bristled at the idea of someone signing up for the libhid list, and  
expecting us to solve their problem for some commercial software that  
they are writing (which is probably not going to be allowed to link  
against libhid anyway, given that our code is GPL'd and not LGPL'd).

Since you are writing open-source software, you won't have anything  
more demanding than a self-imposed schedule, and you probably have  
the time to understand a little more about what's going on under the  
hood. As far as I'm concerned, even if you don't use libhid itself,  
USB HID programming with libusb is not too far off topic, and the  
people who haven't already unsubscribed from the list have a good  
amount of experience with Linux, USB and HID devices that they are  
usually willing to share. Maybe this is a good argument for splitting  
off some of the HID parsing functions, or creating other functions to  
emulate the Windows HID API.

If it is something specific to libusb, you might try the libusb-devel  
list:

https://lists.sourceforge.net/lists/listinfo/libusb-devel

The people at the linux-usb-devel list (which is mainly for  
discussing development of the Linux kernel USB stack and kernel USB  
device drivers) may also be able to help, but when it's time for a  
new kernel release, reading that list is like drinking from a firehose.

-- 
Charles Lepple