All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.