[libcamera-devel] Regression in commit 86a47fdcd97350bd979a4d6b00124330a3b02441

[David Plowman]

Just in case it helps anyone to check the problems for themselves...
It's easy enough to try our libcamera-apps
(https://github.com/raspberrypi/libcamera-apps) by following the build
instructions and running the little test.py "smoke test" application.

It seems I'm looking at a different commit now
94fb6b2f4d02707cac2a1c5c1a9d622eeaeb4c04 ("libcamera:
v4l2_videodevice: Create color-format planes in createBuffer()"), by
the way.

Thanks!

On Fri, 3 Sept 2021 at 16:31, David Plowman
<david.plowman at raspberrypi.com> 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.
>
> Thanks
> David
>
> On Fri, 3 Sept 2021 at 14:21, David Plowman
> <david.plowman at raspberrypi.com> 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?
> >
> > Thanks!
> > David