Skip to content

OV08X40 binned mode (1928×1088) produces capture buffers full of 0xFFFF on Lunar Lake (Dell PA14250) #70

@MPvHarmelen

Description

@MPvHarmelen

Summary

On a Dell Pro 14 Premium PA14250 (Lunar Lake), capturing from /dev/video0 while the OmniVision OV08X40 (OVTI08F4) is in its 1928×1088 binned mode produces buffers where 99.91% of the 10-bit Bayer samples are 0xFFFF. Only the first ~1928 + 24 pixels of each frame contain real sensor data; the remainder is the buffer's init pattern. The frame rate drops to 3.59 fps (vs the expected sensor rate). The same hardware in 3856×2176 native mode delivers fully valid 10-bit data at 28.57 fps.

The valid-pixel positions are deterministic across frames (same first row + 24 pixels of the second row in every frame), and the buffer reported by ISYS is 26,112 pixels (52,224 bytes) larger than the nominal 1928 × 1088 × 2 = 4,195,328 bytes.

Hardware

  • Laptop: Dell Pro 14 Premium PA14250
  • CPU: Intel Core Ultra (Lunar Lake)
  • Camera sensor: OmniVision OV08F40 / OV08X40 (ACPI HID OVTI08F4, kernel driver ov08x40)
  • IVSC: Synaptics SVP7500 (USB ID 06CB:0701, firmware version 84.95)

Software

  • OS: Ubuntu 26.04 LTS
  • Kernel: 7.0.0-15-generic
  • In-kernel modules in use: intel_ipu7, intel_ipu7_isys (staging), ipu_bridge, int3472-discrete, ov08x40
  • DKMS modules in use:
    • intel-ipu7-dkms (Ubuntu archive, 0~git202602091007.a88b1909-0ubuntu1) — provides intel-ipu7-psys, ipu-acpi, etc.
    • intel-usbio-dkms (Ubuntu archive, 0~git202510282139.ee221eca-0ubuntu1) — provides usbio, gpio_usbio, i2c_usbio
    • vision-driver/1.0.0 — built from https://github.com/intel/vision-drivers master at commit 845d6f8 (includes PR media: staging/ipu7: Disallow source multiplexing #38 "fix probe failure on Protocol 1.0 devices (LNL)"). Without that PR the camera does not enumerate at all.

Reproducer (terminal-only)

Capture three frames of raw 10-bit Bayer in binned mode and inspect:

cam -c 1 --capture=3 \
  -s width=1928,height=1088,pixelformat=SGRBG10 \
  --file=/tmp/bin-#.bin

python3 - <<'EOF'
for i in range(3):
    fn = f'/tmp/bin-cam0-stream0-{i:06d}.bin'
    data = open(fn, 'rb').read()
    n = len(data) // 2
    ffff = sum(1 for j in range(0, len(data), 2)
               if (data[j] | (data[j+1] << 8)) == 0xFFFF)
    print(f'{fn}: {n} pixels, {ffff} == 0xFFFF ({100*ffff/n:.2f}%), {n-ffff} valid')
EOF

Output (deterministic):

/tmp/bin-cam0-stream0-000000.bin: 2123776 pixels, 2121824 == 0xFFFF (99.91%), 1952 valid
/tmp/bin-cam0-stream0-000001.bin: 2123776 pixels, 2121824 == 0xFFFF (99.91%), 1952 valid
/tmp/bin-cam0-stream0-000002.bin: 2123776 pixels, 2121824 == 0xFFFF (99.91%), 1952 valid

The same capture in 3856×2176 native mode is fully valid:

cam -c 1 --capture=3 \
  -s width=3856,height=2176,pixelformat=SGRBG10 \
  --file=/tmp/nat-#.bin

python3 - <<'EOF'
data = open('/tmp/nat-cam0-stream0-000000.bin', 'rb').read()
n = len(data) // 2
oob = sum(1 for j in range(0, len(data), 2)
          if (data[j] | (data[j+1] << 8)) >= 1024)
print(f'pixels with value >= 1024 (out of declared 10-bit range): {oob}/{n}')
EOF

Yields 0/8425472.

The frame-rate difference is also visible in cam --capture output:

# Native, 3856×2176:
1942.262752 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 16850944
1942.297751 (28.57 fps) cam0-stream0 seq: 000001 bytesused: 16850944

# Binned, 1928×1088 (~8× slower):
1943.407838 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 4247552
1943.686327 (3.59 fps) cam0-stream0 seq: 000001 bytesused: 4247552

3.59 fps ≈ once per 280 ms, consistent with a wait-for-frame-then-timeout-and-deliver-empty-buffer path.

Sensor / pipeline state during the failing capture

Active media-controller format on every pad of the chain when binned-mode capture is active:

ov08x40 14-0036, pad 0 (SOURCE):
    [stream:0 fmt:SGRBG10_1X10/1928x1088 field:none]

Intel IPU7 CSI2 0, pad 0 (SINK), pad 1 (SOURCE):
    [stream:0 fmt:SGRBG10_1X10/1928x1088 field:none
     crop.bounds:(0,0)/1928x1088
     crop:(0,0)/1928x1088]

Intel IPU7 ISYS Capture 0 (/dev/video0):
    1928×1088 BG10

Driver banner from this boot:

intel-ipu7 0000:00:05.0: Found supported sensor OVTI08F4:00
intel-ipu7 0000:00:05.0: Connected 1 cameras
intel-ipu7 0000:00:05.0: CSE authenticate_run done
intel_ipu7_isys: module is from the staging directory, the quality is unknown, you have been warned.
ov08x40 i2c-OVTI08F4:00: supply dovdd not found, using dummy regulator
ov08x40 i2c-OVTI08F4:00: supply avdd not found, using dummy regulator
ov08x40 i2c-OVTI08F4:00: supply dvdd not found, using dummy regulator
intel_ipu7_isys.isys intel_ipu7.isys.40: bind ov08x40 5-0036 nlanes is 2 port is 0
intel_ipu7_isys.isys intel_ipu7.isys.40: All sensor registration completed.

(int3472-discrete INT3472:00: GPIO type 0x02 unknown is also printed, but the in-kernel int3472 driver continues parsing, registers the INT3472:00-dvdd regulator, and the camera enumerates correctly. I do not believe this warning is on the path to the binned-mode buffer-fill issue.)

Offer to gather more diagnostic information

I have the laptop and a working capture pipeline at native resolution. Things I can produce on request:

  • Full dmesg from a clean boot, with any specific dynamic-debug categories enabled (e.g. intel-ipu7, intel_ipu7_isys, ov08x40, ipu_bridge).
  • media-ctl -d /dev/media0 -p topology dump.
  • v4l2-ctl --device=… --list-formats-ext, --list-frameintervals, etc., for any subdev.
  • Register dumps over i2c if a register-read tool / sequence is provided.
  • trace-cmd / ftrace captures of the streaming start sequence in binned mode.
  • Test builds with experimental patches.

Related issues

Remarks

This issue was drafted by Claude, but I stay responsible for its content.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions