Re: [RFCv2 API PATCH 04/28] DocBook: make the G/S/TRY_FMT specification more strict.
On Friday 07 September 2012 15:29:04 Hans Verkuil wrote: > From: Hans Verkuil > > - S/TRY_FMT should always succeed, unless an invalid type field is passed > in. - TRY_FMT should give the same result as S_FMT, all other things being > equal. - ENUMFMT may return different formats for different inputs or > outputs. > > This was decided during the 2012 Media Workshop. > > Signed-off-by: Hans Verkuil With the typo fix reported by Sylwester, Acked-by: Laurent Pinchart -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 04/28] DocBook: make the G/S/TRY_FMT specification more strict.
On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuil - S/TRY_FMT should always succeed, unless an invalid type field is passed in. - TRY_FMT should give the same result as S_FMT, all other things being equal. - ENUMFMT may return different formats for different inputs or outputs. This was decided during the 2012 Media Workshop. Signed-off-by: Hans Verkuil Reviewed-by: Sylwester Nawrocki A typo managed to snick in below... --- Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml |3 +++ Documentation/DocBook/media/v4l/vidioc-g-fmt.xml|9 ++--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml index 81ebe48..0bd3324 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml @@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an incrementing by one untilEINVAL is returned. +Note that after switching input or output the list of enumerated image +formats may be different. + structv4l2_fmtdesc diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index 52acff1..9ef279a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -81,7 +81,7 @@ the application calls theVIDIOC_S_FMT ioctl with a pointer to av4l2_format structure the driver checks and adjusts the parameters against hardware abilities. Drivers -should not return an error code unless the input is ambiguous, this is +should not return an error code unless thetype field is invalid, this is a mechanism to fathom device capabilities and to approach parameters acceptable for both the application and driver. On success the driver may program the hardware, allocate resources and generally prepare for @@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations. Although strongly recommended drivers are not required to implement this ioctl. +The format as returned byVIDIOC_TRY_FMT +must be identical to whatVIDIOC_S_FMT returns for +the same input or output. + structv4l2_format @@ -187,8 +191,7 @@ capture and output devices. EINVAL The&v4l2-format;type -field is invalid, the requested buffer type not supported, or the -format is not supported with this buffer type. +field is invalia or the requested buffer type not supported. invalia -> invalid -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv2 API PATCH 04/28] DocBook: make the G/S/TRY_FMT specification more strict.
From: Hans Verkuil - S/TRY_FMT should always succeed, unless an invalid type field is passed in. - TRY_FMT should give the same result as S_FMT, all other things being equal. - ENUMFMT may return different formats for different inputs or outputs. This was decided during the 2012 Media Workshop. Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml |3 +++ Documentation/DocBook/media/v4l/vidioc-g-fmt.xml|9 ++--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml index 81ebe48..0bd3324 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml @@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an incrementing by one until EINVAL is returned. +Note that after switching input or output the list of enumerated image +formats may be different. + struct v4l2_fmtdesc diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index 52acff1..9ef279a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -81,7 +81,7 @@ the application calls the VIDIOC_S_FMT ioctl with a pointer to a v4l2_format structure the driver checks and adjusts the parameters against hardware abilities. Drivers -should not return an error code unless the input is ambiguous, this is +should not return an error code unless the type field is invalid, this is a mechanism to fathom device capabilities and to approach parameters acceptable for both the application and driver. On success the driver may program the hardware, allocate resources and generally prepare for @@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations. Although strongly recommended drivers are not required to implement this ioctl. +The format as returned by VIDIOC_TRY_FMT +must be identical to what VIDIOC_S_FMT returns for +the same input or output. + struct v4l2_format @@ -187,8 +191,7 @@ capture and output devices. EINVAL The &v4l2-format; type -field is invalid, the requested buffer type not supported, or the -format is not supported with this buffer type. +field is invalia or the requested buffer type not supported. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
