On Tue, Feb 03, 2026 at 02:10:15AM +0200, Jarkko Sakkinen wrote: > 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.
As for the patch itself, it is RFC i.e., not request for immediate merge. I sent v2 quickly primarily to address the motivation part properly. I'll phase this down a bit, and rework on issues in the uAPI I observed (and remarked in a response to this patch) etc., and generally give people some time to digest. BR, Jarkko
