On Tuesday, November 08, 2011 13:50:54 Laurent Pinchart wrote:
Hi Hans,
On Monday 07 November 2011 10:03:23 Hans Verkuil wrote:
On Monday, November 07, 2011 00:18:57 Pawel Osciak wrote:
Hi Mingcheng, I've been looking into the data_offset problem that we discussed on the summit, but right now I'm not sure there is a problem in the current code:
- on QBUF, if the buffer type is OUTPUT, data_offsets will be copied
for the driver to use; if the buffer type is CAPTURE, it is the driver who should be filling them out so we do not copy anything
- on DQBUF, we copy the v4l2_planes structure from struct vb2_buffer
to v4l2_buffer. If the type is OUTPUT, this will copy back the offsets copied on QBUF (unless the driver changes this, but that would be wrong); if the type is CAPTURE, the values set in vb2_buffer->v4l2_planes by the driver will be copied to v4l2_buffer.
So I think this is the correct behavior - for OUTPUT we pass data_offsets provided by userspace to the driver, and for CAPTURE we return data_offsets provided by the driver to the userspace. If I recall correctly, you said that you'd need data_offset to be passed on QBUF from userspace for CAPTURE, but data_offset is a property of data present in the frame and is known to the driver in that case, not the userspace, and is returned to userspace, not passed from it. Could you remind me what was the scenario you needed it for?
Right now capturing starts immediately from the start of the buffer (we are talking about the mmap case here, BTW). What Mingcheng wants is to reserve space at the beginning of the buffer and have the capture DMA start at an offset. He thought he could use data_offset for that, but that's used for a different purpose (at least in the capture case).
My proposal is to add an app_offset field where the application can specify that the capture DMA should start at buffer.start + app_offset.
There are various use-cases where the application needs to fill in extra data before the captured frame if it for example needs to be passed on to some compression engine. Note that the kernel will never touch that area, other than zeroing it on allocation.
What about using USERPTR in that case ?
Sure, none of this is particularly relevant if you can use USERPTR. This is, however, a missing feature for the mmap streaming mode.
Regards,
Hans
For output data_offset and app_offset need to be summed to get the final offset.