Hi Jarkko, 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.
As I think it was pointed out in review comments for v1, the reason behind using v4l2loopback is the use of a downstream driver, which itself is a source of a security risk. If I understand correctly, supporting this (proprietary/downstream vendor drivers) would be the main use case this driver serves? Should this downstream driver be upstreamed to alleviate the security risks, the need for v4l2loopback or similar drivers presumably disappears. Another of the downsides of such proprietary/downstream solutions is they can never be properly integrated into the Linux ecosystem so functionality will remain spotty (limited to specific systems and specific releases of specific distributions) at best. In other words, this driver appears to be orthogonal to solving either of the above two problems the proprietary/downstream solutions have. >From the Open Source libcamera based camera software stack point of view there doesn't seem to be a need for v4l2loopback or another similar driver. The two main reasons for this is that (1) there's no need for glueing something separate together like this and (2) V4L2 isn't a great application interface for cameras -- use libcamera or Pipewire instead. > > 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. I'd really try to avoid involving V4L2 in-kernel implementation when the source of the video is network. V4L2 is meant to be used (when it comes to video) for interfacing video related hardware such as cameras, ISPs and codecs. There are limited number of video output related devices, too, but network is something quite different from these. -- Kind regards, Sakari Ailus
