** Description changed: - Ubuntu 26.04, v4l2-relayd 0.2.0-0ubuntu1, libcamera 0.7.0, kernel 7.0.0-31-generic. - Hardware: Dell XPS 13 9320, IPU6 + ov01a10 MIPI camera, in-tree kernel driver - (no intel-ipu6-dkms), libcamera simple pipeline + software ISP. + [ Impact ] - With VIDEOSRC=libcamerasrc, the relay produces only black frames. Two independent - causes: + On systems using MIPI cameras with in-tree IPU6 drivers and libcamera + SoftISP (e.g. Dell XPS 13 9320, Lenovo ThinkPad X1 Carbon Gen 10/11), + configuring v4l2-relayd with VIDEOSRC=libcamerasrc fails completely and + delivers only black frames or fails to negotiate caps. - 1. Sandbox blocks the software ISP. - [email protected] sets DevicePolicy=closed and allowlists only drm/media/ - psys/video4linux. libcamera's SoftISP needs /dev/udmabuf or /dev/dma_heap/*: + Two independent issues cause this failure: + 1. systemd sandboxing: [email protected] sets DevicePolicy=closed and only allowlists drm, media, psys, and video4linux. libcamera's SoftISP DmaBufAllocator requires /dev/udmabuf or /dev/dma_heap/* to allocate buffers. Without them, SoftISP debayering fails immediately with: + "ERROR DmaBufAllocator dma_buf_allocator.cpp:119 Could not open any dma-buf provider" + "WARN SimplePipeline simple.cpp:620 Failed to create software ISP, disabling software debayering" + 2. GStreamer caps negotiation and latency: SoftISP outputs RGB formats (RGBA/ABGR), whereas the relay previously applied the configured FORMAT (default YUY2) directly to libcamerasrc caps with no conversion, causing immediate negotiation failure (-4). Furthermore, software debayering introduces latency spikes that stall upstream libcamera threads without an intermediate leaky queue. Additionally, v4l2loopback default buffer limits can lead to v4l2bufferpool allocation errors. - ERROR DmaBufAllocator dma_buf_allocator.cpp:119 Could not open any dma-buf provider - ERROR SoftwareIsp software_isp.cpp:88 Failed to create DmaBufAllocator object - WARN SimplePipeline simple.cpp:620 Failed to create software ISP, disabling software debayering + Without this fix, MIPI cameras relying on the Linux in-tree IPU6 + + libcamera SoftISP stack cannot be used via v4l2-relayd in applications + that require standard v4l2loopback devices (e.g. Chrome, Zoom, Firefox). - The allowlist (note the psys entries) predates the SoftISP path. Fix: add - DeviceAllow=/dev/udmabuf rw - DeviceAllow=/dev/dma_heap/system rw + [ Fix ] - 2. FORMAT=YUY2 can never negotiate with libcamerasrc. - The SoftISP outputs only RGB formats (here RGBA/ABGR8888 etc., verified with - cam -I), and the relay applies FORMAT directly to libcamerasrc's caps with no - conversion, so the pipeline fails instantly: + 1. In data/systemd/[email protected]: + Add DeviceAllow=char-dma_heap and DeviceAllow=/dev/udmabuf rw so libcamera's DmaBufAllocator can initialize properly for SoftISP. + 2. In src/v4l2-relayd.c: + Insert videoscale, videoconvert, and a leaky queue between the negotiated src_pad and appsink. This enables proper format and resolution conversion (e.g. RGBA from SoftISP into appsink caps) and absorbs debayering latency spikes without stalling upstream libcamera. + 3. In src/v4l2-relayd.c: + Link explicitly from the negotiated src_pad rather than element-level to properly handle multi-pad VIDEOSRC bins (such as libcamerasrc). + 4. In data/etc/modprobe.d/v4l2-relayd.conf: + Set max_buffers=8 to prevent v4l2bufferpool allocation failure in GStreamer v4l2sink. - gst_libcamera_src_task_enter (): streaming stopped, reason not- - negotiated (-4) + [ Test Plan ] - Reproducible standalone; even matching libcamerasrc's own negotiated caps - verbatim fails when set as a fixed capsfilter: - gst-launch-1.0 libcamerasrc ! video/x-raw,format=RGBA,width=1280,height=800,colorimetry=sRGB,framerate=30/1 ! fakesink - while unconstrained negotiation works: - gst-launch-1.0 libcamerasrc ! videoconvert ! fakesink - -> caps = video/x-raw, format=RGBA, 1280x800, sRGB, 30/1 + 1. On a system with an IPU6 camera or libcamera SoftISP device: + - Configure /etc/default/v4l2-relayd with: + VIDEOSRC=libcamerasrc + - Restart service: + systemctl restart v4l2-relayd + 2. Verification without the fix: + - Check journalctl -u v4l2-relayd: + Shows "Could not open any dma-buf provider" and negotiation error (-4). + - Video device /dev/videoN outputs black frames or pipeline terminates. + 3. Verification with the fix: + - v4l2-relayd starts cleanly without dma-buf errors. + - Run: + gst-launch-1.0 v4l2src device=/dev/videoN ! videoconvert ! autovideosink + or test via browser/webcam app. + - Camera video stream renders smoothly in color without stalls or dropped pipeline errors. + 4. Non-regression test: + - Test default VIDEOSRC=videotestsrc and existing V4L2 device sources. + - Service starts cleanly and delivers virtual camera video as expected. - The relay pipeline needs a videoconvert between source and the appsrc caps (or - equivalent) for the libcamerasrc case. + [ Where problems could occur ] - Net effect: on the default-supported MIPI camera path (in-tree IPU6 + libcamera), - v4l2-relayd delivers black frames out of the box. A plain - gst-launch-1.0 libcamerasrc ! videoconvert ! queue ! v4l2sink device=/dev/videoN - into the same v4l2loopback device works, confirming the stack itself is fine. + - Sandboxing: Adding /dev/udmabuf and char-dma_heap slightly broadens device access for the v4l2-relayd daemon, but both are standard memory allocation interfaces restricted to the relay process. + - GStreamer pipeline: Adding videoscale, videoconvert, and a leaky queue introduces minor CPU overhead during format conversion, but it is strictly required when the source format differs from the sink format. For native formats, videoconvert acts as passthrough. + - v4l2loopback max_buffers=8: Slightly increases kernel memory allocated per loopback device (transient buffers for video frames), well within normal system limits. - Also worth noting: the shipped default VIDEOSRC=videotestsrc means the - libcamerasrc path gets no coverage in a default install. + [ Other Info ] - ProblemType: Bug - DistroRelease: Ubuntu 26.04 - Package: v4l2-relayd 0.2.0-0ubuntu1 - ProcVersionSignature: Ubuntu 7.0.0-31.31-generic 7.0.14 - Uname: Linux 7.0.0-31-generic x86_64 - ApportVersion: 2.34.1-0ubuntu0.1 - Architecture: amd64 - CasperMD5CheckResult: pass - CurrentDesktop: ubuntu:GNOME - Date: Sun Sep 6 12:00:18 2026 - DistributionChannelDescriptor: - # This is the distribution channel descriptor for the OEM CDs - # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor - canonical-oem-somerville-jammy-amd64-20220504-33 - InstallationDate: Installed on 2023-08-25 (1108 days ago) - InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - somerville-jammy-amd64-20220504-33 - ProcEnviron: - LANG=en_US.UTF-8 - PATH=(custom, no user) - SHELL=/bin/bash - TERM=xterm-256color - XDG_RUNTIME_DIR=<set> - SourcePackage: v4l2-relayd - UpgradeStatus: Upgraded to resolute on 2026-06-10 (88 days ago) - mtime.conffile..etc.default.v4l2-relayd: 2026-09-06T11:24:43.009736 + Debdiff prepared for Resolute (0.2.0-0ubuntu1.1). + Sponsored by Sebastien Bacher.
-- 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
