linux-kernel - Re: [RFC PATCH v2] media: Virtual camera driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260203211818.GD11369@killaraus>
Date: Tue, 3 Feb 2026 23:18:18 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: johannes.goede@....qualcomm.com
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
	Jarkko Sakkinen <jarkko@...nel.org>, linux-media@...r.kernel.org,
	anisse@...ier.eu, oleksandr@...alenko.name,
	linux-integrity@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Hans Verkuil <hverkuil@...nel.org>,
	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 03:19:13PM +0100, johannes.goede@....qualcomm.com wrote:
> On 3-Feb-26 14:20, Jani Nikula wrote:
> > On Tue, 03 Feb 2026, johannes.goede@....qualcomm.com wrote:
> >> 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.
> > 
> > ...
> > 
> >> 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.
> > 
> > Why is v4l2-loopback problematic from the perspective of facilitating
> > running proprietary camera stacks, but pipewire isn't?
> 
> Once pipewire mostly works everywhere for camera access then indeed
> this will allow proprietary stacks to present themselves as a pipewire src.
> For now though most proprietary stacks seem to prefer v4l2loopback because
> pipewire is not supported as camera source yet by a lot of apps.

I agree, that's a perfectly valid assessment of the situation.

> As I indicated in my original email personally I'm a bit divided on
> whether a virtual camera driver should be kept out of the kernel
> to not promote proprietary userspace stacks, but this is not my call.

Even disregarding that argument, the camera ecosystem is moving towards
implementing those use cases entirely in userspace with PipeWire. I
believe that merging a new kernel driver for this purpose, especially
one that exposes a custom API on its sink side and would therefore
require developing support in all source applications, goes against the
direction we're taking overall.

> OTHO evdi: https://github.com/DisplayLink/evdi has been kept out
> of the kernel for pretty much the same reasons by the drm/kms folks.
> 
> At least AFAIK there still is no way to present virtual kms capable
> display outputs backed by userspace in the kernel.
> 
> I completely understand where you're coming from wrt v4l2-loopback
> support (or something equivalent) but asking for this really is
> the same as asking for the evdi driver to get merged, which AFAIK
> has been blocked for the reason of avoiding proprietary userspace
> display output drivers (I guess there might be technical reasons too).

-- 
Regards,

Laurent Pinchart