<div dir="ltr"><div class="gmail_quote gmail_quote_container"><div dir="ltr">Thank you Kieran and Laurent,<br><br>Sorry for the delay in my response ... it took me a while to learn how to "enable v4l2 debug" ... <div>It was indeed fun, since I did not know about this, and it seemed like opening a treasure chest :)</div><div>Your feedback steered me in the proper direction.<br><br>I started with the following observations:<br>- after the error with my xisp pipeline handler, I was still able to launch a gstreamer pipeline with v4l2src</div><div>- the error fails at following code in V4L2VideoDevice::queueBuffer() : ret = ioctl(VIDIOC_QBUF, &buf);</div><div>This gave me the intuition that the problem was not with my V4LSubdevices, but rather my V4LVideoDevice.<br><br>I did not enable "dynamic_debug" in the kernel, but enabled the following v4l debug for my V4LVideoDevice:<br><font face="monospace">   echo 3 > /sys/class/video4linux/video0/dev_debug</font></div><div><font face="monospace">   echo 3 > /sys/module/videobuf2_common/parameters/debug</font></div><div><br></div><div>The debug log was not very intuitive for me, but it turned out it did hold information on the culprit:<br><br><font face="monospace">...</font></div><div><font face="monospace">[250879.144584] video0: VIDIOC_S_FMT: type=vid-cap-mplane, width=640, height=480, format=BGR3 little-endian (0x33524742), field=none, colorspace=0, <b>num_planes=0</b>, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0</font></div><div><font face="monospace">...<br></font><br>The "num_planes=0" was incorrect, and the cause of my issue.<br><br>After going back to my "configure" function, and properly configuring the format for the V4L2VideoDevice, <br><br><span style="font-family:monospace">    ...</span></div><div><font face="monospace">    captureFormat.fourcc = pipe->capture->toV4L2PixelFormat(config.pixelFormat);<br></font><span style="font-family:monospace">    </span><font face="monospace">captureFormat.size = config.size;<br><br></font></div><font face="monospace"><b>    const PixelFormatInfo &info = PixelFormatInfo::info(config.pixelFormat);<br></b></font><div><font face="monospace"><b>    captureFormat.planesCount = info.numPlanes();<br>    captureFormat.planes[0].bpl = config.stride;<br></b><br></font><span style="font-family:monospace">    </span><font face="monospace">/* \todo Set stride and format. */</font></div><div><span style="font-family:monospace">    </span><font face="monospace">ret = pipe->capture->setFormat(&captureFormat);</font></div><div><span style="font-family:monospace">    ...</span><font face="monospace"><br></font><br>I got the following change in the v4l2 debug messages:</div><div><br><font face="monospace">...</font></div><div><font face="monospace">[  474.808502] video0: VIDIOC_S_FMT: type=vid-cap-mplane, width=640, height=480, format=BGR3 little-endian (0x33524742), field=none, colorspace=0, <b>num_planes=1</b>, flags=0x0, ycbcr_enc=0, quantization=0, xfer_func=0<br>[  474.808570] <b>plane 0: bytesperline=1920 sizeimage=921600</b></font></div><div><font face="monospace"><b>...<br></b></font><br></div><div>With these modifications, I was able to capture my first image:<br><br><font face="monospace">root@uzev-hailo-2024-1:~/libcamera.xisp_take01/build# cam -c1 -C1</font></div><div><font face="monospace">...<br>Using camera /base/pl-bus/i2c@80040000/sensor@10 as cam0<br>[0:13:58.267167846] [804]  INFO Camera camera.cpp:1202 configuring streams: (0) 640x480-RBG888<br>cam0: Capture 1 frames<br>838.393150 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 921600<br></font><br><br></div><div>Thank you again !<br><br>Cheers !<br><br>Mario Bergeron (AlbertaBeef)<br><br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 17, 2025 at 4:25 AM Laurent Pinchart <<a href="mailto:laurent.pinchart@ideasonboard.com" target="_blank">laurent.pinchart@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Jan 17, 2025 at 08:58:47AM +0000, Kieran Bingham wrote:<br>
> Quoting Laurent Pinchart (2025-01-17 06:10:14)<br>
> > On Thu, Jan 16, 2025 at 11:34:31PM +0000, Kieran Bingham wrote:<br>
> > > Quoting Mario Bergeron (2025-01-16 22:04:06)<br>
> > > > Hello,<br>
> > > > <br>
> > > > I have made some progress on my XISP pipeline handler.<br>
> > > > <br>
> > > > I am able to enumerate the four (4) cameras in my system:<br>
> > > > <br>
> > > > # cam -l<br>
> > > > ...<br>
> > > > Available cameras:<br>
> > > > 1: 'imx219' (/base/pl-bus/i2c@80040000/sensor@10)<br>
> > > > 2: 'imx708_wide' (/base/pl-bus/i2c@80070000/sensor@10)<br>
> > > > 3: 'imx500' (/base/pl-bus/i2c@80090000/sensor@1a)<br>
> > > > 4: 'imx477' (/base/pl-bus/i2c@800b0000/sensor@1a)<br>
> > > > <br>
> > > > <br>
> > > > When I attempt to capture one frame, I get the following error message when<br>
> > > > queueing buffers:<br>
> > > > <br>
> > > > # cam -c1 -C1<br>
> > > > ...<br>
> > > > Using camera /base/pl-bus/i2c@80040000/sensor@10 as cam0<br>
> > > > [51:33:28.743843521] [53606]  INFO Camera camera.cpp:1202 configuring<br>
> > > > streams: (0) 640x480-RBG888<br>
> > > > cam0: Capture 1 frames<br>
> > > > [51:33:28.782733421] [53607] ERROR V4L2 v4l2_videodevice.cpp:1777<br>
> > > > /dev/video0[16:cap]: Failed to queue buffer 0: Invalid argument<br>
> > > <br>
> > > This is quite often a failure to conifgure the pipeline correctly and<br>
> > > propagate formats through from the camera to the ISP for all of the link<br>
> > > validations.<br>
> > <br>
> > I'd expect a -EPIPE error in such a case, but we're dealing with an<br>
> > out-of-tree driver here that may not return the right error codes.<br>
> <br>
> Ah yes, I chose my words poorly - but I hope the intent/actions are<br>
> still the same. Yesterday, we tackled an issue with the same 'symptom'<br>
> on a -EINVAL at queue buffer time because the CSI2 receiver was being<br>
> configured with an out of bounds link frequency. I 'wrapped that up as<br>
> link validation' in my head - but it is a bit distinct.<br>
> <br>
> The principle issue is - there are many components that often all get<br>
> started when you first queue a buffer (even though there's a stream on<br>
> call, that can often be deferred to the first buffer being available).<br>
<br>
I really dislike how queuing buffers can fail due to misconfigured<br>
pipelines, and I consider that as driver bugs. Some of those bugs can't<br>
be fixed without changes to frameworks, but we really need to aim at<br>
improving all this.<br>
<br>
> Unfortunately - many debug and error paths are often disabled in v4l2<br>
> by default to prevent rogue applications flooding kernel logs. I do<br>
> wish it was clearer what went wrong sometimes - but that's why we turn<br>
> on all the logging when it fails.<br>
> <br>
> > > I usually make sure I enable all v4l2 debug at this stage on the<br>
> > > subdevices and video devices to be sure all dbg prints come out from the<br>
> > > kernel - and check to see what's failing.<br>
> > <br>
> > And in the worst case, add more print statements in the kernel to trace<br>
> > code paths and see what's going on.<br>
> > <br>
> > > Happy bug hunting!<br>
> > <br>
> > It's fun. For some definition of fun :-)<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</blockquote></div>
</div></div>