Gerd Knorr wrote: > (1) dma to userspace. This is what the current devel bttv versions > (0.8.x) do. It's the most efficient way to do it, but the drawback > is that neither non-blocking reads nor partial reads can be handled > this way. I guess there are possible hybrid approaches too - dma to bounce buffer if there's no pending read, else direct to userspace. You could even provide an ioctl() to let the app. specify whether or not it's interested in stored frames (if not, then no need to store them). >From a practial point of view though a high performance bttv application (unless there ever is V4L async IO read) is going to want to use the mmap interface, and so maybe read trade-offs should be selected in favor of fuctionality/ease of use rather than performance - i.e. dma to bounce buffer and provide non-blocking read and partial read if useful. One problem is that as things stand for some drivers read() is the only supported interface so needs to be as efficient as possible. One option that would be very application friendly would be to make driver mmap() support mandadory, then make the read() trade-offs as suggested above. Ben
