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