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
