[libhid-discuss] Performance of libhid

[shivaprasad javali]

Thanks for all your input. My USB device may have poor performance because
of the device itself as Peter pointed out, but I have no control it and can
only try to make it faster in my driver. I don't know of how much help this
will be , but I will rewrite my driver using more low-level code.

I don't have any experience in USB device drivers and I am a bit short on
time. Which of the native Linux API or libusb will be easier and faster to
develop? Any pointers will be helpful.

Once again thanks for all your help.

Thanks
Shivaprasad

On Thu, Apr 30, 2009 at 4:18 AM, Peter Stuge <stuge-libhid at cdy.org> wrote:

> shivaprasad javali wrote:
> > unplug the USB devices which have to be reflected in my application
> > immediately( there is a visual indicator as to how many USB devices are
> > plugged in). So I open new handles to the USB devices once every
> > second.
>
> I strongly recommend that you make your application event based
> instead. (Never poll, get plug/unplug events from the system and
> update your view accordingly.)
>
>
> > My target platform is the OLPC
>
> I also work on coreboot, too bad for us you guys recruited Richard. :)
>
>
> > In my application a Motion sensor can be connected to the computer
> > through the USB device and when it is connected I read from the
> > sensor every 5ms so that I can detect any sort of movement across
> > the motion sensor. The OLPC in itself is very slow and that coupled
> > with my requirement on the USB driver has led the motion sensor to
> > be very sluggish in its response.
>
> The OLPC is a Geode LX running at 400-500 MHz and the USB is 2.0.
> I don't consider that "very slow." There are admittedly many layers
> of software running on the CPU, but the system does not have to be
> sluggish.
>
>
> How USB performs is extremely dependant on the device. It is very
> easy for inexperienced USB device developers to create devices with
> very bad performance. Knowing when and how to use standardized device
> classes and the four endpoint types will make or break a device.
>
> HID devices are very easy to access in Windows. Many device vendors
> choose to abuse the HID specification for this reason, in spite of
> their devices having nothing to do with a Human Interface.
>
> But, as Charles pointed out, HID devices are never high performance.
> They use control or interrupt transfers, which have particular
> benefits and drawbacks (just like bulk and isochronous do).
>
>
> As you are targeting a particular system and need neither portability
> nor full featured HID report processing you should write your driver
> using either one of the native Linux APIs for USB (usbfs) and HID
> (hidraw) or possibly libusb-1.0.
>
> If you go for usbfs, make sure to keep multiple transfers pending at
> all times.
>
> You must write more low level code to get better performance.
>
> Your device will be the bottleneck. The device descriptors and the
> device firmware is critical. Most device vendors are not very skilled
> with USB. Geode LX+CS5536 can drive a lot of USB data effortlessly.
>
>
> //Peter
>
> _______________________________________________
> libhid-discuss mailing list
> libhid-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
> http://libhid.alioth.debian.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/libhid-discuss/attachments/20090430/8371155f/attachment.htm>