Vojtech Pavlik wrote: >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. > > > The problem with libhid is that it is a GPL licenced library not LGPL so I can't use it. Otherwise that was my initial plan. Also the benifit of using hiddev is that I don't have to install another library onto the system. I could try using libusb but it looked like I would have to basically replicate a lot of what libhid does.
So is the memory usage a concern? ------------------------------------------------------- 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
