Commit 6055b12a authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab

[media] V4L2 Spec: fix extended control documentation

Update the spec to the behavior implemented by the control framework.
This should have been documented long ago but for some reason it was
never done.
Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
parent 047a01fd
...@@ -183,7 +183,12 @@ applications must set the array to zero.</entry> ...@@ -183,7 +183,12 @@ applications must set the array to zero.</entry>
<entry>__u32</entry> <entry>__u32</entry>
<entry><structfield>ctrl_class</structfield></entry> <entry><structfield>ctrl_class</structfield></entry>
<entry>The control class to which all controls belong, see <entry>The control class to which all controls belong, see
<xref linkend="ctrl-class" />.</entry> <xref linkend="ctrl-class" />. Drivers that use a kernel framework for handling
controls will also accept a value of 0 here, meaning that the controls can
belong to any control class. Whether drivers support this can be tested by setting
<structfield>ctrl_class</structfield> to 0 and calling <constant>VIDIOC_TRY_EXT_CTRLS</constant>
with a <structfield>count</structfield> of 0. If that succeeds, then the driver
supports this feature.</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
...@@ -194,10 +199,13 @@ also be zero.</entry> ...@@ -194,10 +199,13 @@ also be zero.</entry>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry> <entry><structfield>error_idx</structfield></entry>
<entry>Set by the driver in case of an error. It is the <entry>Set by the driver in case of an error. If it is equal
index of the control causing the error or equal to 'count' when the to <structfield>count</structfield>, then no actual changes were made to
error is not associated with a particular control. Undefined when the controls. In other words, the error was not associated with setting a particular
ioctl returns 0 (success).</entry> control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
were modified and control <structfield>error_idx</structfield> is the one that
caused the error. The <structfield>error_idx</structfield> value is undefined
if the ioctl returned 0 (success).</entry>
</row> </row>
<row> <row>
<entry>__u32</entry> <entry>__u32</entry>
......
...@@ -666,27 +666,6 @@ a control of this type whenever the first control belonging to a new control ...@@ -666,27 +666,6 @@ a control of this type whenever the first control belonging to a new control
class is added. class is added.
Differences from the Spec
=========================
There are a few places where the framework acts slightly differently from the
V4L2 Specification. Those differences are described in this section. We will
have to see whether we need to adjust the spec or not.
1) It is no longer required to have all controls contained in a
v4l2_ext_control array be from the same control class. The framework will be
able to handle any type of control in the array. You need to set ctrl_class
to 0 in order to enable this. If ctrl_class is non-zero, then it will still
check that all controls belong to that control class.
If you set ctrl_class to 0 and count to 0, then it will only return an error
if there are no controls at all.
2) Clarified the way error_idx works. For get and set it will be equal to
count if nothing was done yet. If it is less than count then only the controls
up to error_idx-1 were successfully applied.
Proposals for Extensions Proposals for Extensions
======================== ========================
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment