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?
It's up to the driver writer. I really don't think this needs to be
dictated.
If I recall correctly, the way I made my driver work is:
When a read() call comes in:
if there is no data in the throw buffer, or the data in the throw
buffer is "too old" then initiate a new frame capture. If it was a
blocking read() then sleep, else return an error code (I forget which).
if there is good data, then copy it to the user buffer, and
initiate a new frame capture before returning from read().
select() will initiate a new frame capture as a side effect if there is
no (good) data ready. Otherwise it will sleep forever.
I guess for non-blocking read() capture, the driver would have to
automatically initiate a capture on a read() call or else implement
blocking read() and non-blocking read() the same way. That latter is not
as bad as it sounds, because the video source produces frames
continuously, so, in a sense, there is always data to be read. So what
if it takes a few milliseconds to gather it up? If for some reason the
hardware can't do asynch capture.
> 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
Hmmm. Maybe you're right. Am I giving too much discretion to the driver
writer?
Bill.
