> Hans,
>
> So the only change will be about renaming the flags..
>
> Do you expect LCD VESA timings defined by V4L2_DV_BT_656_1120 timing type?
As far as I am aware, yes. But I have little experience with LCDs.
> I will update the RFC with capabilities flags renamed as discussed and
> re-send it and work on implementation based on this version.
Great!
Hans
>
> Murali Karicheri
> Software Design Engineer
> Texas Instruments Inc.
> Germantown, MD 20874
> email: m-karicheri2@xxxxxx
>
>>-----Original Message-----
>>From: Hans Verkuil [mailto:hverkuil@xxxxxxxxx]
>>Sent: Saturday, October 10, 2009 2:39 PM
>>To: Karicheri, Muralidharan
>>Cc: linux-media@xxxxxxxxxxxxxxx
>>Subject: Re: RFC (v1.1): V4L - Support for video timings at the
>>input/output interface
>>
>>On Saturday 10 October 2009 17:07:36 Karicheri, Muralidharan wrote:
>>> Hans,
>>>
>>> ________________________________________
>>> From: Hans Verkuil [hverkuil@xxxxxxxxx]
>>> Sent: Friday, October 09, 2009 10:43 AM
>>> To: Karicheri, Muralidharan
>>> Cc: linux-media@xxxxxxxxxxxxxxx
>>> Subject: Re: RFC (v1.1): V4L - Support for video timings at the
>>input/output interface
>>>
>>> i Murali,
>>>
>>> Reading through this I noticed that there was one thing that is
>>> probably
>>> no longer needed: now that we have the SUPPORTS_CUSTOM_TIMING
>>> capability
>>> there is no need to include the CUSTOM preset when enumerating presets.
>>> Instead I suggest that the INVALID preset define takes the place of the
>>> CUSTOM preset.
>>>
>>> [MK] Ok.
>>>
>>> Also, these capabilities should probably be renamed to
>>> V4L2_IN_CAP_STD/PRESETS/CUSTOM.
>>>
>>> This is more in line with the current naming convention.
>>>
>>>
>>> [MK] I think this is only partially correct. These presets applies to
>>OUTPUT as well. So We might want to
>>> define V4L2_OUT_CAP_STD/PRESETS/CUSTOM as well or Keep it as is.
>>
>>I got confused here by the tuner and modulator flags where the tuner
>> flags
>>are reused by the modulator flags. Sorry about that.
>>
>>So I think it is best to have both V4L2_IN_CAP and V4L2_OUT_CAP defines.
>>These
>>may initially be the same, but I would not be surprised if we start
>> seeing
>>caps that are unique to either input or output in the future. Just my
>>opinion,
>>though.
>>
>>>
>>>
>>> Otherwise I think this is pretty good.
>>>
>>> One thing: did you check against the FB API? We should have at least
>>> the
>>> same timing parameters as they have (it is my understanding that
>>> timings
>>> can also be setup through the FB API).
>>>
>>> In FB, following parameters defined for video mode..... I have mapped
>>> it
>>to
>>> timing parameter below. I have used modedb.c to understand the
>>> parameters.
>>>
>>> Probably add a timing type for VESA and a structure similar to
>>fb_videomode???
>>>
>>> struct fb_videomode {
>>> const char *name; /* optional */ - Missing in our
>>> API
>>
>>I don't see a good reason for adding this.
>>
>>> u32 refresh; /* optional */ - Missing in
>>out API.
>>
>>This can be calculated from the other arguments.
>>
>>> u32 xres; -
>>width
>>> u32 yres; -
>>height
>>> u32 pixclock; - -
>>pixelclock
>>> u32 left_margin; -
>>hfrontporch (should we rename to left_margin ??)
>>> u32 right_margin; - Need to
>>derive - should we add right margin??
>>> u32 upper_margin; -
>>> vfrontporch
>>(should we rename to upper margin??)
>>> u32 lower_margin; - Need to
>>derive - should we add lower margin??)
>>
>>h/vfrontporch is more standard than margin, so I vote for keeping that
>>terminology. Neither should we add right/lower margin. We have total
>>width/height instead which is also more commonly used.
>>
>>> u32 hsync_len; - hsync
>>> -
>>better to rename this as hsync_len
>>> u32 vsync_len; - vsync -
>>better to rename
>>
>>No need for a rename IMHO. If we do that, then hfrontporch and htotal
>> also
>>need to be renamed.
>>
>>The important bit is that all the same timings are represented here.
>>
>>> u32 sync; -
>>polarities
>>> u32 vmode; -
>>interlaced
>>> u32 flag; -
>>Missing. May be add this ???
>>
>>Are there any flags defined? We have reserved fields that we can utilize
>> in
>>the future.
>>
>>Regards,
>>
>> Hans
>>
>>> };
>>>
>>> Out timing definition.....
>>>
>>> > /* 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];
>>> > };
>>>
>>>
>>> Regards,
>>>
>>> Hans
>>>
>>> > Hello,
>>> >
>>> > Here is the version 1.1 of the RFC which will be used for
>>> implementing
>>> > the video timing APIs in the V4L2 core. Please review and let me know
>>> > if I have missed something. Following are the changes incorporated in
>>this
>>> > version :-
>>> >
>>> > 1) Added width and height parameters in the struct
>>> v4l2_dv_enum_presets
>>> >
>>> > 2) Corrected duplicate values in the defined preset values
>>> >
>>> > 3) Added following capability to indicate if the driver supports
>>setting
>>> > standards through existing S_STD IOCTL.
>>> >
>>> > #define V4L2_SUPPORTS_STD 0x00000004
>>> >
>>> > 4) Removed negative Polarity masks
>>> >
>>> > 5) Added issue #7 for camera sensor frame size/frame rate setting.
>>> >
>>> >
>>===========================================================================
>>=
>>> > RFC (v1.1): V4L - Support for video timings at the input/output
>>interface
>>> >
>>> > Version : 1.1
>>> >
>>> > Background
>>> > -----------
>>> >
>>> > Currently v4l2 specification supports capturing video frames from TV
>>> > signals using tuners (input type V4L2_INPUT_TYPE_TUNER) and baseband
>>> TV
>>> > signals (V4L2_INPUT_TYPE_CAMERA) and sensors. Similarly on the output
>>> > side, the signals could be TV signal (V4L2_OUTPUT_TYPE_MODULATOR),
>>> > baseband TV signal (V4L2_OUTPUT_TYPE_ANALOG) or hybrid analog VGA
>>overlay
>>> > (V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY) which output from a graphics card
>>and
>>> > then use chromakeying to replace part of the picture with the video.
>>> > V4L2_OUTPUT_TYPE_ANALOG & V4L2_INPUT_TYPE_CAMERA are for analog
>>interfaces
>>> > that includes composite, S-Video and VGA (for output only). Note that
>>even
>>> > though VGA is a supported output, we don't have anyway to set the
>>standard
>>> > or timing on the output. Standard ids are only defined for TVs using
>>> > v4l2_std_id and a set of bit masks defined for analog TV standards.
>>> >
>>> > Today we have a wide variety of different interfaces available to
>>> > transmit/receive video or graphics content between source device and
>>> > destination device. Following are some of the interfaces used in
>>addition
>>> > to the ones described in the v4l2 specification.
>>> >
>>> > Component analog input/output interface - ED/HD video
>>> > DVI - Digital only, ANALOG only, DVI integrated that support Digital
>>and
>>> > Analog;
>>> > Dual Link - Where second data link is used for higher bandwidth
>>> > SDI - Serial digital interface standardized by SMPTE
>>> > HDMI - HD video and Audio
>>> > DisplayPort - digital audio/video interconnect by VESA
>>> >
>>> > V4L2 specification currently defined NTSC/PAL/SECAM (all variants)
>>> > standards for describing the timing of the signal transmitted over
>>these
>>> > interfaces. Even though the specification defined ANALOG output type
>>for
>>> > VGA, there are no ways to set the timings used for output to VGA or
>>> LCD
>>> > display monitors. Some of the proprietary implementations used
>>> existing
>>> > standards IOCTL, VIDIOC_S_STD, to set these timings over these
>>interfaces.
>>> > For example, TI SoCs have Video Processing Back End (VPBE) on various
>>> > media SOCs (Eg, DM6446, DM355 etc) that can output signal for Analog
>>> TV
>>> > and VGA interfaces (using Digital LCD port) and support timings for
>>> > displaying SD and HD videos (1080i, 1080p and 720p) as well as over
>>> VGA
>>> > interface to a CRT or LCD display monitor. So we need to enhance the
>>v4l2
>>> > specification to allow applications to set these timings in the
>>> capture
>>or
>>> > output devices. This RFC proposes to add new IOCTLs for
>>> setting/getting
>>> > timings over the different interfaces described above and freeze the
>>the
>>> > use of existing standards IOCTL and standards IDs for analog TVs
>>> only.
>>> >
>>> > Timings
>>> > -------
>>> >
>>> > The timings at the analog or digital interface that are not covered
>>> by
>>the
>>> > v4l2_std_id can be defined using a set of preset values that are used
>>by
>>> > the hardware where the timings are predefined or by a set of timing
>>values
>>> > which can be configured at the hardware to generate the signal
>>> expected
>>at
>>> > the interface. The former will be used for hardware like
>>TVP7002/THS8200
>>> > which specifies preset timing required for output HD video such
>>> > 1080i50/60, 720p50/60 etc. The latter can be used for hardware that
>>> > requires configuration of frame timing such as front porch, hsync
>>length,
>>> > vsync length, pixel clock etc. For example the earlier mentioned TI
>>SOCs
>>> > have a Digital LCD port that can be configured to output different
>>timing
>>> > values expected by LCD Display monitors.
>>> >
>>> > Preset timings (defined by VESA, SMPTE or BT.656/BT.1120 or others)
>>> can
>>be
>>> > defined by the following structure:-
>>> >
>>> > struct v4l2_dv_preset {
>>> > __u32 preset;
>>> > __u32 reserved[4];
>>> > };
>>> >
>>> > Where preset is one of the following values:-
>>> >
>>> > #define V4L2_DV_CUSTOM 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
>>> >
>>> >
>>> > /* Following preset value is used by driver to indicate there is no
>>signal
>>> > detected or could not lock to the signal for VIDIOC_QUERY_DV_PRESET.
>>> > */
>>> > #define V4L2_DV_INVALID 0xFFFFFFFF
>>> >
>>> >
>>> > 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];
>>> > };
>>> >
>>> > /*
>>> > * 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_SUPPORTS_PRESETS 0x00000001
>>> > #define V4L2_SUPPORTS_CUSTOM_TIMINGS 0x00000002
>>> > #define V4L2_SUPPORTS_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];
>>> > };
>>> >
>>> >
>>> > interlaced - Interlaced or progressive. use following values:-
>>> >
>>> > #define V4L2_DV_INTERLACED 0
>>> > #define V4L2_DV_PROGRESSIVE 1
>>> >
>>> > pixelclock - expressed in HZ. So for 74.25MHz, use 74250000.
>>> > width - number of pixels in horizontal direction
>>> > height - number of lines in vertical direction
>>> > polarities - Bit mask for following polarities to begin with
>>> > (if polarity bit is not set, corresponding polarity is assumed to be
>>> > negative)
>>> >
>>> > #define V4L2_DV_VSYNC_POS_POL 0x00000001
>>> > #define V4L2_DV_HSYNC_POS_POL 0x00000002
>>> >
>>> > hfrontporch,hsync, and htotal for horizontal direction and
>>> vfrontporch,
>>> > vsync, and vtotal for vertical direction. il_vtotal is the number of
>>> > vertical lines for interlaced video for bottom field.
>>> >
>>> > To define a particular timing type, following enum is used:-
>>> >
>>> > enum v4l2_dv_timings_type {
>>> > V4L2_DV_BT_656_1120,
>>> > };
>>> >
>>> > This will allow adding new timing types in the future.
>>> >
>>> > If the driver supports a set of custom timing, it can be set/get
>>> using
>>> > VIDIOC_S/G_DV_TIMINGS IOCTL and specifying timings using the
>>> structure
>>> >
>>> > struct v4l2_dv_timings {
>>> > enum v4l2_dv_timings_type type;
>>> > union {
>>> > struct v4l2_bt_timings bt;
>>> > __u32 reserved[32];
>>> > };
>>> > };
>>> >
>>> >
>>> > If the driver supports custom timing as well as Presets, it will
>>> return
>>> > V4L2_DV_CUSTOM along with other preset timings for the
>>> > VIDIOC_ENUM_DV_PRESETS IOCTL call. Application can then call
>>> > VIDIOC_S/G_TIMING to get/set custom timings at the driver.
>>> >
>>> > To detect a preset timing at the input application calls
>>> > VIDIOC_QUERY_DV_PRESET which returns the preset using the
>>v4l2_dv_preset
>>> > structure.
>>> >
>>> > Following summarize the new ioctls added by this RFC
>>> >
>>> > #define VIDIOC_ENUM_DV_PRESETS _IOWR('V', 79, struct
>>> > v4l2_dv_enum_presets)
>>> > #define VIDIOC_S_DV_PRESET _IOWR('V', 80, struct
>>> v4l2_dv_preset)
>>> > #define VIDIOC_G_DV_PRESET _IOWR('V', 81, struct
>>> v4l2_dv_preset)
>>> > #define VIDIOC_QUERY_DV_PRESET _IOR('V', 82, struct
>>> v4l2_dv_preset)
>>> > #define VIDIOC_S_DV_TIMINGS _IOWR('V', 83, struct
>>> v4l2_dv_timings)
>>> > #define VIDIOC_G_DV_TIMINGS _IOWR('V', 84, struct
>>> v4l2_dv_timings)
>>> >
>>> > Open issues
>>> > -----------
>>> >
>>> > 1.How to handle an HDMI transmitter? It can be put in two different
>>modes:
>>> > DVI compatible
>>> > or HDMI compatible. Some of the choices are
>>> > a) enumerate them as two different outputs when enumerating.
>>> > b) adding a status bit on the input.
>>> > c) change it using a control
>>> >
>>> > 2. Detecting whether there is an analog or digital signal on an DVI-I
>>> > input:
>>> > a) add new status field value for v4l2_input ?
>>> > #define V4L2_IN_ST_DVI_ANALOG_DETECTED 0x10000000
>>> > #define V4L2_IN_ST_DVI_DIGITAL_DETECTED 0x20000000
>>> >
>>> > 3. Detecting an EDID.
>>> > a) adding a status field in v4l2_output and two new ioctls that
>>can set
>>> > the EDID for an input or retrieve it for an output. It should also be
>>> > added as an input/output capability.
>>> >
>>> > 4. ATSC bits in v4l2_std_id: how are they used? Are they used at all
>>for
>>> > that matter?
>>> > 5. There are a lot of status bits defined in v4l2_input, but only a
>>> few
>>> > are actually used. What are we going to do with that?
>>> >
>>> > 6. HDMI requires additional investigation. HDMI defines a whole bunch
>>of
>>> > infoframe fields. Most of these can probably be exported as
>>> controls??
>>Is
>>> > HDMI audio handled by alsa?
>>> >
>>> > 7. Can sensor driver use the same API for setting frame size and
>>> frame
>>> > rate? It was discussed and the general agreement was to use this API
>>only
>>> > for video timing.
>>> >
>>> >
>>> > Murali Karicheri
>>> > Software Design Engineer
>>> > Texas Instruments Inc.
>>> > Germantown, MD 20874
>>> > email: m-karicheri2@xxxxxx
>>> >
>>> > --
>>> > To unsubscribe from this list: send the line "unsubscribe
>>> linux-media"
>>in
>>> > the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> >
>>>
>>>
>>> --
>>> Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>>>
>>>
>>>
>>>
>>
>>
>>
>>--
>>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
>
>
>
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
