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

[Hans Verkuil <hverkuil@xs4all.nl>]

On 9/12/19 3:16 PM, Kieran Bingham wrote:
> 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.
>>
>> 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.

There can be only one receive queue and one transmit queue per device node.

Multiple receive queues (i.e. with different types) were allowed in the past,
but I don't think any driver ever implemented it as it was just too complicated.
Both in the driver and for the user.

> 
> Anyway, I thought the horse had bolted on this topic ?

Well, that's the question. For meta output it can certainly be changed since
only a staging driver uses it. For capture it is mainly the uvc driver that's
problematic, but I am not aware of any linux application in a distro that
uses metadata capture.

So with a new kernel option you can choose whether you want to keep the old
behavior or create v4l-meta device nodes instead.

I regularly get questions about what happened, and by no means all applications
properly check the capabilities of the video device nodes (yes, they should do
so, but in the past this never was an issue with your average desktop user).

Besides all that, it is just weird to have meta data arrive on a video node.
I expect video there.

Regards,

	Hans

> 
>  :-D
> 
> 
>> Regards,
>>
>> 	Hans
>>
> 
>