Same issue on a different Dell model + a detailed workaround, in case it
helps.
Hardware / software
- Dell XPS 14 DA14260, BIOS 1.8.2, Intel Core Ultra (Panther Lake), IPU7 PCI
8086:b05d (subsystem 1028:0db9)
- Sensor OVTI08F4 (ov08x40 from linux-modules-ipu6-generic:
/lib/modules/7.0.0-42-generic/ubuntu/dkms/ipu6/ov08x40.ko.zst), 2 CSI-2 lanes
("bind ov08x40 10-0036 nlanes is 2 port is 0")
- Ubuntu 26.04.1, kernel 7.0.0-42-generic, intel_ipu7 (staging), firmware
intel/ipu/ipu7ptl_fw.bin
- libcamera 0.7.0-1ubuntu2 (simple pipeline + software ISP), pipewire 1.6.2,
wireplumber 0.5.13
- Also loaded: usbio, intel_cvs. dmesg: "int3472-discrete INT3472:00: GPIO type
0x02 unknown; the sensor may not work" (the sensor does work here at full
resolution)
Symptoms
- Camera unusable in Firefox/Chromium/Brave (snap) and Cheese; PipeWire (and
audio with it) crashes when an app asks for <= 1080p.
Findings
1. Binned 1928x1088 mode is broken on IPU7 too (same as this bug):
- raw capture via "cam -s role=raw": 1928x1088 -> values up to 65535 (median
65535) on 10-bit data, ~3.6 fps, kernel logs
"intel_ipu7_isys ... IPU_INSYS_RESP_TYPE_PIN_DATA_READY ... error group 3
code 18" for every frame;
- 3856x2176 -> max 1023, 28.57 fps, no kernel error.
2. libcamera picks the smallest sensor mode that fits the request, so any
request <= 1928x1088 uses the broken mode. The corrupt frames then
abort() libcamera (Ubuntu builds with assertions): std::array<unsigned,64>
out of range in SwStatsCpu::processBayerFrame2 (called from
DebayerEGL::process; same with LIBCAMERA_SOFTISP_MODE=cpu/gpu). This kills
the pipewire process (SIGABRT):
"array:210 ... operator[] ... Assertion '__n < this->size()' failed",
"pipewire.service: Main process exited, code=dumped, status=6/ABRT".
Reproducer: cam -c1 -s width=1280,height=720,pixelformat=BGRA8888
--capture=5 (abort), width=3848,height=2176 works.
3. The image is also rotated by 180 degrees and has a green cast (no sensor
properties/tuning for ov08x40 in libcamera 0.7.0).
Measured mean RGB 120/130/118 before correction.
Workaround (works, tested with Chromium and Brave getUserMedia: 1280x720@30, 4
successive open/close cycles at ~0.9 s each)
- v4l2loopback (exclusive_caps=1, label "Virtual Camera") + v4l2-relayd,
capture forced to the full mode and scaled down:
libcamerasrc ! video/x-raw,width=3848,height=2176,format=BGRx ! videorate !
video/x-raw,framerate=30/1 ! videoscale !
video/x-raw,width=1280,height=720 ! videoflip method=rotate-180 !
videoconvert ! capsfilter caps=video/x-raw,format=YUY2,...
- Removed pipewire-libcamera / libspa-0.2-libcamera so PipeWire never starts
the libcamera pipeline (avoids the crash).
- Extra pitfalls found with v4l2-relayd 0.2.0 (some overlap with LP #2172582):
a. Trailing bare caps in VIDEOSRC -> "no element video" (use capsfilter).
b. The service's DevicePolicy=closed blocks /dev/dma_heap, so libcamera logs
"Could not open any dma-buf provider", disables the software
ISP and negotiation fails (not-negotiated, BA10). Needs
DeviceAllow=char-dma_heap rw in a drop-in.
c. v4l2-relayd sets the input pipeline base_time to the OUTPUT pipeline's
base_time (relayd.c: backend_pipeline_create), i.e. the relay's age,
but libcamerasrc timestamps start at 0. I measured: first real frame
appears after ~1 s + 0.2 s per second of relay uptime
(7 s -> 2 s, 12 s -> 3 s, 17 s -> 4 s, 22 s -> 5 s; Brave: 7.7 s of black
at ~43 s uptime, black "forever" after minutes).
Reproduced in a standalone Python harness (pipeline with base_time set N s
in the past): PTS starts at 0 while running time = N,
and the pipeline runs ~5x too fast to "catch up" (~150 fps). clocksync
sync-to-first=true and a live compositor do not fix it.
d. libcamera 0.7.0 does not survive being restarted several times in the same
process (v4l2-relayd re-uses it for each client): after
1-2 sessions no more frames, or another abort (std::array<double,1024> in
the CPU soft-ISP path).
- Final workaround: replaced v4l2-relayd's ExecStart by a ~200-line Python
relay: the capture runs in a fresh "gst-launch-1.0 libcamerasrc ... ! fdsink"
process per session, the output appsrc timestamps frames itself
(do-timestamp), clients are detected with the same V4L2_EVENT_PRI_CLIENT_USAGE
event as v4l2-relayd, plus a small gray-world white balance on chroma for the
green cast. Result: 0.7-0.9 s to first image whatever the idle
time, ~30 fps, 0 kernel error. I can share the script if useful.
Request
- Please carry the "do not expose the 1928x1088 binned mode" patch as SAUCE for
ipu7 as well (this report: Dell XPS 14 DA14260, Panther Lake).
- libcamera: SwStatsCpu should clamp its histogram index so corrupt frames
cannot abort the process (and kill PipeWire).
- v4l2-relayd: the libcamerasrc/base_time/restart issues above deserve a fix or
a documented configuration.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172303
Title:
ov08x40: 1928x1088 binned mode delivers ~3.7 fps on 2-lane Dell Pro
Max 16 Premium (IPU6 + CVS) – webcam unusable at <=1080p
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172303/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
