<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 26 août 2021 10 h 48, Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com">laurent.pinchart@ideasonboard.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nicolas,<br>
<br>
On Thu, Aug 26, 2021 at 10:31:41AM -0400, Nicolas Dufresne wrote:<br>
> Le jeudi 26 août 2021 à 14:08 +0300, Laurent Pinchart a écrit :<br>
> > > We'll probably have to carry a downstream patch to handle them<br>
> > > initially... Would it be possible to at least make it easy to do that<br>
> > > until proper V4L2 support gets merged?<br>
> > > <br>
> > > (v4l2_ext API is being worked on, but last time I checked it was stuck<br>
> > > in review, without any comments...)<br>
> > <br>
> > If there's significant progress with this development we can carry a<br>
> > downstream patch to avoid waiting for the API to be merged upstream, but<br>
> > it indeed seems stuck. What would be your use case for such a downstream<br>
> > patch though ? We would need drivers using the API to make it useful in<br>
> > libcamera.<br>
> <br>
> I've come across a potential usage of this, but that was too much work to fix<br>
> back then. The thingy was a very low power camera viewer (in a grid). We wanted<br>
> to get all the requested frames into the same DMABuf, for that we could have had<br>
> to be able to import that DMABuf with customized offsets and strides, so that<br>
> the camera (if capable) would write the frame at the appropriate location in the<br>
> frame. With 100% of the v4l2 driver not accepting custom strides, and this<br>
> import limitation, we gave up, and simply reduced the grid size due to memory<br>
> limitation.<br>
<br>
Interesting use case. I was however more wondering if Tomasz had use<br>
cases in existing drivers, possibly drivers that carry out-of-tree<br>
patches to support a data offset in V4L2. I fully agree it would be nice<br>
to have data offsets in V4L2, but what I wonder if whether that would<br>
only be used in the future once it's available, or if there are devices<br>
that already use this feature in a downstream kernel.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">While unusual, some codec drivers apparently store motion vectors there. Iirc it might be the case for Qualcomm Venus VP8 decoder.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div></div></div>