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

[Laurent Pinchart]

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.

-- 
Regards,

Laurent Pinchart