[libhid-discuss] device with multiple interfaces

[Peter Stuge]

On Tue, May 15, 2007 at 11:42:33PM +0200, Arvid Picciani wrote:
> > This is problematic. In order to communicate with the USB device
> > directly in your application you must first disconnect the kernel
> > HID driver. This is a really bad approach to programming the device.
> > (Sometimes neccessary because of really bad device design.)
> 
> does this mean i _could_ see the other interfaces when
> disconnecting from the kernel?

Yes, that's right. But then the interface will not "get through" to X
or any other part of the system. Only your application. (That's why
it's bad to bundle independent functionality in one interface.)


> i couldnt unload the driver so i couldnt test:
> 
> $aep at brush ~/cpp/psuc/ls $ sudo rmmod usbhid
> ERROR: Module usbhid is in use by hidp
> $aep at brush ~/cpp/psuc/ls $ sudo rmmod hidp
> ERROR: Module hidp is in use
> $aep at brush ~/cpp/psuc/ls $ sudo rmmod -f hidp
> ERROR: Removing 'hidp': Resource temporarily unavailable

Yeah, because the driver is in use.

There is a function call in libhid to detach the driver from the
device, without needing to unload the driver. But this only really
works on Linux, no other systems.


> > Maybe you can get away with using the kernel input layer API to
> > program the device?
> 
> from the userspace? no idea how, but i will look into it. thanks
> alot.

How will depend on what type of device it is and how it presents
itself to the kernel.


> > What does the manufacturer say about support for the device?
> 
> well, i am suposed to write a linux driver for it in exchange for
> the hardware, so i have direct contact to the hardware developer.
> but he still insists saying the device has 4 interfaces. .... and
> it works on windows.

Right, that's a classic comment.

> it looks like he didnt read the usb specs corectly to me, but i am
> a newbie to USB.

It is far from trivial to design USB devices well. A lot of thought
needs to go into how the device should present itself to the host in
order to make the device work as well as it can across different
operating systems, and in line with the design of the bus and the bus
protocol.

Many developers (hardware and software) that are new to USB believe
(wish?) that it is simply a serial port with a more practical
connector and built-in power supply, but this is far from true.

The first USB device type that was supported in Windows was HID, and
the same API that was invented back then can still be used for HIDs.
This API makes a HID behave much like a serial port, which
unfortunately only strengthens the misconception. :\


> so if you got some hints maybe what i could tell him, i would be
> glad.

For starters, don't tell him that the device is badly designed
without making sure that it really is true. FUD is never good,
especially not when starting up a partnership.

Then, ask for protocol documentation. What should be sent to and
from the device?

When you know that you can determine if it's possible to use the
Linux input API or possibly the hiddev API, rather than libhid.

Not that libhid is bad, but if both interfaces are used by other
drivers it would be better to not have to resort to libhid. If your
application crashes before re-attaching the usbhid driver to the
device after it has performed it's task, the "normal" HID function of
the device will be lost until either your application is run again,
or the device is removed and attached to the USB hub again.


> btw, your name sounds german, are you? 

No I'm swedish (the name is from northern Sweden) but I speak german.
I'll be in Berlin end of May for the LinuxTag expo.


> i wrote the manufacor telling him his device must be bad designed
> and someone else confimed

Oops.


> (it's going to be hard to convince him since it works on windows).
> we will see what he answers tomorow. 

It will probably not be possible to change how the device works, so
you'll just have to make the best of the situation.

I think hiddev may be the best solution. See
/usr/src/linux/Documentation/usb/hiddev.txt
for more details on how it works.


//Peter