> >The device can never overwhelm the system with data.  A device
> >is only allowed to send when asked to do so.
> 
> So as I understand the device will probably be built to ensure that when 
> there is a delay between data acquisition and
> a call to usbd_bulk_transfer(...), no data will be lost. 

The point seems to be that on USB, devices cannot transfer data whenever
they wish, but rather only when they're told to. If they're told too late,
data may be lost - the driver needs to make sure this does not happen
(by buffering frames as the device gets them in the hope userland will
read() them at some point, probably). The best mode of operation depends
on how the device behaves ("continually scanning" vs. "get one frame when
I tell you").

You told that the original (Windoze?) code used some kind of mmap() to
speed things up (which maybe wasn't that much helpful) - you could do
something similar even with traditional read() interface, if there was
an usbd_bulk_transfer() variant that would take a dmamap instead of
raw kernel buffer as data destination (in which case, you could receive
data directly into user-provided buffer, instead of intermediate kernel
buffer that needs to be copyout() later on)... But I'm not familiar with
the USB code, so maybe this is just hallucination.

	Regards,
		-- Jachym Holecek