IMX219 camera with UNO Q, Media Carrier and App Lab

[philippe86220]

Hi everyone,

I have just finished the first version of a small camera project using an Arduino UNO Q, the Arduino® UNO™ Media Carrier, and a Sony IMX219 camera connected to CAMERA0.

The complete application runs on the Linux/MPU side using Arduino App Lab 0.10.0. No MCU code is used.

The WebUI allows manual adjustment of:

• exposure;
• analogue gain;
• full-resolution image capture (3280 × 2464).

The image is captured as RAW Bayer data and processed directly in Python. The application performs bilinear demosaicing, Gray World white balance, shadow correction, moderate contrast/sharpening, and finally generates a JPEG that is displayed in the WebUI.

The project also uses a custom App Lab camera brick with a dedicated container. The camera service communicates with the Linux camera pipeline through media-ctl and v4l2-ctl.

I tried to make the README quite detailed, especially for people who, like me, are discovering how the different parts of an App Lab application communicate with each other.

The project has been exported from App Lab, re-imported and tested successfully. I have therefore released this first stable version as v1.0.0.

GitHub repository:

GitHub - philippe86220/imx219-camera-with-arduino-app-lab: IMX219 Camera with Arduino App Lab

Here is an outdoor test image captured and processed directly by the application:

Exposure: 1042 — Analogue gain: 49

This V1 intentionally uses manual exposure and analogue gain.

The next step will be a V2 where I would like to experiment with automatic exposure and analogue gain control, while keeping this V1 as a simple and stable reference.

Any comments or suggestions are welcome.

[paulrbarnard]

Hi philippe86220, great project — this is exactly the setup I'm trying to get working (UNO Q + Media Carrier + camera on CAMERA0), but I'm stuck one step before your starting point.

When I go into App Lab, Settings, Carriers to enable Camera0, it shows "board needs to be updated" and the update action does nothing. I've dug in a bit: apt-get update succeeds fine, apt list --upgradable shows no pending Arduino packages. arduino-app-cli system update --only-arduino --yes reports "No upgradable packages found". Rebooted the board and restarted App Lab, same result. The camera-capable device tree (qrb2210-arduino-imola-camera-rpiv2.dtb) is already present on disk alongside the default one, so it looks like the kernel side is ready, but nothing is selecting it at boot. As a result, /dev/media0 and the /dev/v4l-subdev* nodes your camera brick depends on never appear, I only get /dev/video0 and /dev/video1, which are the Venus hardware decoder, not the sensor.

My board is on image build 20251024-412, App Lab 0.10.0, arduino-app-cli 0.13.0.

Since you've got this fully working end-to-end, did you hit this same "needs update" gate on the Carriers panel, or was Camera0 already enabled on your board out of the box? And if you did hit it, how did you get past it? Any version info on your side, App Lab or board image build, would help me figure out if I just need to wait for a rollout, or if there's something else going on.

Thanks!

[ptillisch]

In order to make relevant information available to any who are interested in this subject, I'll share a link to formal report @paulrbarnard submitted to the Arduino developers:

Carriers panel blocks enabling Media Carrier Camera0 with "board needs to be updated", but no update is available

[philippe86220]

Hi Paul,

I found the Carriers settings you were referring to. I had actually never used this panel before because I didn't need to configure CAMERA0 manually.

On my working UNO Q, the settings currently show:

• External carriers: enabled
• Carrier type: media-carrier
• Camera0: type1-2lanes
• Camera1: none
• Display: none
• System version: System is up to date

CAMERA0 was therefore already configured this way when I started working with the Media Carrier. I never encountered the “board needs to be updated” message and never manually changed the device tree or boot configuration.

I also checked my system:

• App Lab: 0.10.0
• arduino-app-cli: 0.13.0
• Debian: 13 (Trixie)
• Kernel: 7.0.0-g122c2c22d838
• Build Version: 20260528-558
• Release date: 28/05/2026

The significant difference I can see is that my system image is 20260528-558, whereas yours is 20251024-412.

I don't know whether this difference is responsible for the problem, but hopefully it provides a useful comparison for issue #660.

Philippe

[paulrbarnard]

That was exactly the problem. I've flashed 558 and now I can enable the carrier and I have an operational camera. So the real problem here is that the "update" button does nothing. It would have been nice if the firmware pane had indicated there was an update available, that would have been a nice clue.

Many Thanks for your help.

[paulrbarnard]

@philippe86220 I spoke a touch too soon I'm not at the received image stage.

Sensor detection is now fully working (imx219 shows up cleanly via cam -l and media-ctl, all the v4l-subdev nodes are present). But I'm stuck one step further on than before: actually starting the video stream fails.

VIDIOC_STREAMON returns "Invalid argument" on /dev/video0, reproducible three ways:

• libcamera's cam tool, at any resolution (640x480 scaled or native 3280x2464)
• Direct v4l2-ctl streaming on the raw RDI passthrough node, using the sensor's native format (set via v4l2-ctl -d /dev/video0 --set-fmt-video=width=3280,height=2464,pixelformat=pRAA, which the driver accepts fine and reports correct buffer sizes back - so it's not a format mismatch)

media-ctl -p shows the pipeline correctly linked end to end (imx219 -> msm_csiphy0 -> msm_csid0 -> msm_vfe0_rdi0 -> msm_vfe0_video0/dev/video0), but every entity in the topology reports "(0 routes)". That made me wonder if this driver needs an explicit route configured via the newer V4L2 streams/routing API before STREAMON will succeed, even with the static links already enabled - but the v4l2-ctl on my board's v4l-utils build doesn't have --get-subdev-routing/--set-subdev-routing, so I can't test that theory directly.

Since your camera brick clearly gets real frames out via media-ctl/v4l2-ctl, could you share the exact command sequence you use to get from a fresh boot to a successful capture? In particular I'm curious whether you do any explicit routing/streams setup on the subdevs before opening /dev/video0, or anything else beyond the basic link setup that isn't obvious from the README.

Board/software versions on my side: image 20260528-558, kernel 7.0.0-g122c2c22d838, App Lab 0.10.0, arduino-app-cli 0.13.0. Camera0 set to type1-2lanes.

Thanks again for the help so far - getting a lot closer.

Just to add: I'm using a "SHCVHV 8MP PRI Camera V5" module rather than an 'official' RPi camera from Raspberry. I don't think this should be an issue.

[paulrbarnard]

I've dug a bit more and checked your camera_service.py and I found the exact sequence you use for the RDI path:

media-ctl -d /dev/media0 -V '"msm_csiphy0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csiphy0":1[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csid0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_csid0":1[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":0[fmt:SRGGB8_1X8/WxH]'
media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":1[fmt:SRGGB8_1X8/WxH]'
v4l2-ctl -d /dev/v4l-subdev12 --set-ctrl=exposure=...,analogue_gain=...
v4l2-ctl -d /dev/video0 --set-fmt-video=width=WxH,pixelformat=RGGB
v4l2-ctl -d /dev/video0 --stream-mmap=4 --stream-count=1 --stream-to=FILE

I reproduced this exactly (setting format on both sink AND source pad of each subdev, which I'd been missing before, and setting sensor controls before format/stream). That got further than anything I'd tried: STREAMON no longer returns an error at all. But instead of producing a frame, v4l2-ctl just hangs indefinitely - no data ever arrives, no timeout, nothing further in dmesg. I let it sit for a couple of minutes with zero progress before killing it.

Looking at dmesg from that same STREAMON call, I get this kernel warning every time:

WARNING: drivers/media/v4l2-core/v4l2-subdev.c:484 at call_s_stream+0xec/0xf8 [videodev]
Call trace:
  call_s_stream+0xec/0xf8 [videodev]
  video_start_streaming+0x104/0x13c [qcom_camss]
  vb2_start_streaming+0x6c/0x178 [videobuf2_common]
  vb2_core_streamon+0xd8/0x1bc [videobuf2_common]
  vb2_ioctl_streamon+0x58/0xa0 [videobuf2_v4l2]

My working theory: call_s_stream() is what qcom_camss uses to tell each subdev in the pipeline (sensor -> csiphy -> csid -> vfe) to actually start streaming. If it warns on one of those calls but doesn't propagate that as a hard error, video_start_streaming could end up marking the whole queue "started" while silently skipping the sensor's own start-stream call - which would exactly explain STREAMON succeeding with zero frames ever arriving, forever.

Question for you: do you see this same WARNING in your dmesg when your camera_service starts a capture, even though you do get real frames back? Or is your dmesg completely clean at that point? That would tell us whether the warning is a harmless red herring in your working setup, or whether something upstream of it is different between our two boards despite the identical kernel version.

Happy to share the full dmesg/lspci-equivalent output if useful.

[philippe86220]

Hi Paul,

I tested this on my working setup immediately after taking a successful photo with the application.

I don't get the call_s_stream warning you are seeing.

I checked with:

sudo dmesg | grep -E -i "call_s_stream|qcom_camss|WARNING|streaming"

There was no call_s_stream warning.

I also checked:

sudo dmesg | grep -E -i "camss|csiphy|csid|vfe|imx219|v4l2"

The only CAMSS-related messages I have are from boot, including:

qcom-camss 5c11000.camss: supply vdd-csiphy-1p2 not found, using dummy regulator
qcom-camss 5c11000.camss: supply vdd-csiphy-1p8 not found, using dummy regulator

My camera still captures frames correctly, and there is no new CAMSS/V4L2 warning when a capture is performed.

Since we now have the same system image, kernel, App Lab version and Camera0 configuration, I think it might also be useful if you try running my complete App Lab application unchanged, rather than reproducing the camera_service.py sequence manually.

That would give us a cleaner comparison:

my UNO Q + my IMX219 + same application = working
your UNO Q + your IMX219 + same application = ?

If the complete application also hangs on your board and produces the call_s_stream warning, then we would know that the application and command sequence are identical on both sides. The different IMX219 camera module would then be one of the remaining differences worth investigating.

I don't think we can conclude yet that your SHCVHV module is the cause, but testing the exact same application should help narrow this down.

Philippe

[paulrbarnard]

Update - ran your app exactly as you suggested, plus some other developments since my last post.

First, a board-side update landed: App Lab's example catalog refreshed and now ships an official native "Camera" peripheral (arduino.app_peripherals.camera.Camera) with a one-line WebUI.expose_camera() helper - no more needing video_object_detection or a custom brick just to get a feed. I tested that first, on its own, with a fresh re-seat of both the Media Carrier and the camera cable. That re-seat did fix a real, separate problem I'd been hitting intermittently: I2C write failures to the Media Carrier's onboard PCA9555 GPIO expander (the chip that controls camera power), which had been causing inconsistent sensor detection. After the reseat, sensor detection has been rock solid every time.

But the actual streaming still fails, even through Arduino's own new official Camera class:

ERROR V4L2 v4l2_videodevice.cpp:1998 /dev/video0[12:cap]: Failed to start streaming: Invalid argument
ERROR Camss camss.cpp:429 Failed to start camera platform/soc@0/5c1b000.cci/i2c-2/2-0010 imx219

So then I did exactly what you suggested: ran your complete app unmodified rather than reproducing the sequence by hand. I recreated your repo file-for-file on the board (git clone was blocked in my environment, so I pulled each file from GitHub directly and wrote them in - app.yaml, python/main.py, and the full bricks/camera/ brick including camera_service.py verbatim), and ran it exactly as your brick_compose.yaml defines it - as root, inside its own Docker container, with the same device mounts.

Result: your exact code, running exactly as designed, fails the same way on my board:

VIDIOC_STREAMON returned -1 (Invalid argument)
Erreur capture : Taille RAW incorrecte : 0, attendu 8081920

That's a clean result in the sense that it rules out a lot: it's not root vs non-root permissions (your code runs as root here too), it's not a command-sequence mistake on my end (this is your literal file, unmodified), and it's not specific to any one API (I've now hit the identical STREAMON/Invalid argument failure through libcamera's cam tool, raw v4l2-ctl on the RDI path, the newer PIX routing path, Arduino's own new native Camera peripheral, and now your exact working code).

Across this whole process, whenever the sensor is cleanly detected (which it now is, consistently, after the reseat), STREAMON has never once succeeded on my board, on any code path. That points at something board- or kernel-specific rather than anything in your code or mine.

One more variable I'm ruling out: my camera module is an "8MP IMX219 Camera Module, MIPI interface, 200° FOV" (SHCHV brand, fisheye lens variant) rather than a standard-lens Pi Camera Module v2 clone. It identifies correctly as imx219 over I2C, but it's possible the board/lens variant differs enough to matter. I've ordered a different IMX219 module to rule that out and will report back once it arrives.

Many thanks for helping me sort this out.

[philippe86220]

Hi Paul,

Just one additional data point: I also tried the new basic App Lab Camera example you mentioned, using arduino.app_peripherals.camera.Camera.

On my UNO Q with my IMX219, it works. The camera starts successfully, captures an image, and captured_image.jpg is created correctly.

My log contains:

CSICamera: Successfully started csi:platform/soc@0/5c1b000.cci/i2c-2/2-0010 imx219

followed by a successful stop of the camera.

So the new official Camera example also gives us the same difference between our two setups: it successfully streams and captures on mine, whereas you get Failed to start streaming: Invalid argument.

I think your test with the second IMX219 module will be very interesting.

Philippe

[paulrbarnard]

This is starting to drive me nuts. Two genuine Raspberry camera turned up today. They are not seen at all by the media carrier. However plugging in to a VentunoQ the camera shows up (doesn't get to the image stage due to a different error). I then tried the two different cameras, two different UnoQ and two different media carriers in all permutations but the cameras simply don't show up. It was at that point I realised the cameras were V3 which have IMX708 not IMX 219. A quick check and I can find no IMX708 support for the media carrier. I'm going to give the project a rest for a few days to clear my head as I'm in stupid mistake mode now.

[ptillisch]

@paulrbarnard

A quick check and I can find no IMX708 support for the media carrier.

That is correct. At this time, we only officially support the use of the IMX219 with the UNO Media Carrier and UNO Q.

For the VENTUNO Q we only support the IMX577.

Of course the community is welcome to work to implement their own solutions for supporting additional camera models. However, for those looking for the smoothest path to getting a MIPI CSI camera working with their project, I do recommend selecting the models I specified above.

[philippe86220]

Hi Paul,
If it helps, I can give you the Amazon link for the exact IMX219 camera I’m using.
This is the one that works with my UNO Q + Media Carrier, both with my V1 application and with the new App Lab Camera example.

Waveshare IMX219 Camera Module, Compatible with Raspberry Pi 5, 8MP, MIPI-CSI...

[paulrbarnard]

Well I pointed Claude at it and I now have images. I may have got there myself but this worked remarkably well.

Here is what Claude has to say about it.
VVVVVVVVVV

Update: third-party RPi Camera V2 (IMX219 clone) on UNO Q + Media Carrier: root cause found, workaround streaming

Short version: the clone isn't failing in the sensor or the CSI link. When the driver puts it into reset, the clone pulls down the camera I²C bus. The PCA9555 GPIO expander that controls that reset line is on the same bus, so once the camera is in reset, nothing can take it out again. Leaving the reset line out of the device tree fixes it: the clone now streams at full resolution.

Setup

• UNO Q + Media Carrier, Debian 13, kernel 7.0.0-g122c2c22d838, libcamera 0.4.0 (simple pipeline + soft ISP)
• Third-party IMX219 camera on camera0, configured with arduino-linux-config carrier enable media-carrier camera0=type1-2lanes camera1=none

Symptom

The sensor probes fine (chip ID is read and cam -l lists it), but starting a stream fails:

v4l2_videodevice: /dev/video0: Failed to start streaming: No such device or address
imx219 2-0010: imx219_power_on: failed to enable regulators

What's happening

1. At boot, the PCA9555 (0x26 on CCI bus 0) probes, and the imx219 driver powers the sensor, reads its chip ID and then runtime-suspends it. That drives reset-gpios (PCA9555 pin 0) low and switches cam-pwr-csi0 (PCA9555 pin 1) off.
2. With that line low, the clone loads CCI bus 0. After this, a forced read of the expander fails:

   $ sudo i2cget -f -y <cci0-bus> 0x26 0x00
   Error: Read failed
   

3. On stream start, the driver has to write to the PCA9555 to power the sensor up and release reset. The expander doesn't answer (-ENXIO), so the sensor can never be woken up again.
4. The PCA9555 appears to keep its latched outputs through a warm reboot, probably because it stays powered. After a failure, the next boot starts with the bus already held down, and even the PCA9555 probe fails (pca953x …-0026: failed writing register: -6). Only a full power cycle clears it, which is why the fault can look intermittent.

To isolate the reset line, I first made only cam-pwr-csi0 regulator-always-on. The power errors went away, but the stream then failed on the first sensor register write (Error writing reg 0x0100: -6), and the expander was again unreachable. So the trigger is the reset/XCLR line, not the power rail.

I haven't measured the clone board, so the exact electrical mechanism is my assumption. My guess is that on this clone, the connector's enable/XCLR line also switches the module's own regulators, and an unpowered module drags SDA/SCL down. I don't know why genuine V2 boards don't do this.

Workaround (tested)

A copy of Arduino's qrb2210-arduino-imola-carrier-media-camera-imx219-csi0-2lanes.dtbo with two changes:

 cam-pwr-csi0 {
     ...
     gpio = <&pca9555 1 GPIO_ACTIVE_HIGH>;
+    regulator-always-on;
+    regulator-boot-on;
 };

 sensor@10 {
     compatible = "sony,imx219";
     ...
-    reset-gpios = <&pca9555 0 GPIO_ACTIVE_HIGH>;
 };

reset-gpios is optional in the imx219 driver. With no consumer, PCA9555 pin 0 stays an input, the line floats high, and the sensor uses software standby (register 0x0100) instead.

I built the boot DTB the same way arduino-linux-config does:

fdtoverlay -i qrb2210-arduino-imola-base.dtb -o qrb2210-arduino-imola.dtb \
    qrb2210-arduino-imola-carrier-media.dtbo \
    imx219-csi0-2lanes-clone.dtbo \
    qrb2210-arduino-imola-video_sound-usbc.dtbo

After a cold power cycle, cam -c1 --capture=10 delivered 10 frames at 3272x2464 with no kernel errors, and the image is correct. It has a green cast, because the simple IPA has no imx219.yaml tuning and falls back to uncalibrated.yaml.

If you try this: back up /boot/efi/dtb/qcom/qrb2210-arduino-imola.dtb first. Also, running arduino-linux-config again regenerates that file and removes the change.

Still to check

• A warm reboot still works with the workaround.
• Whether removing reset-gpios alone is enough, without regulator-always-on.
• That a genuine V2 still works with this overlay (no regression).
• Soft-ISP colour tuning for the IMX219.

Questions for the Arduino team

1. On the Media Carrier, is PCA9555 pin 0 (reset-gpios) wired to the camera connector's CAM_GPIO/enable pin?
2. Would you accept a new camera option in arduino-linux-config (for example type1-2lanes-noreset), or would you rather change the default overlay, once the regression checks above pass?

[paulrbarnard]

Claude had me turn power on and off for him/her/it. A 50 year career in engineering, retiring as a VP Engineering, has enabled me to become a remote power and cable switcher for an AI...

Follow-up: the clone V2 fix is a one-line change

Following on from my earlier post: I've narrowed the workaround down, and the only change needed is removing reset-gpios from the camera0 overlay. Forcing the power rail on (regulator-always-on) isn't needed.

Minimal fix

Arduino's qrb2210-arduino-imola-carrier-media-camera-imx219-csi0-2lanes.dtbo, with this one change:

 sensor@10 {
     compatible = "sony,imx219";
     ...
-    reset-gpios = <&pca9555 0 GPIO_ACTIVE_HIGH>;
 };

(If you edit a decompiled .dtbo, also remove the matching reset-gpios entry under __local_fixups__, otherwise fdtoverlay fails.)

What I tested

• The boot DTB was built exactly as before (base + carrier-media + modified camera0 overlay + video_sound-usbc), then I did a warm reboot.
• I ran cam -c1 --capture=10 four times, 8 s apart. Every run gave 10 frames at 3272x2464, with no kernel errors.
• I confirmed the power rail really is switched. The sensor's runtime-PM autosuspend is 1 s, and between runs it showed runtime_status: suspended with both cam-pwr regulators disabled. The last run started from that powered-off state and came up cleanly.
• The previous version (reset removed plus always-on rail) also worked after both a cold boot and a warm reboot.

Conclusion

• Switching cam-pwr-csi0 (PCA9555 pin 1) on and off is harmless for the clone.
• The fault is caused only by the reset/XCLR line (PCA9555 pin 0) being driven low. While it's low, the clone loads CCI bus 0, the PCA9555 on that bus stops answering, and reset can't be released again.
• Without reset-gpios, the imx219 driver uses software standby instead, and nothing drives that line low.

Still open

• Checking that a genuine V2 still works with the no-reset overlay. I'd expect it to, because reset-gpios is optional in the imx219 driver.
• camera1 probably needs the same change (its reset is PCA9555 pin 2). I haven't tested it yet.
• Soft-ISP colour tuning for IMX219. Frames have a green cast with uncalibrated.yaml.

For the Arduino team

The same questions as before still apply, but the change is now very small. Would you prefer:

1. dropping reset-gpios from the stock camera overlays, if you can confirm it doesn't affect genuine modules or anything else wired to pins 0 and 2, or
2. a separate option in arduino-linux-config (for example type1-2lanes-noreset)?

Also, is PCA9555 pin 0 wired straight to the connector's CAM_GPIO/enable pin? That would explain why some modules react so badly to it being held low.

[philippe86220]

Great result Paul!

And I had to smile at your comment about becoming a remote power and cable switcher for an AI after a 50-year engineering career.

Your follow-up makes the problem much clearer to me. What I find particularly interesting is that you have now isolated the workaround to a single change: removing reset-gpios, while the camera power can still be switched normally.

It also explains something that puzzled me from the beginning: how the IMX219 could be detected correctly, yet fail later when starting the stream.

I have learned quite a lot from following your investigation, especially about the interaction between the device tree, the PCA9555 and the camera reset line.

Congratulations on finally getting your images, and thanks for documenting the investigation in such detail!

Philippe

PS: Now that your camera is actually streaming, I would also be very curious to see what happens if you run my V1 application again unchanged. When you tested it previously, it never got as far as producing a RAW frame because STREAMON failed. It would be interesting to see what my RAW processing produces with your fisheye IMX219 now.

[paulrbarnard]

Claude has a final comment

Follow-up 2: two clone V2s working (camera0 + camera1)

I've now tested two clone IMX219 cameras at once, one on each Media Carrier port.

camera1 needs the same fix

camera1's overlay (…-camera-imx219-csi1-2lanes.dtbo) has the same reset-gpios, on PCA9555 pin 2, and it fails the same way with a clone attached. Removing it fixes camera1 too:

 sensor@10 {   /* on cci i2c-bus@1 */
     compatible = "sony,imx219";
     ...
-    reset-gpios = <&pca9555 2 GPIO_ACTIVE_HIGH>;
 };

I built the dual-camera DTB the same way as before (base + carrier-media + camera0 + camera1 + video_sound-usbc). It differs from the stock dual-camera DTB only in the two removed reset-gpios lines.

Results

• cam -l lists both cameras.
• Each camera on its own: 10 frames at 3272x2464, no kernel errors.
• Both at once at the kernel level works. Routed csiphy0 → csid0 → vfe0_rdi0 and csiphy1 → csid1 → vfe1_rdi0 with media-ctl, then streamed raw SRGGB10 1920x1080 from /dev/video0 and /dev/video4 at the same time: ~28-30 fps each, no errors.

Warning if you use the workaround

arduino-linux-config carrier enable … rebuilds /boot/efi/dtb/qcom/qrb2210-arduino-imola.dtb from the stock overlays and silently removes the fix. The clone then fails again, and after a reboot the board may need a full power cycle, because the PCA9555 keeps reset latched low through a warm reboot. Keep a copy of your modified DTB, and re-install it after any carrier reconfiguration.

libcamera limitation (not related to the fix)

The libcamera 0.4 simple pipeline can only stream one camera at a time on this board:

• cam -c1 -c2 silently starts only one of them.
• A second cam process fails with:

  Failed to setup link 'msm_csiphy1'[1] -> 'msm_csid0'[0]: Device or resource busy
  

The simple pipeline routes every sensor through csid0, even though the hardware has two CSIDs and two VFEs, and it works at the V4L2 level (see above). I'm now checking whether a newer libcamera handles this, or whether it needs a pipeline-handler change.

For the Arduino team

Given the arduino-linux-config behaviour, the most robust fix would be to drop reset-gpios from both stock IMX219 overlays (camera0 pin 0, camera1 pin 2), I have confirmed a genuine Raspberry Pi Camera V2 works with the reset fix. I'm happy to prepare the PR.

[paulrbarnard]

@philippe86220 forgot to mention in the previous reply but your app works fine with the fisheye camera.

I really appreciate the help you provided on the way through this

[philippe86220]

That's great to hear, Paul!
I'm very pleased that my app now works with your fisheye camera too. Thank you for testing it and for letting me know.
And you're very welcome — I learned quite a lot myself by following your investigation!
Philippe

[ptillisch]

@paulrbarnard

clone IMX219 cameras

Which specific cameras are you using? You can post a link to the product listing you purchased them from if you like.

@paulrbarnard

I'm happy to prepare the PR.

Please do!