Hello,

>On Mon, 22 Feb 2010 00:12:18 +0100
>Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote:
>> On Saturday 20 February 2010 15:00:21 Hans Verkuil wrote:
>> > 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 ?)
>
>Agree. It seems that the memory field is not useful at all in the struct
>v4l2_buffer if a same process does reqbuf, qbuf, dqbuf and querybuf.

In the current multi-plane buffer proposal, the memory field is required
in querybuf, qbuf and dqbuf for the v4l2-ioctl.c code to be able to
determine whether the planes array should be copied from/to user along
with the buffer.
Just wanted to add another view to the problem, as multiplanes are accepted
yet of course.


As for the REQBUF, I've always thought it'd be nice to be able to ask the
driver for the "recommended" number of buffers that should be used by
issuing a REQBUF with count=0...


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland R&D Center


--
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