Commit 882a935c authored by Hans Verkuil's avatar Hans Verkuil Committed by Mauro Carvalho Chehab

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

Signed-off-by: default avatarHans Verkuil <hans.verkuil@cisco.com>
Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarMauro Carvalho Chehab <mchehab@redhat.com>
parent 5626b8c7
...@@ -495,18 +495,20 @@ Handling autogain/gain-type Controls with Auto Clusters ...@@ -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 A common type of control cluster is one that handles 'auto-foo/foo'-type
controls. Typical examples are autogain/gain, autoexposure/exposure, 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, that determines whether another control is handled automatically by the hardware,
or whether it is under manual control from the user. or whether it is under manual control from the user.
If the cluster is in automatic mode, then the manual controls should be 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 marked inactive and volatile. When the volatile controls are read the
operation should return the value that the hardware's automatic mode set up g_volatile_ctrl operation should return the value that the hardware's automatic
automatically. mode set up automatically.
If the cluster is put in manual mode, then the manual controls should become 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 active again and the volatile flag is cleared (so g_volatile_ctrl is no longer
is no longer called while in manual mode). 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 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. 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, ...@@ -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 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 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. 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. The first control of the cluster is assumed to be the 'auto' control.
...@@ -680,16 +686,6 @@ if there are no controls at all. ...@@ -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 count if nothing was done yet. If it is less than count then only the controls
up to error_idx-1 were successfully applied. 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 Proposals for Extensions
======================== ========================
...@@ -702,9 +698,3 @@ decimal. Useful for e.g. video_mute_yuv. ...@@ -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 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 successfully written and which failed by for example adding a bit to the
control ID. Not sure if it is worth the effort, though. 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.
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