[libcamera-devel] Regression in commit 86a47fdcd97350bd979a4d6b00124330a3b02441

[Laurent Pinchart]

Hi David,

On Fri, Sep 03, 2021 at 04:31:50PM +0100, David Plowman wrote:
> Hi again
> 
> Still struggling here, and finding various buffer sizes seem to be
> messed up. When it "invents" these fake multiple planes, it seems to
> be using the image width as the stride (or "bytesperline" sometimes),
> with the result that all the buffer lengths end up too short. The code
> I'm looking at is towards the end of V4L2VideoDevice::createBuffer. I
> notice a "\todo Take the V4L2 stride into account" there... Strides
> *MUST* take into account the numbers coming out of the hardware
> because it has specific alignment constraints.
> 
> We're actually trying to put our libcamera-apps into our new OS
> releases and are unfortunately finding that EVERYTHING is crashing all
> over the place with seg faults. Any help would be appreciated.

All this is my top priority for the weekend. In the meantime, you can
use commit a000a1f6e3208515200aaae6ca8128471c6ed9f3 as a base, that's
right before the breakage got introduced.

> On Fri, 3 Sept 2021 at 14:21, David Plowman wrote:
> >
> > Hi everyone
> >
> > We're having a bit of a problem with this commit ("libcamera:
> > framebuffer: Add offset to FrameBuffer::Plane").
> >
> > We use only single plane buffers in all our code and previously
> > FrameBuffers would advertise having only one plane
> > (frameBuffer.planes().size() would be 1), and the length would be the
> > full length of the plane (all of the Y and U and V pixels). We'd use
> > this information to mmap the buffer and give us a pointer. And in
> > fact, we'd quite often check that there's only one plane because (for
> > example) our codec driver doesn't support mplane formats.
> >
> > Since this commit, everything is now showing up as 3 planes, and each
> > has a length field just for a part of the plane, so the first "plane"
> > would just be the Y, and so on.
> >
> > Now, I can loop through all the planes with the same fd and add up all
> > the lengths, and then mmap my buffer as before, but I guess I'm
> > wondering why this has changed. After all, it's *not* a multi-plane
> > buffer and we want to know, only now it seems harder to tell the
> > difference.
> >
> > Any thoughts?

-- 
Regards,

Laurent Pinchart