From: Jarkko Sakkinen <jarkko@kernel.org>
To: linux-media@vger.kernel.org
Cc: jani.nikula@linux.intel.com, anisse@astier.eu,
oleksandr@natalenko.name, linux-integrity@vger.kernel.org,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hverkuil@kernel.org>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
Jacopo Mondi <jacopo.mondi@ideasonboard.com>,
Ricardo Ribalda <ribalda@chromium.org>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v2] media: Virtual camera driver
Date: Tue, 3 Feb 2026 10:09:20 +0200 [thread overview]
Message-ID: <aYGsyk5SnzktKM3m@kernel.org> (raw)
In-Reply-To: <20260202204425.2614054-1-jarkko@kernel.org>
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.
>
> 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.
>
> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
After learning a bit more about the topic and for future updates I will
drop YUYV. NV12, MJPEG, and additionally RGBX32 and XRGB32 for testing
and GPUs define pretty well the requirements for a software define device,
and limit the applicability of "proprietary risk" (as that was the main
concern raised). I honestly did not have idea what would be an
appropriate subset of formats to constraint the driver initially.
In addition, a better name for this module would probably be swcam as it
does not mix up with those pre-existing devices starting with the
letter 'v'.
BR, Jarkko
next prev parent reply other threads:[~2026-02-03 8:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 20:44 [RFC PATCH v2] media: Virtual camera driver Jarkko Sakkinen
2026-02-02 21:28 ` Jarkko Sakkinen
2026-02-02 22:50 ` Sakari Ailus
2026-02-03 0:10 ` Jarkko Sakkinen
2026-02-03 1:36 ` Jarkko Sakkinen
2026-02-03 20:57 ` Laurent Pinchart
2026-02-03 21:11 ` Jarkko Sakkinen
2026-02-03 21:21 ` Laurent Pinchart
2026-02-03 8:09 ` Jarkko Sakkinen [this message]
2026-02-03 8:32 ` Jarkko Sakkinen
2026-02-03 10:27 ` johannes.goede
2026-02-03 13:16 ` Jani Nikula
2026-02-03 21:09 ` Laurent Pinchart
2026-02-03 13:20 ` Jani Nikula
2026-02-03 14:19 ` johannes.goede
2026-02-03 15:25 ` Mauro Carvalho Chehab
2026-02-03 18:53 ` Jani Nikula
2026-02-03 19:07 ` Jarkko Sakkinen
2026-02-03 19:15 ` Jarkko Sakkinen
2026-02-03 21:22 ` Laurent Pinchart
2026-02-03 21:40 ` Jarkko Sakkinen
2026-02-03 21:18 ` Laurent Pinchart
2026-02-03 17:56 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYGsyk5SnzktKM3m@kernel.org \
--to=jarkko@kernel.org \
--cc=anisse@astier.eu \
--cc=hverkuil@kernel.org \
--cc=jacopo.mondi@ideasonboard.com \
--cc=jani.nikula@linux.intel.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=oleksandr@natalenko.name \
--cc=ribalda@chromium.org \
--cc=sakari.ailus@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox