On Mon, 24 Oct 2005, Pete Zaitcev wrote: > Well, that's fine, but this is certainly overdoing it: > > > -#define HIDDEV_BUFFER_SIZE 64 > > +#define HIDDEV_BUFFER_SIZE 1024 > > That's 24 KILOBYTES of zeroes. Not to mention that anything larger than > two pages worth is nearly impossible to allocate... > > Why in the world do you need a thousand of entries?
The problem is that we need at least as many entries as the wDescriptorLength of the HID device. I don't know what the maximum report size is (if there is one), but apparently some devices have a wDescriptorLength of at least 287! See: http://64.233.161.104/search?q=cache:ccjSgfoEOzEJ:www2.starcat.ne.jp/~yaoshi/netbsd/usbrimocon.txt+%22wDescriptorLength+287%22&hl=en&lr=&strip=1 It seems to me that the ring buffer should be at least twice as big as the report size, because we want to give the reader a fighting chance of getting to read the report before it gets overwritten by the next report that comes in. If there are HID devices out there with 287-element reports, that means the ring buffer should be at least 574 elements, which I rounded up to 1024 out of conservatism. Maybe a better approach would be to dynamically allocate the ring buffer based on the wDescriptorLength of the actual HID device that's plugged in, but obviously that would be a much bigger change. -Keith ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
