Re: [RFC PATCH v2] media: Virtual camera driver

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Feb 03, 2026 at 03:19:13PM +0100, johannes.goede@oss.qualcomm.com wrote:
> On 3-Feb-26 14:20, Jani Nikula wrote:
> > On Tue, 03 Feb 2026, johannes.goede@oss.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