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

## 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 master at commit `845d6f8` (includes PR #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:

```bash
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:

```bash
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

- intel/ipu7-drivers#26 — "Not working on Dell Pro Plus 14, PB14250" (sister Lunar Lake SKU; OPEN)
- intel/vision-drivers#33 — "Camera doesn't work on Dell Pro Max 14 Premium MA14250" (sister SKU; OPEN)
- intel/vision-drivers#31 — "IPU7 camera non-functional after building vision-drivers" — addressed by intel/vision-drivers PR #38 (merged 2026-05-07), which I have applied.
- Ubuntu Launchpad #2138991 — "Dell 16 Premium DA16250 webcam (OV02C10) not working" — different sensor, similar Lunar Lake platform class.

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