Gerd Knorr wrote: > > 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. I agree it's questionable, but it seems the only clean alternative is that the first read is going to have to trigger it's own capture (as well as that for the next read), and you then introduce the fact that select() then will NEVER return readable until after the first read has been done, so you have to do ioctl(VIDREADTRIGGER) to "prime" a select() based capture loop. > > > 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. It wouldn't *normally* be needed. A normal use would just be open(), read(), read()..., but in the case where you do open(), ... time goes by ... read(), read(), then the added ioctl would allow you to request that your first read() gets an up-to-date frame rather than one that could be arbitrarily old. > 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. > > 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. Hmmm... I wasn't aware of that. I don't see the point of restricting it. Ben
