Re: [RFCv4 PATCH 1/3] uapi/linux/media.h: add property support

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

 



On 12/12/18 9:43 AM, Hans Verkuil wrote:
> On 12/12/18 9:18 AM, Mauro Carvalho Chehab wrote:
>>>  /* ioctls */
>>> @@ -368,6 +446,8 @@ struct media_v2_topology {
>>>  #define MEDIA_IOC_ENUM_ENTITIES	_IOWR('|', 0x01, struct media_entity_desc)
>>>  #define MEDIA_IOC_ENUM_LINKS	_IOWR('|', 0x02, struct media_links_enum)
>>>  #define MEDIA_IOC_SETUP_LINK	_IOWR('|', 0x03, struct media_link_desc)
>>> +/* Old MEDIA_IOC_G_TOPOLOGY ioctl without props support */
>>> +#define MEDIA_IOC_G_TOPOLOGY_OLD 0xc0487c04
>>
>> I would avoid calling it "_OLD". we may have a V3, V4, V5, ... of this
>> ioctl.
>>
>> I would, instead, define an _IOWR_COMPAT macro that would take an extra
>> parameter, in order to get the size of part of the struct, e. g. something
>> like:
>>
>> #define MEDIA_IOC_G_TOPOLOGY_V1		_IOWR_COMPAT('|', 0x04, struct media_v2_topology, num_props)
> 
> That's not a bad idea, actually.
> 
>>
>> Also, I don't see any good reason why to keep this at uAPI (except for a
>> mc-compliance tool that would test both versions - but this could be
>> defined directly there).
> 
> Makes sense.

Ah, this means that applications like gstreamer cannot fall back to the older
G_TOPOLOGY ioctl. They don't know which kernel they are running against, so
they will probably want to try the new one first before falling back to the
old version.

I wonder how drm does this. Does anyone know?

Regards,

	Hans

> 
>>
>>>  #define MEDIA_IOC_G_TOPOLOGY	_IOWR('|', 0x04, struct media_v2_topology)
>>>  #define MEDIA_IOC_REQUEST_ALLOC	_IOR ('|', 0x05, int)
>>>  
>>
>> Thanks,
>> Mauro
>>
> 
> Regards,
> 
> 	Hans
> 




[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