From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Kieran Bingham <kieran.bingham@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX
Date: Thu, 12 Sep 2019 11:21:14 -0300 [thread overview]
Message-ID: <20190912112114.3a66663f@coco.lan> (raw)
In-Reply-To: <60769f0c-506c-4057-00ce-f4c8620441c5@ideasonboard.com>
Em Thu, 12 Sep 2019 14:16:11 +0100
Kieran Bingham <kieran.bingham@ideasonboard.com> escreveu:
> Hi Hans,
>
> On 12/09/2019 08:48, 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.
Kernel has (about) nothing to do with how the userspace devnodes are
named, as the actual name is given by udev.
Anyway, from Kernel standpoint, it sounds too late to change the name
of the devices from "videoX" to something else, as a change like that
may break existing apps.
It could make sense to have something like that at udev rules.
Btw, at least at the apps I'm maintaining on userspace, I'm not using
/dev/foo to detect devices anymore. Instead, I'm relying on udev
in order to enum devices, checking if the devnode support video stream
capabilities before exposing them for userspace to select.
> >
> > 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.
>
> I think I prefer this separation (v4l-metaX).
>
> Having metadata as a (separate) videoX seemed odd to me - but I only
> saw/was affected by the metadata topics when it was too late it seemed ...
>
>
> > 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?
>
> I've wondered why it's not a separate queue on the same video device -
> much like we have multiple queues for V4L2-M2M devices ....
>
> The data is relative to the same frames coming from the main queue right ?
>
> That might have been awkward to express through our device type flags
> though.
>
> Anyway, I thought the horse had bolted on this topic ?
>
> :-D
>
>
> > Regards,
> >
> > Hans
> >
>
>
Thanks,
Mauro
next prev parent reply other threads:[~2019-09-12 14:21 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 [this message]
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
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=20190912112114.3a66663f@coco.lan \
--to=mchehab+samsung@kernel.org \
--cc=hverkuil@xs4all.nl \
--cc=kieran.bingham@ideasonboard.com \
--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 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.