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. Michael Downey ------------------------------------------------------- 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
