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]

 



On 9/12/19 4:21 PM, Mauro Carvalho Chehab wrote:
> 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.

To my knowledge the standard udev rules do not rename anything for media
devices, so in reality it IS the kernel that decides this.

But this is why I suggested to put it under a kernel config option.

> 
> 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.

But wouldn't that break existing apps as well?

A bigger problem is that it isn't easy to detect the difference between
a regular video device and a metadata device: you'd have to call QUERYCAP
to determine that.

Now that device_caps is always available, perhaps we should exports that
as an attribute? Regardless of this specific issue, it would make it a lot
easier to write udev rules.

Regards,

	Hans

> 
> 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