diff options
author | Hans Verkuil <hans.verkuil@cisco.com> | 2013-01-11 08:33:30 -0500 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@redhat.com> | 2013-02-06 05:10:40 -0500 |
commit | 0568aeeeef467ac6e22d5d549cd50e8c93abf959 (patch) | |
tree | c9c6bd7f4a747ef8c83a6af30f6f5c369c581b63 /Documentation/DocBook | |
parent | 07b64b837d90cf20fad6b4965aa1fecdb4a88e9b (diff) |
[media] DocBook: improve the error_idx field documentation
The documentation of the error_idx field was incomplete and confusing.
This patch improves it.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Diffstat (limited to 'Documentation/DocBook')
-rw-r--r-- | Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 47 |
1 files changed, 40 insertions, 7 deletions
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 0a4b90fcf2da..42ffbff6d37e 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml | |||
@@ -199,13 +199,46 @@ also be zero.</entry> | |||
199 | <row> | 199 | <row> |
200 | <entry>__u32</entry> | 200 | <entry>__u32</entry> |
201 | <entry><structfield>error_idx</structfield></entry> | 201 | <entry><structfield>error_idx</structfield></entry> |
202 | <entry>Set by the driver in case of an error. If it is equal | 202 | <entry><para>Set by the driver in case of an error. If the error is |
203 | to <structfield>count</structfield>, then no actual changes were made to | 203 | associated with a particular control, then <structfield>error_idx</structfield> |
204 | controls. In other words, the error was not associated with setting a particular | 204 | is set to the index of that control. If the error is not related to a specific |
205 | control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield> | 205 | control, or the validation step failed (see below), then |
206 | were modified and control <structfield>error_idx</structfield> is the one that | 206 | <structfield>error_idx</structfield> is set to <structfield>count</structfield>. |
207 | caused the error. The <structfield>error_idx</structfield> value is undefined | 207 | The value is undefined if the ioctl returned 0 (success).</para> |
208 | if the ioctl returned 0 (success).</entry> | 208 | |
209 | <para>Before controls are read from/written to hardware a validation step | ||
210 | takes place: this checks if all controls in the list are valid controls, | ||
211 | if no attempt is made to write to a read-only control or read from a write-only | ||
212 | control, and any other up-front checks that can be done without accessing the | ||
213 | hardware. The exact validations done during this step are driver dependent | ||
214 | since some checks might require hardware access for some devices, thus making | ||
215 | it impossible to do those checks up-front. However, drivers should make a | ||
216 | best-effort to do as many up-front checks as possible.</para> | ||
217 | |||
218 | <para>This check is done to avoid leaving the hardware in an inconsistent state due | ||
219 | to easy-to-avoid problems. But it leads to another problem: the application needs to | ||
220 | know whether an error came from the validation step (meaning that the hardware | ||
221 | was not touched) or from an error during the actual reading from/writing to hardware.</para> | ||
222 | |||
223 | <para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield> | ||
224 | to <structfield>count</structfield> if the validation failed. This has the | ||
225 | unfortunate side-effect that it is not possible to see which control failed the | ||
226 | validation. If the validation was successful and the error happened while | ||
227 | accessing the hardware, then <structfield>error_idx</structfield> is less than | ||
228 | <structfield>count</structfield> and only the controls up to | ||
229 | <structfield>error_idx-1</structfield> were read or written correctly, and the | ||
230 | state of the remaining controls is undefined.</para> | ||
231 | |||
232 | <para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware | ||
233 | there is also no need to handle the validation step in this special way, | ||
234 | so <structfield>error_idx</structfield> will just be set to the control that | ||
235 | failed the validation step instead of to <structfield>count</structfield>. | ||
236 | This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with | ||
237 | <structfield>error_idx</structfield> set to <structfield>count</structfield>, | ||
238 | then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover | ||
239 | the actual control that failed the validation step. Unfortunately, there | ||
240 | is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>. | ||
241 | </para></entry> | ||
209 | </row> | 242 | </row> |
210 | <row> | 243 | <row> |
211 | <entry>__u32</entry> | 244 | <entry>__u32</entry> |