On Tue, Feb 03, 2026 at 12:50:06AM +0200, Sakari Ailus wrote: > 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.
My goal is not to proactively support proprietary drivers, and I don't know how to measure such incentive or risk, when it comes to video drivers. And besides there is e.g. FUSE. > > 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. While I get this argument isolated, it does not match the observed reality, and does not provide tools to address the core issue. I will be in my grave before I've fixed the world like you are suggesting :-) Like, first off, where would I use libcamera or Pipewire? There's no well-defined target other than kernel in this problem. > > > > > 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. I'd look at the usage patterns in the field too. It is pretty obvious that there is a significant gap what users want and expect when it comes to this debate. > > -- > Kind regards, > > Sakari Ailus BR, Jarkko
