> What I'd like to see would be: > > 1) open() : O_NONBLOCK honored to determine whether read() blocks or > returns E_AGAIN > 2) select() indicates when read() won't block Yes of course, that's the usual unix way (or turn on O_NONBLOCK with fcntl(2) ...). > 3) open() triggers capture for first read No. That way you'll need memory for the video frame even if the application never captures something. And even applications which do captures very likely set the format first. There is absolutely no point in capturing a frame at open() time. > 4) read() triggers capture for next read > 5) ioctl(VIDREADTRIGGER) triggers capture for next read (discarding any > existing frame) > > The utility of ioctl(VIDREADTRIGGER) would be if there is a long delay > from open/read to the next read, and the user wants to force a fresh > frame rather than getting the existing one. Yes, the old data is one of the problems here. The point of using read for capture is that it is _simple_. Set the format you need with ioctl(VIDIO_S_FMT), read() your frame, you are done. You can even capture with "dd" if you want. I don't like the idea to make that more complex with one more ioctl. 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 interaction between read() and streaming mmap() capture should be > that if streaming then assume the user knows what they want and frames > preferentially go to the read capture (if needed) rather than the > streaming. No. The API spec is pretty clear here: You can't stream and read() at the same time. Gerd -- Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
