I'm probably lacking some important understanding here, so correct me where I'm wrong, please.
I've done a bunch of HIDs using ATMega32u4 and they all work fine on Windows and Android.
My latest HID input device is generating 11 bytes of status on 1, 10, or 20 bIntervals interrupts (I've tried them all separately).
Reading the device on Windows happens instantaneously.
(OTOH, I only ever get 11 bytes per synchronous read no matter how big the buffer is and how long a user polling interval, a separate question.)
On the Raspberry Pi a read is usually <10 ms but about 10% of the time it is a random time less than 1 second.
Running "time" on a program that does open, read, close always shows negligible user and kernel time and up to 1 second real time.
It's always the first open/read/close in a while that gives a problem.
That is, wait 10 seconds, hit it, it could be slow.
Get past this point and hammer it repeatedly (with a new executable) and it responds quickly.
Switching to the newer quad core RPi gives the exact same performance.
It is always the read function call, not the open or close that is taking all this time.
What's going on here?
Edit: Hmm, could this be related to different implementations/interpretations of GET_IDLE/SET_IDLE?
I'm not doing anything with these, I believe that I am STALL-ing.