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?
Somehow I feel non-blocking I/O via read() isn't a good idea for
video frames ...
A related problem: The API document allows drivers to refuse read()
calls with sizes smaller than a full frame ("a partial frame may be
[ ... ] impractical or inefficient to implement"). Which doesn't
make sense to me, assuming we require the drivers to support
non-blocking I/O via read(). The driver needs a bounce buffer
for the video data anyway (see above) and it is absolutely no
problem to copy_to_user data in small pieces then.
Gerd
--
Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
