public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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