Message-ID: <20260203205742.GB11369@killaraus>
Date: Tue, 3 Feb 2026 22:57:42 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>,
	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>,
	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

Hello Jarkko,

On Tue, Feb 03, 2026 at 03:36:59AM +0200, Jarkko Sakkinen wrote:
> 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:
> > > 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 :-)

I really hope we'll provide a solution much faster than that :-)

> > Like, first off, where would I use libcamera or Pipewire? There's
> > no well-defined target other than kernel in this problem.

PipeWire is becoming the de facto media server on desktop systems, for
both audio and video. It has been shipped by distributions for a while
for audio, and is the core component that allows screen capture (and
therefore screen sharing in video conferencing) on Wayland-based
systems. For video, PipeWire support has most notably been integrated in
WebRTC, used by both Firefox and Chrome. The number of applications
using PipeWire is growing, OBS has recently received support for
PipeWire sources for instance. If you need to use it in an application
that requires a V4L2 capture device, the pw-v4l2 script emulates the
V4L2 API to provide a quick stopgap measure until applications get
native PipeWire support.

libcamera solves an orthogonal problem, which is control of raw camera
sensors and ISPs typically found in mobile and embedded devices, and now
increasingly in laptops as well (Intel IPU3, IPU4, IPU6 and IPU7).
Applications typically don't use libcamera directly, but interface it
with GStreamer (libcamerasrc element) or PipeWire (which has native
libcamera support).

While I understand that libcamera and PipeWire may be quite new for a
large number of users, the ecosystem is moving in that direction, and
both projects are very active.

> > > > 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.

-- 
Regards,

Laurent Pinchart

Powered by blists - more mailing lists