> Hans,
>
>
>>>
>>> #define V4L2_DV_INVALID 0x00000000
>>> #define V4L2_DV_480I59_94 0x00000001
>>> #define V4L2_DV_480I60 0x00000002
>>> #define V4L2_DV_480P23_976 0x00000003
>>> #define V4L2_DV_480P24 0x00000004
>>> #define V4L2_DV_480P29_97 0x00000005
>>> #define V4L2_DV_480P30 0x00000006
>>> #define V4L2_DV_576I50 0x00000007
>>> #define V4L2_DV_576P25 0x00000008
>>> #define V4L2_DV_576P50 0x00000009
>>> #define V4L2_DV_720P23_976 0x0000000A
>>> #define V4L2_DV_720P24 0x0000000B
>>> #define V4L2_DV_720P25 0x0000000C
>>> #define V4L2_DV_720P29_97 0x0000000D
>>> #define V4L2_DV_720P30 0x0000000E
>>> #define V4L2_DV_720P50 0x0000000F
>>> #define V4L2_DV_720P59_94 0x00000010
>>> #define V4L2_DV_720P60 0x00000011
>>> #define V4L2_DV_1080I50 0x00000012
>>> #define V4L2_DV_1080I59_94 0x00000013
>>> #define V4L2_DV_1080I60 0x00000014
>>> #define V4L2_DV_1080P23_976 0x00000015
>>> #define V4L2_DV_1080P24 0x00000016
>>> #define V4L2_DV_1080P25 0x00000017
>>> #define V4L2_DV_1080P29_97 0x00000018
>>> #define V4L2_DV_1080P30 0x00000019
>>> #define V4L2_DV_1080P60 0x00000020
>>
>>Note: when defining this in the videodev2 header we also need to document
>>the timings for each preset and where we got this data from (e.g.
>> CEA861-E
>>if I recall correctly).
>>
> [MK] To be honest, I did a google search and arrived at the list. If you
> need to specify where it actually defined, I would need your help since I
> don't have access to any standards document. If not, we might want to
> start with a small set ( where we know there is a specific standard for
> the same) which can be expanded later by developers (since they would know
> what standard they refer to)
In that case, start with a standard set. I can check this later when I'm
back in Norway.
>
>>>
>>>
>>> Driver sets preset to V4L2_DV_INVALID to indicate there is no signal
>>> detected or could not lock to the signal for a VIDIOC_QUERY_DV_PRESET
>>> IOCTL
>>>
>>> This list is expected grow over time. So a bit mask is not used for
>>> this
>>> (Unlike analog TV standards) so that many presets can be defined as
>>needed
>>> in the future.
>>>
>>> To enumerate the DV preset timings available, applications call
>>> VIDIOC_ENUM_DV_PRESETS using the following structure:-
>>>
>>> struct v4l2_dv_enum_presets {
>>> __u32 index;
>>> __u32 preset;
>>> __u8 name[32]; /* Name of the preset timing */
>>> __u32 width;
>>> __u32 height;
>>> __u32 reserved[4];
>>> };
>>>
>>> Application set/get the preset by calling VIDIOC_S/G_DV_PRESET using
>>> v4l2_dv_preset structure.
>>>
>>> Also add a capabilities field in the input and output structure to
>>support
>>> presets
>>>
>>> /*
>>> * V I D E O I N P U T S
>>> */
>>> struct v4l2_input {
>>> __u32 index; /* Which input */
>>> __u8 name[32]; /* Label */
>>> __u32 type; /* Type of input */
>>> __u32 audioset; /* Associated audios
>>> (bitfield)
>>> */
>>> __u32 tuner; /* Associated tuner */
>>> v4l2_std_id std;
>>> __u32 status;
>>> __u32 capabilities;
>>> __u32 reserved[3];
>>> };
>>>
>>> where capabilities can be one or more of the following:-
>>>
>>> #define V4L2_IN_CAP_PRESETS 0x00000001
>>> #define V4L2_IN_CAP_CUSTOM_TIMINGS 0x00000002
>>> #define V4L2_IN_CAP_STD 0x00000004
>>>
>>> /*
>>> * V I D E O O U T P U T S
>>> */
>>> struct v4l2_output {
>>> __u32 index; /* Which output */
>>> __u8 name[32]; /* Label */
>>> __u32 type; /* Type of output */
>>> __u32 audioset; /* Associated audios
>>> (bitfield)
>>> */
>>> __u32 modulator; /* Associated modulator */
>>> v4l2_std_id std;
>>> __u32 capabilities;
>>> __u32 reserved[3];
>>> };
>>>
>>> where capabilities can be one or more of the following:-
>>>
>>> #define V4L2_OUT_CAP_PRESETS 0x00000001
>>> #define V4L2_OUT_CAP_CUSTOM_TIMINGS 0x00000002
>>> #define V4L2_OUT_CAP_STD 0x00000004
>>>
>>> For setting custom timing at the device, following structure is used
>>which
>>> defines the complete set of timing values required at the input and
>>output
>>> interface:-
>>>
>>> /* timing data values specified by various standards such as BT.1120,
>>> BT.656 etc. */
>>>
>>> /* bt.656/bt.1120 timing data */
>>> struct v4l2_bt_timings {
>>> __u32 interlaced;
>>> __u64 pixelclock;
>>> __u32 width, height;
>>> __u32 polarities;
>>> __u32 hfrontporch, hsync, htotal;
>>> __u32 vfrontporch, vsync, vtotal;
>>> /* timings for bottom frame for interlaced formats */
>>> __u32 il_vtotal;
>>> __u32 reserved[16];
>>> };
>>
>>I think that we should be a change here: instead of specifying htotal and
>>vtotal it is more symmetrical to specify hbackporch and vbackporch.
>>
>>And instead of il_vtotal I think it is better to specify il_vfrontporch,
>>il_vsync, il_vbackporch. Since any of these three parameters can be the
>>one that is 1 longer than the top field.
>
>
> [MK] So are you saying we need all four:- il_vtotal, il_vfrontporch,
> il_vsync, & il_vbackporch ?
No, the htotal, vtotal and il_vtotal fields should be removed. These can
be calculated from adding up the other fields.
>
>>
>>>
>>>
>>> interlaced - Interlaced or progressive. use following values:-
>>>
>>> #define V4L2_DV_INTERLACED 0
>>> #define V4L2_DV_PROGRESSIVE 1
>>
>>Make PROGRESSIVE 0 instead of 1. It fits the meaning of the field better.
>>For the interlaced formats we might end up with two: INTERLACED_TOP_FIRST
>>and INTERLACED_BOTTOM_FIRST: depending on the interlaced format the top
>>field or the bottom field is sent first. That's something that can differ
>>depending on the format (I know it is different between PAL and NTSC).
>
>
> [MK] will change to
>
> #define V4L2_DV_PROGRESSIVE 0
> #define V4L2_DV_INTERLACED 1
>
>>
>>I'm not sure how the CEA standard defines this.
>
> [MK]If we need to support different interlaced formats as you state, we
> could add a flag using the reserved later. I think it is better to add
> such things later when someone actually has a use case. I don't have
> access to CEA standard. So I can't comment on that.
OK, I agree with this.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
