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: > > [EMAIL PROTECTED] ~/cpp/psuc/ls $ sudo rmmod usbhid > ERROR: Module usbhid is in use by hidp > [EMAIL PROTECTED] ~/cpp/psuc/ls $ sudo rmmod hidp > ERROR: Module hidp is in use > [EMAIL PROTECTED] ~/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 _______________________________________________ libhid-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
