On Mon, Feb 02, 2026 at 10:44:21PM +0200, Jarkko Sakkinen wrote: > Already a quick Google survey backs strongly that OOT drivers (e.g., > v4l2loopback) are the defacto solution for streaming phone cameras in > video conference calls, which puts confidential discussions at risk. > > It can be also claimed that there's enough OOT usage in the wild that > possible security bugs could be considered as potential zerodays for the > benefit of malicious actors. > > The situation has been stagnated for however many years, which is > unsastainable situation, and it further factors potential security > risks. Therefore, a driver is needed to address the popular use case. > > vcam is a DMA-BUF backed virtual camera driver capable of creating video > capture devices to which data can be streamed through /dev/vcam after > calling VCAM_IOC_CREATE. Frames are pushed with VCAM_IOC_QUEUE and recycled > with VCAM_IOC_DEQUEUE. Zero-copy semantics are supported for shared DMA-BUF > between capture and output. > > This enables efficient implementation of software, which can manage network > video streams from phone cameras, and map those streams to video devices. > > PipeWire or any other specific pick of userspace software cannot really > address the issue at scale, as e.g., the use of v4l2loopback is both wide > and scattered. > > Signed-off-by: Jarkko Sakkinen <[email protected]>
After learning a bit more about the topic and for future updates I will drop YUYV. NV12, MJPEG, and additionally RGBX32 and XRGB32 for testing and GPUs define pretty well the requirements for a software define device, and limit the applicability of "proprietary risk" (as that was the main concern raised). I honestly did not have idea what would be an appropriate subset of formats to constraint the driver initially. In addition, a better name for this module would probably be swcam as it does not mix up with those pre-existing devices starting with the letter 'v'. BR, Jarkko
