From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX
Date: Sat, 14 Sep 2019 15:38:48 +0300 [thread overview]
Message-ID: <20190914123848.GD4734@pendragon.ideasonboard.com> (raw)
In-Reply-To: <f26a4eb0-7009-a25f-29bc-3a292d2d79e1@xs4all.nl>
Hi Hans,
On Thu, Sep 12, 2019 at 09:48:11AM +0200, Hans Verkuil wrote:
> Hi all,
>
> I am increasingly unhappy about the choice of /dev/videoX for metadata devices.
>
> It is confusing for end-users (especially w.r.t. the common uvc driver) and
> if we want to change this, then we need to do it soon.
>
> This patch https://patchwork.linuxtv.org/patch/58693/ adds a new VFL_TYPE_METADATA
> so at least drivers can now explicitly signal that they want to register a
> metadata device.
>
> This also makes it possible to add a kernel config option that allows you
> to select whether you want metadata devices to appear as videoX or v4l-metaX.
> I would prefer to set it to v4l-metaX by default.
>
> We can also consider backporting this to the stable/long-term kernels.
>
> Metadata capture was introduced in 4.12 for the vsp1 driver, in 4.16 for the
> uvc driver and in 5.0 for the staging ipu3 driver.
>
> Does someone remember the reason why we picked /dev/videoX for this in the
> first place?
One of the reason is CSI-2 sensors and CSI-2 receivers. A CSI-2 link
often carries both video and metadata using two different datatypes.
From the point of view of the CSI-2 receiver or the DMA engines, video
and metadata are not distinguishable, the CSI-2 receiver receives one
stream with two data types, demultiplexes them, and passes them to
different DMA engines. A sensor could send two video datatypes, or even
conceptually two metadata data types, and this would work the exact same
way, with each of the two DMA engines capturing data to buffers without
caring about the contents. Given that the datatype selection happens at
runtime, a given DMA engine is thus not dedicated to video or metadata,
any of the DMA engines (and there could also be more than two) could
handle any type of data. For this type of system we thus can't dedicate
device nodes to video or metadata, they need to support either.
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2019-09-14 12:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 7:48 [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX Hans Verkuil
2019-09-12 13:16 ` Kieran Bingham
2019-09-12 13:48 ` Hans Verkuil
2019-09-12 14:21 ` Mauro Carvalho Chehab
2019-09-12 14:49 ` Hans Verkuil
2019-09-12 14:57 ` Philipp Zabel
2019-09-12 15:08 ` Hans Verkuil
2019-09-14 12:38 ` Laurent Pinchart [this message]
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=20190914123848.GD4734@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
/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