Regression on IPU7 / OV02C10 (Lunar Lake): camera works on HAL e4a08b1, black frames on b94eee8 #52

Activity

1. xsteadfastx

   added 2 commits that reference this issue on Sep 4, 2026

   feat(coltrane): enable the IPU7 webcam

   ...

   c7efb28

   fix(coltrane): track upstream HEAD for the IPU7 camera HAL and bins

   ...

   9830c57
2. xsteadfastx commented on Sep 4, 2026

   

   xsteadfastx

   on Sep 4, 2026

   More actions

   Data point: HAL HEAD (11d8aff0) works on a Dell XPS 13 9350 / OV02C10 / IPU7

   Same laptop model and sensor as the report, but a different distro and build path, so this is a data point rather than a contradiction.

   Setup

   • Dell XPS 13 9350 (2024), Lunar Lake, OV02C10 (OVTI02C1:00) behind CVS chip INTC10DE:00 (protocol 1.0)
   • NixOS, kernel 6.18.49; both repos built from source, not the ppa:oem-solutions-group/intel-ipu7 packages
   • Out-of-tree intel-ipu7-psys from ipu7-drivers 495acc90, built against the in-tree IPU7 core (ipu_bridge not blacklisted), plus intel_cvs from intel/vision-drivers 845d6f8 for the sensor-ownership handshake; then icamerasrc → v4l2-relayd
   • Full config: hosts/coltrane/ipu7.nix

   A/B result

   Each HAL was run with its own /etc/camera bind-mounted inside a separate mount namespace. That matters: the two versions ship an identical ov02c10-uf.json but a different OV02C10_MSHW0550.IPU7X.bin graph config, which seemed like the likeliest candidate for the regression, so mixing one version's libs with the other's config would have invalidated the comparison.

   150 frames from icamerasrc at 1280x720 NV12, reading the last frame:

   HAL	bins	last-frame Y mean	max
   e4a08b1 (2026-05-20)	cead732 (2026-04-23)	92.65	187	image
   11d8aff0 (2026-08-12)	adf55525 (2026-07-17)	92.99	187	image

   Same live scene, so a 0.34 difference is noise. The regression does not reproduce here on either side, and I've dropped the last-known-good pins from my config.

   One measurement caveat for anyone bisecting this

   The HAL's first buffer is always flat (NV12 Y=16, U=V=128), frames 1–5 are ≈Y=0, and auto-exposure only converges around frame ~30 (~1 s @ 30 fps). So any capture using num-buffers=1..10 reads as "solid black" on a perfectly working camera — that cost me a while. This would not explain a black image in a live viewer, so it likely doesn't account for the original report, but it does invalidate short automated captures.

   Related, in case it saves someone else the detour: if you sandbox this test in an unprivileged user namespace (unshare -rm), every HAL version fails with CameraHal: camera open num couldn't be 0 — the user namespace breaks the HAL's shared-memory open-counter. It looks like a HAL bug and isn't one; the bind-mount harness needs real root. Worth running a known-good control before trusting any failure from a sandboxed run.

   Happy to test patches or other revision pairs on this hardware.