Re: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On 09/04/2009 05:14 AM, Andy Walls wrote:
The V4L2 spec for the read() call seems unlcear to me:

"Return Value
On success, the number of bytes read is returned. It is not an error if
this number is smaller than the number of bytes requested, or the amount
of data required for one frame. This may happen for example because
read() was interrupted by a signal. On error, -1 is returned, and the
errno variable is set appropriately. In this case the next read will
start at the beginning of a new frame."

To me, the spec only says the remainder of a frame is thrown away when
read() exits with an error.


It does seem to say that yes, as said in a previous mail of me, this part
of the spec needs some fixing. It seems to try and describe the queuing
that happens inside the driver in too much detail and leaves out other
much me important bits about how read() on video devices behaves.


BTW, should select() return "data available", if less than one whole
frame is available?  It can happen if the buffers we give to the CX23418
firmware don't exactly match the YUV framesize.  The V4l2 spec for the
read() call seems to imply that read() should block (or return with
EAGAIN) until at least one whole frame is available.  Is that correct?

I agree that waiting until at least one whole frame is available. Is the
correct behaviour.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux