Message-ID: <aYI2sESZFU6TzeAQ@kernel.org>
Date: Tue, 3 Feb 2026 19:56:00 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: johannes.goede@....qualcomm.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>,
	Sakari Ailus <sakari.ailus@...ux.intel.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 11:27:10AM +0100, johannes.goede@....qualcomm.com wrote:
> Hi Jarkko,
> 
> On 2-Feb-26 21:44, 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.
> > 
> > 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.
> > 
> > PipeWire or any other specific pick of userspace software cannot really
> > address the issue at scale, as e.g., the use of v4l2loopback is both wide
> > and scattered.
> 
> I appreciate your efforts here and if I understand things correctly
> your main goal is to allow people to use the camera of there mobile
> phone for e.g. video-conferencing on a standard linux distro
> (Debian/Fedora/Arch) laptop/desktop right ?
> 
> The problem is that what you're suggesting is basically a much
> improved (using dma-buf is way better) v4l2-loopback driver and
> v4l2-loopback has been blocked from getting merged into the kernel
> because besides the mobile-phone camera use, the other main use-case
> is to allow running proprietary camera stacks like Intel's proprietary
> camerastack and then presenting that to userspace as a standard v4l2
> cam so that userspace apps will just work.

v4l2-loopback is a bit like, or the difference to this at least, is that
it does not really have any life-cycle model or constraints what it is.

And in terms of "if this was  in terms of dual-VB2 pipeline and on
producer side locking into DMA-BUF is how you would want to approach the
topic.

> 
> Personally I think that there are enough valid use-cases for something
> like your proposed vcam driver, also for e.g. CI purposes that I think
> that maybe the V4L2 maintainers should reconsider. But this is not my
> call to make and with both Laurent (in the v1 thread) and Sakari pretty
> much having NACK-ed this, I do not think this is going to go very far
> if you want a mainline solution.

I will phase down attention to the topic a bit. It's been noted. I'm not
sending a new version at least any time soon.

> 
> As Sakari mentioned in this day and age raw V4L2 access is really not
> the best API to acccess cameras. Especially modern smartphone like
> CSI2 MIPI cameras which consist of quite a complex graph of building
> blocks which need to be configured to work together to get a picture.

I will look into this topic.

> 
> So now even when running directly on the hardware (vs the network case)
> apps can no longer directly access v4l2 devices because of the complexity.
> 
> This is already the case on newer x86_64 laptops with MIPI cameras
> instead of USB UVC cams and also on phones running postmarketos.
> 
> The community concensus is that the solution here is for apps to
> access cameras through pipewire. Together with the shift of laptops
> cameras from UVC to "raw" MIPI cameras there also is a shift to
> running applications sandboxed as flatpacks because of the changing
> "cyber" security landscape. This is why pipewire was chosen because
> it also solves the accessing cameras from a sandbox issue.
> 
> Both Firefox and chrome(ium) already support pipewire for cameras
> OOTB. In chrome it requires setting a config setting and maybe for
> upstream Firefox too (it is enabled in Fedora's Firefox by default).
> 
> Given that pipewire is seen as the way to access all cameras in
> the future and that we are already moving in that direction (e.g.
> Fedora has been shipping this OOTB since Fedora 42) IMHO your time
> would be better spend helping out there.
> 
> E.g. add support to popular software for sharing smartphone cameras
> to represent the frames received over the network as a video sources
> in pipewire and check if this works in Firefox + Chrome and write
> patches or file issues for other apps to also add pipewire camera
> access support.
> 
> As was mentioned in the earlier thread for making the camera show
> up as a source in pipewire you could try using the pipewire sink
> element in gstreamer, assuming you can make the phone-cam available
> as a gstreamer src element, you may be able to prototype things
> then using just a gst-launch cmd from the shell.

With a quick ACM search mocking /dev/videoX is not alien approach. And
when it is done it's not focused-on-V4L2 type of situation but more like
being able to drive a software platform without associated hardware. And
when doing something like this with QEMU, it is really nice to still
have uncluttered and stackless-as-possible data paths,

[and I at lest would not try to run 'qemu' through camerify from
libcamera-tools]

You can project from that at least that there are other applications too
for "software-defined camera", and what people do in academic world has
reflection to R&D in industry (e.g. drone industry). It's an asset to
use software as far as possible even when doing embedded platforms.

Thanks for the pointers anyhow. This was very informative. These are
great lore references too.

> 
> Regards,
> 
> Hans

BR, Jarkko

Powered by blists - more mailing lists