Re: [PATCH 10/15] V4L: Add camera 3A lock control
Hi Sakari, On 04/24/2012 10:59 PM, Sakari Ailus wrote: Dzien dobry Sylwester, (I hope it's not too wrong time of the day for that! ;)) No, it's never too wrong;) Sylwester Nawrocki wrote: On 04/23/2012 07:47 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 04/17/2012 06:09 PM, Sakari Ailus wrote: On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: ... I was thinking how does the situation really differ from disabling the corresponding automatic algorithm. There may be subtle differences in practice albeit in principle the two are no different. And if some of the sensors implement it as lock, then I guess it gives us few options for the user space interface. Can you anticipate any any possible issues such diversity might bring to applications ? I imagine such control can be quite useful for snapshot, and with current control API design and the drivers' behaviour applications cannot be sure what settings a device ends up with after switching from auto to manual - last auto settings or the manual values. Usually its just the previous manual values. On software controlled digital cameras, depending on what the manual configuration actually means, you either get the same than by locking the automatic control or the previous manual configuration. If the means for manual configuration are the same than what the automatic algorithm uses then it's the first case. However, I have a feeling that such low level controls might often not work the best for manual control: for white balance users seldom wish to fiddle with SRGB matrix or gamma tables directly. Colour balance might just do mostly the same and be more convenient, with the automatic algorithm still doing some work to configure the underlying low-level configuration. I was thinking more along the lines of currently available V4L2 controls. And with cameras with I2C control interface there is often a device specific user interface of which characteristics are slightly different that what we would have implemented directly in software in user space. Perhaps it would make sense to suggest that the control algorithm locks should be implemented even in cases where the lock would mean exactly the same than just disabling the algorithm. What do you think? IMHO a driver should expose the control only if hardware supports locking. Once we have clear semantics for the lock control, it should be up to the driver's author to decide whether such functionality should be exposed or not. I believe the locking and disabling/enabling automatic settings will differ in most cases, there may be different latencies involved, etc. Also I think the lock control should have top priority, .e.g when the user sets V4L2_CID_AUTO_FOCUS_START control nothing should happen, unless V4L2_LOCK_FOCUS is set to 0. What do you think ? BTW, I've changed names of the individual lock bits an removed _3A prefix from them. It seems to look better that way: #define V4L2_CID_3A_LOCK(V4L2_CID_CAMERA_CLASS_BASE+27) #define V4L2_LOCK_EXPOSURE (1 0) #define V4L2_LOCK_WHITE_BALANCE (1 1) #define V4L2_LOCK_FOCUS (1 2) Or must we abide the rule that individual option names are created by only removing the _CID part from the control name and appending the option's name ? Shouldn't the lock be related to contiguous focus only btw.? Regular autofocus is typically a one-time operation, the lens ending up on a position where the AF algorithm left it. Perhaps, it would make sense mostly for continuous auto focus. However, I'm inclined to not limit it to continuous auto focus only. I think regardless of the focus mode the lock should freeze focusing, so still image capture is not disturbed. -- 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
Re: [PATCH 10/15] V4L: Add camera 3A lock control
Moikka Sakari, On 04/23/2012 07:47 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 04/17/2012 06:09 PM, Sakari Ailus wrote: On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? The difference looks quite obvious to me. When some AUTO control is switched from auto to manual mode there is no guarantee about the related parameters the device will end up. E.g. lens may be positioned into default position, rather than kept at current one, exposure might be set to manual value from before AE was enabled, etc. I've seen separate registers at the sensor interfaces for AE, AWB locking/unlocking and for disabling/enabling those algorithms. With the proposed control applications can be sure that, for example, exposure is retained when the V4L2_CID_3A_LOCK is set. Does it answer your question ? Yes, it does. I was thinking how does the situation really differ from disabling the corresponding automatic algorithm. There may be subtle differences in practice albeit in principle the two are no different. And if some of the sensors implement it as lock, then I guess it gives us few options for the user space interface. Can you anticipate any any possible issues such diversity might bring to applications ? I imagine such control can be quite useful for snapshot, and with current control API design and the drivers' behaviour applications cannot be sure what settings a device ends up with after switching from auto to manual - last auto settings or the manual values. Usually its just the previous manual values. Such a bitmask control looks quite useful to me. Moreover, at the moment there is no control that would provide similar functionality for auto focus. The bitmask control allows to easily control auto exposure, wb and focus atomically. However that's not a big deal, since this could be well achieved with the extended control API. Although V4L2_CID_3A_LOCK might be hard to implement in driver which use the control framework, since it would depend on multiple other controls. But this could be worked around by updating proper control current values and sending a control event from driver manually, unless you want to cluster almost all controls. -- 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
Re: [PATCH 10/15] V4L: Add camera 3A lock control
Dzien dobry Sylwester, (I hope it's not too wrong time of the day for that! ;)) Sylwester Nawrocki wrote: Moikka Sakari, On 04/23/2012 07:47 AM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 04/17/2012 06:09 PM, Sakari Ailus wrote: On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? The difference looks quite obvious to me. When some AUTO control is switched from auto to manual mode there is no guarantee about the related parameters the device will end up. E.g. lens may be positioned into default position, rather than kept at current one, exposure might be set to manual value from before AE was enabled, etc. I've seen separate registers at the sensor interfaces for AE, AWB locking/unlocking and for disabling/enabling those algorithms. With the proposed control applications can be sure that, for example, exposure is retained when the V4L2_CID_3A_LOCK is set. Does it answer your question ? Yes, it does. I was thinking how does the situation really differ from disabling the corresponding automatic algorithm. There may be subtle differences in practice albeit in principle the two are no different. And if some of the sensors implement it as lock, then I guess it gives us few options for the user space interface. Can you anticipate any any possible issues such diversity might bring to applications ? I imagine such control can be quite useful for snapshot, and with current control API design and the drivers' behaviour applications cannot be sure what settings a device ends up with after switching from auto to manual - last auto settings or the manual values. Usually its just the previous manual values. On software controlled digital cameras, depending on what the manual configuration actually means, you either get the same than by locking the automatic control or the previous manual configuration. If the means for manual configuration are the same than what the automatic algorithm uses then it's the first case. However, I have a feeling that such low level controls might often not work the best for manual control: for white balance users seldom wish to fiddle with SRGB matrix or gamma tables directly. Colour balance might just do mostly the same and be more convenient, with the automatic algorithm still doing some work to configure the underlying low-level configuration. Perhaps it would make sense to suggest that the control algorithm locks should be implemented even in cases where the lock would mean exactly the same than just disabling the algorithm. What do you think? Shouldn't the lock be related to contiguous focus only btw.? Regular autofocus is typically a one-time operation, the lens ending up on a position where the AF algorithm left it. Such a bitmask control looks quite useful to me. Moreover, at the moment there is no control that would provide similar functionality for auto focus. The bitmask control allows to easily control auto exposure, wb and focus atomically. However that's not a big deal, since this could be well achieved with the extended control API. Although V4L2_CID_3A_LOCK might be hard to implement in driver which use the control framework, since it would depend on multiple other controls. But this could be worked around by updating proper control current values and sending a control event from driver manually, unless you want to cluster almost all controls. Cheers, -- Sakari Ailus sakari.ai...@iki.fi -- 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: [PATCH 10/15] V4L: Add camera 3A lock control
Hi Sylwester, Sylwester Nawrocki wrote: Hi Sakari, On 04/17/2012 06:09 PM, Sakari Ailus wrote: Hi Sylwester, On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? The difference looks quite obvious to me. When some AUTO control is switched from auto to manual mode there is no guarantee about the related parameters the device will end up. E.g. lens may be positioned into default position, rather than kept at current one, exposure might be set to manual value from before AE was enabled, etc. I've seen separate registers at the sensor interfaces for AE, AWB locking/unlocking and for disabling/enabling those algorithms. With the proposed control applications can be sure that, for example, exposure is retained when the V4L2_CID_3A_LOCK is set. Does it answer your question ? Yes, it does. I was thinking how does the situation really differ from disabling the corresponding automatic algorithm. There may be subtle differences in practice albeit in principle the two are no different. And if some of the sensors implement it as lock, then I guess it gives us few options for the user space interface. -- Sakari Ailus sakari.ai...@iki.fi -- 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: [PATCH 10/15] V4L: Add camera 3A lock control
Hi Sakari, On 04/17/2012 06:09 PM, Sakari Ailus wrote: Hi Sylwester, On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? The difference looks quite obvious to me. When some AUTO control is switched from auto to manual mode there is no guarantee about the related parameters the device will end up. E.g. lens may be positioned into default position, rather than kept at current one, exposure might be set to manual value from before AE was enabled, etc. I've seen separate registers at the sensor interfaces for AE, AWB locking/unlocking and for disabling/enabling those algorithms. With the proposed control applications can be sure that, for example, exposure is retained when the V4L2_CID_3A_LOCK is set. Does it answer your question ? -- 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
[PATCH 10/15] V4L: Add camera 3A lock control
The V4L2_CID_3A_LOCK bitmask control allows applications to pause
or resume the automatic exposure, focus and wite balance adjustments.
It can be used, for example, to lock the 3A adjustments right before
a still image is captured, for pre-focus, etc.
The applications can control each of the algorithms independently,
through a corresponding control bit, if driver allows that.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Documentation/DocBook/media/v4l/controls.xml | 40 ++
drivers/media/video/v4l2-ctrls.c |2 ++
include/linux/videodev2.h|5
3 files changed, 47 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 5a3f78e..c0926c3 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3275,6 +3275,46 @@ lens-distortion correction./entry
/row
rowentry/entry/row
+ row
+ entry spanname=idconstantV4L2_CID_3A_LOCK/constant/entry
+ entrybitmask/entry
+ /row
+ row
+ entry spanname=descrThis control locks or unlocks the automatic
+exposure, white balance and focus. The automatic adjustments can be paused
+independently by setting the coresponding lock bit to 1. The camera then
retains
+the relevant 3A settings, until the lock bit is cleared. The value of this
+control may be changed by other, exposure, white balance or focus controls. The
+following are bit mask definitions for locking each algorithm independently:
+/entry
+ /row
+ row
+ entrytbl spanname=descr cols=2
+ tbody valign=top
+ row
+ entryconstantV4L2_3A_LOCK_EXPOSURE/constant/entry
+ entryAutomatic exposure adjustments lock./entry
+ /row
+ row
+ entryconstantV4L2_3A_LOCK_WHITE_BALANCE/constant/entry
+ entryAutomatic white balance adjustments lock./entry
+ /row
+ row
+ entryconstantV4L2_3A_LOCK_FOCUS/constant/entry
+ entryAutomatic focus adjustments lock./entry
+ /row
+ /tbody
+ /entrytbl
+ /row
+ rowentry spanname=descr
+When a particular algorithm is not enabled, drivers should ignore
+requests to lock it and should return no error. An example might be an
+application setting bit constantV4L2_3A_LOCK_WHITE_BALANCE/constant
+when constantV4L2_CID_AUTO_WHITE_BALANCE/constant control is set to
+constantFALSE/constant./entry
+ /row
+ rowentry/entry/row
+
/tbody
/tgroup
/table
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index f1d1ff2..e21f210 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -656,6 +656,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ISO_SENSITIVITY_AUTO: return ISO Sensitivity, Auto;
case V4L2_CID_EXPOSURE_METERING:return Exposure, Metering
Mode;
case V4L2_CID_SCENE_MODE: return Scene Mode;
+ case V4L2_CID_3A_LOCK: return 3A Lock;
/* FM Radio Modulator control */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -828,6 +829,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
break;
case V4L2_CID_FLASH_FAULT:
case V4L2_CID_JPEG_ACTIVE_MARKER:
+ case V4L2_CID_3A_LOCK:
*type = V4L2_CTRL_TYPE_BITMASK;
break;
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index a1fc9a8..4a60d5f 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1772,6 +1772,11 @@ enum v4l2_scene_mode {
V4L2_SCENE_MODE_TEXT= 13,
};
+#define V4L2_CID_3A_LOCK (V4L2_CID_CAMERA_CLASS_BASE+27)
+#define V4L2_3A_LOCK_EXPOSURE (1 0)
+#define V4L2_3A_LOCK_WHITE_BALANCE (1 1)
+#define V4L2_3A_LOCK_FOCUS (1 2)
+
/* FM Modulator class control IDs */
#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
--
1.7.10
--
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: [PATCH 10/15] V4L: Add camera 3A lock control
Hi Sylwester, On Tue, Apr 17, 2012 at 12:09:51PM +0200, Sylwester Nawrocki wrote: The V4L2_CID_3A_LOCK bitmask control allows applications to pause or resume the automatic exposure, focus and wite balance adjustments. It can be used, for example, to lock the 3A adjustments right before a still image is captured, for pre-focus, etc. The applications can control each of the algorithms independently, through a corresponding control bit, if driver allows that. How is disabling e.g. focus algorithm different from locking focus? Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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
