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? I will update the RFC with capabilities flags renamed as discussed and re-send it and work on implementation based on this version. 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 -- 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
