On Tue, Feb 03, 2026 at 10:09:25AM +0200, Jarkko Sakkinen wrote: > 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'.
In addition to phones, there's also category of devices called IP cameras, and managing them ubiquitos to other camera device is a convenience to say the least. And when it comes to pure testing, not all testing where V4L2 is involved is neither about simulating V4L2 hardware nor centered around V4L2 as a topic. It could be e.g., embedded system testing where you want to mock the cameras with simulated content in software only testing (QEMU has V4L2 passthrough) BR, Jarkko
