Gerd Knorr wrote: > > Yet another v4l2 API comment / update request. > > The current specification for capture read() and for non-blocking > I/O is somewhat unclear. How this is supposed to work in detail? > > For non-blocking I/O using read() the driver has to capture data > into a kernel bounce buffer and then just copy_to_user the image > data (because it does not know the destination address yet at the > time the capture is started). > > How such a capture is triggered? Should the application call read() > once (which would make the driver start capture and return -EAGAIN)? > What about select()? Does that also trigger a capture (very ugly side > effect IMHO)? What happens when a frame was returned by the read() > call? Should the driver automagically schedule the next capture or > not? 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 3) open() triggers capture for first read 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. 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. If there is a read capture outstanding then select() would indicate when read() can be performed without blocking, otherwise with no pending read select indicates when ioctl(VIDIOCSYNC) can be performed without blocking. I think this functionality would be most natural and flexible. Ben
