Hi Hans,

On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote:
> I have a few more questions regarding the streaming I/O API:
> 
> 1) The spec mentions that the memory field should be set for VIDIOC_DQBUF.
> But videobuf doesn't need it and it makes no sense to me either unless it
> is for symmetry with VIDIOC_QBUF. Strictly speaking QBUF doesn't need it
> either, but it is a good sanity check.
>
> Can I remove the statement in the spec that memory should be set for DQBUF?
> The alternative is to add a check against the memory field in videobuf, but
> that's rather scary.

In that case I would remove it for QBUF as well, and state that the memory 
field must be ignored by drivers (but should they fill it when returning from 
QBUF/DQBUF ?)

> 2) What to do with REQBUFS when called with a count of 0? Thinking it over
> I agree that it shouldn't do an implicit STREAMOFF. But I do think that it
> is useful to allow as a simple check whether the I/O method is supported.

REQBUFS(0) should also free allocated buffers (if any).

> So a count of 0 will either return an error if streaming is still in
> progress or if the proposed I/O method is not supported, otherwise it will
> return 0 while leaving count to 0.
> 
> This allows one to use REQBUFS to test which I/O methods are supported by
> the driver without having the driver allocating any buffers.
> 
> This will become more important with embedded systems where almost
> certainly additional I/O methods will be introduced (in particular
> non-contiguous plane support).
> 
> Currently a count of 0 will result in an error in videobuf.
> 
> Note that drivers do not generally check for valid values of the memory
> field at the moment. So that is another thing we need to improve. But
> before I start working on that, I first want to know exactly how REQBUFS
> should work.

-- 
Regards,

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

Reply via email to