[libcamera-devel] [RFC PATCH 08/10] libcamera: v4l2_videodevice: Create color-format planes in CreateBuffer()

[Tomasz Figa]

On Fri, Aug 27, 2021 at 10:00 AM Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>
>
>
> Le jeu. 26 août 2021 10 h 48, Laurent Pinchart <laurent.pinchart at ideasonboard.com> a écrit :
>>
>> Hi Nicolas,
>>
>> On Thu, Aug 26, 2021 at 10:31:41AM -0400, Nicolas Dufresne wrote:
>> > Le jeudi 26 août 2021 à 14:08 +0300, Laurent Pinchart a écrit :
>> > > > We'll probably have to carry a downstream patch to handle them
>> > > > initially... Would it be possible to at least make it easy to do that
>> > > > until proper V4L2 support gets merged?
>> > > >
>> > > > (v4l2_ext API is being worked on, but last time I checked it was stuck
>> > > > in review, without any comments...)
>> > >
>> > > If there's significant progress with this development we can carry a
>> > > downstream patch to avoid waiting for the API to be merged upstream, but
>> > > it indeed seems stuck. What would be your use case for such a downstream
>> > > patch though ? We would need drivers using the API to make it useful in
>> > > libcamera.
>> >
>> > I've come across a potential usage of this, but that was too much work to fix
>> > back then. The thingy was a very low power camera viewer (in a grid). We wanted
>> > to get all the requested frames into the same DMABuf, for that we could have had
>> > to be able to import that DMABuf with customized offsets and strides, so that
>> > the camera (if capable) would write the frame at the appropriate location in the
>> > frame. With 100% of the v4l2 driver not accepting custom strides, and this
>> > import limitation, we gave up, and simply reduced the grid size due to memory
>> > limitation.
>>
>> Interesting use case. I was however more wondering if Tomasz had use
>> cases in existing drivers, possibly drivers that carry out-of-tree
>> patches to support a data offset in V4L2. I fully agree it would be nice
>> to have data offsets in V4L2, but what I wonder if whether that would
>> only be used in the future once it's available, or if there are devices
>> that already use this feature in a downstream kernel.
>
>
> I believe in Xilinx tree, data_offset is used for import too. At least this is how this apparently invalid usage made it into GStreamer.
>
> If my memory is right, this method was denied by mainline as it would be incompatible with drivers that uses the buffer from the start to data_offset to store some state.
>
> While unusual, some codec drivers apparently store motion vectors there. Iirc it might be the case for Qualcomm Venus VP8 decoder.
>
> My memory is a bit rusted, so all this needs to be checked. I never really been completely clear why is this method was invalid, it allow per plane offset, hence allow importing single DMAbuf into drivers to that only support true MPLANE.

The reason was that data_offset is currently defined as filled in by
userspace for OUTPUT and by drivers for CAPTURE. So there is no way to
pass plane offsets for CAPTURE buffers.