[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260203150638.GA11369@killaraus>
Date: Tue, 3 Feb 2026 17:06:38 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, linux-media@...r.kernel.org,
anisse@...ier.eu, oleksandr@...alenko.name,
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] media: Virtual camera driver
On Tue, Feb 03, 2026 at 11:50:23AM +0200, Jani Nikula wrote:
> On Sun, 01 Feb 2026, Laurent Pinchart <laurent.pinchart@...asonboard.com> wrote:
> > On Sun, Feb 01, 2026 at 09:04:00PM +0200, Jarkko Sakkinen wrote:
> >> On Sun, Feb 01, 2026 at 08:20:11PM +0200, Laurent Pinchart wrote:
> >> > On Sun, Feb 01, 2026 at 03:33:38PM +0200, Jarkko Sakkinen wrote:
> >> > > 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.
> >> > >
> >> > > Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
> >> > > ---
> >> > > Early feedback e.g., is this completely in wrong direction? V4L2 world
> >> > > is relatively alien world, and thus I need a sanity check ;-)
> >> >
> >> > We already have multiple virtual drivers, including vivid and vimc.
> >> > Could you please explain the rationale for yet another one, and why the
> >> > new features it provides (if any) can't be added to existing drivers ?
> >>
> >> There is a notable user base for v4l2-loopback. It is the defacto choice
> >> for streaming phone cams.
> >
> > This will then likely face the same hurdles as v4l2-loopback, the main
> > one being that camera support should be upstreamed with proper drivers
> > instead of a closed-source userspace daemon.
>
> My use case:
>
> Input screen capture and webcam into OBS Studio, output the combined
> scene into virtual device, and input that virtual device into an
> application that is designed to work with video devices like that, and
> is not aware of anything fancier. For example, a web based meeting
> software. [1]
>
> There's nothing proprietary or closed-source here. AFAICT using
> v4l2-loopback is currently the only method suggested or supported by OBS
> Studio, or the plethora of apps that only really understand the video
> devices.
>
> I don't want to use that out-of-tree module from distro DKMS or
> whatever. Please enlighten me (and apparently a lot of other folks) if
> there's a better option that can be made to work out of the box. And it
> pretty much has to be as simple as 'apt install v4l2loopback-dkms'.
I'd say it should be as simple as 'apt install obs-studio' :-)
OBS has recently gained PipeWire support, but as a source, not a sink.
To cover your use case, we would need to extend OBS with PipeWire sink
support. The video stream that it would then provide to PipeWire would
be available in applications, including web browsers for video
conferencing.
Yes, this will require work on OBS, but the proposed virtual camera
driver does as well as the API on the sink side uses custom ioctls.
v4l2loopback support in OBS won't work out of the box with it. If OBS is
to be extended anyway, it should be done with PipeWire support as that's
where the ecosystem is moving.
PipeWire also includes pw-v4l2, a wrapper script with an LD_PRELOAD-able
library that emulates the V4L2 API. It helps with applications that
require a V4L2 capture device, until they gain native PipeWire support.
> [1] https://obsproject.com/kb/virtual-camera-guide
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists