RE: RFC (v1.1): V4L - Support for video timings at the input/output interface
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-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Saturday, October 10, 2009 2:39 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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 [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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
RE: RFC (v1.1): V4L - Support for video timings at the input/output interface
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-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Saturday, October 10, 2009 2:39 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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 [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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
RE: RFC (v1.1): V4L - Support for video timings at the input/output interface
Hans,
From: Hans Verkuil [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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.
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
u32 refresh;/* optional */ - Missing in out API.
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??)
u32 hsync_len;- hsync - better
to rename this as hsync_len
u32 vsync_len;- vsync - better
to rename
u32 sync; - polarities
u32 vmode; - interlaced
u32 flag; - Missing.
May be add this ???
};
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_STD0x0004
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
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 [hverk...@xs4all.nl]
Sent: Friday, October 09, 2009 10:43 AM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
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_STD0x0004
4) Removed negative Polarity masks
5) Added issue #7 for camera sensor frame size/frame rate setting
Re: RFC (v1.1): V4L - Support for video timings at the input/output interface
Hi 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. Also, these capabilities should probably be renamed to V4L2_IN_CAP_STD/PRESETS/CUSTOM. This is more in line with the current naming convention. 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). 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_STD0x0004 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
