On 14/06/2021 19:04, Nelson Costa wrote:
> Hi Hans,
>
> Thanks for your comments!
>
> From: Hans Verkuil <hverkuil-cisco@xxxxxxxxx>
> Date: qua, jun 02, 2021 at 19:19:25
>
>> On 02/06/2021 19:15, Nelson Costa wrote:
>>> Hi Hans,
>>>
>>> Thanks for your comments and feedback!
>>>
>>> From: Hans Verkuil <hverkuil-cisco@xxxxxxxxx>
>>> Date: qua, jun 02, 2021 at 13:26:17
>>>
>>>> Hi Nelson,
>>>>
>>>> On 02/06/2021 13:24, Nelson Costa wrote:
>>>>> This extends the support for more video format timings based
>>>>> on SPECs CEA-861-F and CTA-861-G.
>>>>>
>>>>> NOTE: For the newer SPECs the CEA was unified to the CTA.
>>>>> The CTA-861-G then includes the CEA-861-F timings besides
>>>>> the new timings that are specified.
>>>>>
>>>>> CEA-861-F: Specifies the Video timings for VICs 1-107.
>>>>> CTA-861-G: Specifies the Video timings for VICs 1-107, 108-127, 193-219.
>>>>>
>>>>> With this patch, the array v4l2_dv_timings_presets has support for
>>>>> all video timings specified in CTA-861-G.
>>>>>
>>>>> Signed-off-by: Nelson Costa <nelson.costa@xxxxxxxxxxxx>
>>>>> ---
>>>>> drivers/media/v4l2-core/v4l2-dv-timings.c | 139 +++
>>>>> include/uapi/linux/v4l2-dv-timings.h | 1595 ++++++++++++++++++++++++++++-
>>>>
>>>> I prefer to split this up in two patches, one for each header.
>>>>
>>>
>>> I agree! It will be addressed in the next patch series.
>>>
>>>> The v4l2-dv-timings.h changes look good (my compliments for all the
>>>> work you put into that!).
>>>>
>>>
>>> Thanks!
>>>
>>>> I am more concerned about adding all these timings to v4l2_dv_timings_presets.
>>>>
>>>> There are really two different things going on here: the v4l2_dv_timings_presets
>>>> array is used both by v4l2_enum_dv_timings_cap() to list supported commonly used
>>>> timings, or to match against timings parameters (v4l2_find_dv_timings_cap()), and
>>>> as a lookup table when receiving a specific VIC code (v4l2_find_dv_timings_cea861_vic()).
>>>>
>>>> All the new timings you added are really only relevant in the last case when you
>>>> have the vic code.
>>>>
>>>> I think it is better to create a second array v4l2_dv_timings_non_square_vics[]
>>>> (or a better name!) that contains these timings.
>>>>
>>>
>>> I understood.
>>>
>>> We can then create another array as you said. But when you say
>>> "non_square"
>>> you mean that the vics have "Pixel Aspect Ratio != 1:1"?
>>>
>>> Because the new vics added have both kind of vics with "Pixel Aspect
>>> Ratio != 1:1"
>>> and also "Pixel Aspect Ratio == 1:1".
>>
>> There are? It's confusing since for 1:1 pixel aspect ratios I expect that the
>> picture aspect ratio is set to { 0, 0 }, instead they are all filled in.
>>
>> I think it will be clearer if I see a v2 where the picture aspect ratio and
>> the V4L2_DV_FL_HAS_PICTURE_ASPECT flag are only set for the non-square pixel
>> timings. Also, for the timings with 1:1 pixel aspect ratio you don't need to
>> add the PA... suffix. That suffix only makes sense for non-square pixel aspect
>> ratios. It's confusing otherwise.
>>
>
> It makes sense! That way it will assure coherence with the current
> implementation.
> In the v2 patch series this will be addressed.
>
>>>
>>> So, for the new vics should we create a second array with name
>>> v4l2_dv_timings_extended_vics[]?
>>
>> The new vics with non-square pixel aspect ratios, or with pixel repetition.
>>
>
> You mean the new vics added that are square should be kept in the
> original array?
>
> And only the new vics that are non-square or with pixel repetition should
> go to a second array?
Correct.
Regards,
Hans
