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

[tugkanbatu]

Hardware

• Dell XPS 13 9350 (2024), Intel Core Ultra 5 226V (Lunar Lake)
• Sensor: OmniVision OV02C10 (ACPI OVTI02C1) via Intel IPU7 (PCI 8086:645d)

OS / kernel

• Ubuntu 24.04, kernel 6.17.0-1025-oem

Summary
A userspace HAL/imaging-lib snapshot bump regressed the camera. The sensor still
enumerates (kernel detects it, /dev/video0 loopback present) but every app receives
black frames — the icamerasrc/v4l2-relayd pipeline no longer delivers.

Last good → first bad (packages from ppa:oem-solutions-group/intel-ipu7)

• libcamhal-ipu7x: 0git202605200138.e4a08b1 (works)
  → 0git202606180621.b94eee8 (black frames)
• libia-* set: 0git202604230632.cead732 (works)
  → 0git202606170948.d235697 (black frames)
  So the regression is in ipu7-camera-hal between e4a08b1 and b94eee8,
  and/or the ipu7-camera-bins / libia-* set between cead732 and d235697.

Kernel side unchanged and healthy across the regression
dmesg: "intel-ipu7 ...: Found supported sensor OVTI02C1:00" / "Connected 1 cameras".
Firmware authenticates fine. No kernel update was involved.

Recovery
Reverting the whole ipu7x userspace set to Dell's validated somerville build
(libcamhal-ipu7x 0git202510170946.ec24db2, libia-* 0git202509280950) restores
a working camera on the same kernel.

[xsteadfastx]

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.