On Mon, Apr 10, 2006 at 05:03:21PM -0700, Greg KH wrote: > On Mon, Apr 10, 2006 at 03:08:50PM -0600, Michael Downey wrote: > > I am currently looking at using a MegTek USB insertion reader and I have > > run into a problem with the current hiddev. The card reader returns a > > 338 byte Input report on the interrupt in channel everytime a card is > > inserted. The data contains basically all the information needed from > > the card. The problem is that this one report is seen as 338 usage > > references. So hiddev tries to build all the events for this report but > > wraps it's buffer as it only allocates space for 64. I increased > > HIDDEV_BUFFER_SIZE to 512 and everything worked correctly. > > > > My question is whether there would be any issue with increasing the > > HIDDEV_BUFFER_SIZE to 512? I realize that this causes us to use 24 * > > 512 bytes instead of 24 * 64 bytes. Is there any specific reason for > > only allocating 64 or was it just a nice power of 2 number? The main > > reason why we overflow this buffer is that we report a seperate event > > for every report count on each usage. So in the case of this card > > reader there are three usages with a report count of 110. So each of > > these usages cause 110 seperate events to be generated. If we could > > somehow pack all the similar data into a single buffer then this device > > would only generate 11 events per insert instead of 338. This would > > mean making changes to the file access structures which would likely > > break things for other people. > > > > If no one has issues I will submit a patch to just up the > > HIDDEV_BUFFER_SIZE to 512 from 64. > > I don't see a problem with this, perhaps Vojtech remembers why the > buffer size was set to 64. The reason is that it was originally intended for devices which don't issue huge numbers of reports in one go, and 64 was supposed to be 'large enough' for userspace to be able to empty the buffers as the data are coming from the device.
Moving to 512 is not a big problem, except for memory usage. However, I'd suggest using libusb/libhid instead here, since the hiddev interface is really inadequate for uses like this. -- Vojtech Pavlik Director SuSE Labs ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
