Re: [RFC] V4L2 & Metadata: switch to /dev/v4l-metaX instead of /dev/videoX

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Em Thu, 12 Sep 2019 14:16:11 +0100
Kieran Bingham <kieran.bingham@xxxxxxxxxxxxxxxx> 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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux