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
