Thanks @herrsaalfeld for the detailed follow-up and isolating the bufferpool allocation failure.
All three issues trace back to the relay stack expecting a legacy hardware ISP / v4l2 device rather than a modern Software ISP with libcamerasrc: 1. Sandbox dma-buf blocking: libcamera's SoftISP DmaBufAllocator relies on /dev/udmabuf and /dev/dma_heap/system to allocate frame buffers. With DevicePolicy=closed in the systemd unit, these devices are blocked unless explicitly allowed. 2. Caps negotiation: SoftISP pipelines typically produce formats like RGBx/BGRx rather than raw YUY2. Without dynamic conversion between the backend input pad and appsink, GStreamer cannot negotiate caps between libcamerasrc and the relay's appsink. 3. Buffer starvation on v4l2loopback: GStreamer's v4l2sink requests a minimum of 3 mmap buffers through its internal v4l2bufferpool. Because v4l2loopback defaults to max_buffers=2, the pipeline fails immediately after two frames with error -5. I have prepared a patch and debdiff for v4l2-relayd (0.2.0-0ubuntu2) that resolves all three issues out of the box: - data/systemd/[email protected]: Adds DeviceAllow for char-dma_heap, /dev/udmabuf rw, and /dev/dma_heap/system rw. - src/v4l2-relayd.c: Inserts videoscale and videoconvert elements between the input element and appsink so formats and frame sizes negotiate cleanly. - data/etc/modprobe.d/v4l2-relayd.conf: Appends max_buffers=8 to the v4l2loopback options so the kernel driver allocates enough buffers for GStreamer's v4l2sink. Regarding exclusive_caps: once the relay service starts and opens the loopback device in OUTPUT mode, v4l2loopback with exclusive_caps=1 will announce the CAPTURE capability to client applications (like Zoom or Chromium). Below is the SRU template. I have also attached the tested debdiff (v4l2-relayd_0.2.0-0ubuntu2.debdiff). [Impact] Users on platforms with Software ISP (such as IPU6 ov01a10 on Dell XPS 13 9320) cannot use v4l2-relayd with VIDEOSRC=libcamerasrc. The service fails due to dma-buf sandbox denial, caps negotiation mismatch, and bufferpool starvation in v4l2loopback. [Test Plan] 1. On affected hardware or in a VM with v4l2loopback installed: Configure /etc/default/v4l2-relayd with VIDEOSRC=libcamerasrc (or test with videotestsrc ! v4l2sink). 2. Start the v4l2-relayd service or trigger on-demand activation. 3. Verify that the loopback device /dev/videoX streams without bufferpool allocation errors (-5). 4. Verify that applications (such as Zoom, Chromium, or cheese) can capture video from the virtual device. [Where problems could occur] - Adding videoscale and videoconvert introduces minimal CPU overhead during format conversion, but only when the native source format does not match the configured output. For native YUY2 streams, videoconvert acts as a passthrough. - Allowing /dev/udmabuf and /dev/dma_heap/system relaxes the device sandbox specifically for camera buffer allocation, but DevicePolicy remains closed for all other devices. - Setting max_buffers=8 slightly increases maximum kernel memory reservation for the loopback device, but only while buffers are active. Attached: v4l2-relayd_0.2.0-0ubuntu2.debdiff ** Patch added: "v4l2-relayd_0.2.0-0ubuntu2 debdiff for SoftISP and libcamerasrc support" https://bugs.launchpad.net/ubuntu/+source/v4l2-relayd/+bug/2166611/+attachment/5998287/+files/v4l2-relayd_0.2.0-0ubuntu2.debdiff ** Changed in: v4l2-relayd (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2166611 Title: v4l2-relayd unusable with libcamerasrc/SoftISP: sandbox blocks dma-buf allocator, and YUY2 caps never negotiate (black frames) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/v4l2-relayd/+bug/2166611/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
