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

[Nicolas Dufresne]

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.



> --
> Regards,
>
> Laurent Pinchart
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20210826/5dd5644e/attachment.htm>