AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

[media] v4l2-controls.txt: update auto cluster documentation

Browse Source 
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This commit is contained in:
Hans Verkuil 2011-08-26 08:35:59 -03:00 committed by Mauro Carvalho Chehab
parent 5626b8c75b
commit 882a935c43
1 changed files with 12 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
Documentation/video4linux/v4l2-controls.txt
View File

@ -495,18 +495,20 @@ Handling autogain/gain-type Controls with Auto Clusters
A common type of control cluster is one that handles 'auto-foo/foo'-type
controls. Typical examples are autogain/gain, autoexposure/exposure,
autowhitebalance/red balance/blue balance. In all cases you have one controls
autowhitebalance/red balance/blue balance. In all cases you have one control
that determines whether another control is handled automatically by the hardware,
or whether it is under manual control from the user.
If the cluster is in automatic mode, then the manual controls should be
marked inactive. When the volatile controls are read the g_volatile_ctrl
operation should return the value that the hardware's automatic mode set up
automatically.
marked inactive and volatile. When the volatile controls are read the
g_volatile_ctrl operation should return the value that the hardware's automatic
mode set up automatically.
If the cluster is put in manual mode, then the manual controls should become
active again and V4L2_CTRL_FLAG_VOLATILE should be ignored (so g_volatile_ctrl
is no longer called while in manual mode).
active again and the volatile flag is cleared (so g_volatile_ctrl is no longer
called while in manual mode). In addition just before switching to manual mode
the current values as determined by the auto mode are copied as the new manual
values.
Finally the V4L2_CTRL_FLAG_UPDATE should be set for the auto control since
changing that control affects the control flags of the manual controls.
@ -520,6 +522,10 @@ void v4l2_ctrl_auto_cluster(unsigned ncontrols, struct v4l2_ctrl **controls,
The first two arguments are identical to v4l2_ctrl_cluster. The third argument
tells the framework which value switches the cluster into manual mode. The
last argument will optionally set V4L2_CTRL_FLAG_VOLATILE for the non-auto controls.
If it is false, then the manual controls are never volatile. You would typically
use that if the hardware does not give you the option to read back to values as
determined by the auto mode (e.g. if autogain is on, the hardware doesn't allow
you to obtain the current gain value).
The first control of the cluster is assumed to be the 'auto' control.
@ -680,16 +686,6 @@ if there are no controls at all.
count if nothing was done yet. If it is less than count then only the controls
up to error_idx-1 were successfully applied.
3) When attempting to read a button control the framework will return -EACCES
instead of -EINVAL as stated in the spec. It seems to make more sense since
button controls are write-only controls.
4) Attempting to write to a read-only control will return -EACCES instead of
-EINVAL as the spec says.
5) The spec does not mention what should happen when you try to set/get a
control class controls. The framework will return -EACCES.
Proposals for Extensions
========================
@ -702,9 +698,3 @@ decimal. Useful for e.g. video_mute_yuv.
2) It is possible to mark in the controls array which controls have been
successfully written and which failed by for example adding a bit to the
control ID. Not sure if it is worth the effort, though.
3) Trying to set volatile inactive controls should result in -EACCESS.
4) Add a new flag to mark volatile controls. Any application that wants
to store the state of the controls can then skip volatile inactive controls.
Currently it is not possible to detect such controls.