> > IMHO the main question is: Is it really useful to support non-blocking > > I/O via read()? Or should we simply say: if you need non-blocking I/O, > > use the mmap() interfaces? That would solve all the problems we have > > with the non-blocking read(): The driver knows where to put the data > > (no bounce-buffers needed), we have ioctls to start/stop capture, ... > > The non-blocking open/read is useful because it allows you to integrate > V4L read() based IO with other non-V4L IO in a single select() based > loop/thread. select() works for streaming mmap(), so you don't need a non-blocking read() for that. > > No. The API spec is pretty clear here: You can't stream and read() at > > the same time. > > Hmmm... I wasn't aware of that. I don't see the point of restricting it. I don't see the point in using mmap() and read() based capture at the same time. So why require drivers to deal with that special case? Also streaming capture guaranties that the application can get full rate, allowing any other capture requests inbetween would break that. Gerd -- Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
