Message-ID: <aYFRO1XdtEUkbSCg@kernel.org>
Date: Tue, 3 Feb 2026 03:36:59 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: linux-media@...r.kernel.org, jani.nikula@...ux.intel.com,
	anisse@...ier.eu, oleksandr@...alenko.name,
	linux-integrity@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Hans Verkuil <hverkuil@...nel.org>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Jacopo Mondi <jacopo.mondi@...asonboard.com>,
	Ricardo Ribalda <ribalda@...omium.org>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2] media: Virtual camera driver

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

Powered by blists - more mailing lists