## Summary `data/systemd/v4l2-relayd@.service` sets `DevicePolicy=closed` with an allow-list that only covers Intel IPU6/IPU7 devices. On platforms where libcamera performs debayering in its software ISP, that ISP must allocate dma-buf from `/dev/dma_heap/*`, which the closed policy denies. The service then relays undebayered data and every consumer sees a black image. The service runs as root, so this is easy to misdiagnose: root bypasses the file permissions on `/dev/dma_heap/*`, but not the cgroup device filter that `DevicePolicy=closed` installs. The identical GStreamer pipeline run by hand from a shell works perfectly, which points investigation away from the unit. ## Affected platforms Any platform relying on libcamera's software ISP rather than a hardware ISP. I hit it on Qualcomm Snapdragon X (x1e80100, CAMSS + OV02E10), where it affects every machine in the family, but it is not Qualcomm-specific — nothing in the allow-list covers dma-heaps for any non-Intel system. ## Reproduction Configure an instance against a libcamera source on such a platform: VIDEOSRC="libcamerasrc ! videoconvert ! videoscale" FORMAT=YUY2 WIDTH=1280 HEIGHT=720 FRAMERATE=30/1 CARD_LABEL="Integrated Camera" Start it and read the journal: ERROR DmaBufAllocator dma_buf_allocator.cpp:119 Could not open any dma-buf provider ERROR SoftwareIsp software_isp.cpp:90 Failed to create DmaBufAllocator object WARN SimplePipeline simple.cpp:620 Failed to create software ISP, disabling software debayering `/dev/video*` then produces black frames. Running the equivalent pipeline directly works and yields correct video at full frame rate: gst-launch-1.0 libcamerasrc ! videoconvert ! videoscale ! \ video/x-raw,format=YUY2,width=1280,height=720,framerate=30/1 ! \ v4l2sink device=/dev/video42 ## Cause From the shipped unit: DeviceAllow=char-drm DeviceAllow=char-media # Intel IPU6 PSYS DeviceAllow=char-intel-ipu6-psys # Intel IPU7 PSYS DeviceAllow=char-psys DeviceAllow=char-video4linux DevicePolicy=closed No entry covers the dma-heap character devices (major 246 here, `dma_heap` in `/proc/devices`). ## Fix Adding one line to the unit resolves it: DeviceAllow=/dev/dma_heap/system rw I suggest naming the system heap specifically rather than allowing the whole `char-dma_heap` class. libcamera's `DmaBufAllocator` probes `/dev/dma_heap/linux,cma` before `/dev/dma_heap/system` and stops at the first provider it can open, so allowing the class makes it select the CMA heap wherever one exists. On boards with a small CMA reservation shared with the display that pool fragments after a few capture cycles and allocation then fails, which returns the stream to black — the same visible symptom, but appearing only after the service has been working for a while. That is a libcamera issue rather than one of yours, and I intend to report it there separately; I mention it only because it affects which form of the fix below is preferable. If you would rather not hard-code a device path, `DeviceAllow=char-dma_heap rw` also restores working video and is the more conventional form; it just inherits that second failure mode on CMA-constrained boards. ## Environment v4l2-relayd 0.2.0 libcamera 0.7.2 v4l2loopback 0.15.4 kernel 7.2.6 aarch64 hardware Dell Inspiron 14 Plus 7441, Qualcomm X1P-64-100 (x1e80100) distribution Arch Linux ARM I am happy to test any patch on this hardware.