[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250715235952.GE19299@pendragon.ideasonboard.com>
Date: Wed, 16 Jul 2025 02:59:52 +0300
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Mirela Rabulea <mirela.rabulea@....com>
Cc: mchehab@...nel.org, sakari.ailus@...ux.intel.com,
hverkuil-cisco@...all.nl, ribalda@...omium.org,
jai.luthra@...asonboard.com, laurentiu.palcu@....com,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
LnxRevLi@....com, julien.vuillaumier@....com,
celine.laurencin@....com
Subject: Re: [RFC 0/2] Add standard exposure and gain controls for multiple
captures
Hi Mirela,
On Fri, Jul 11, 2025 at 01:05:42AM +0300, Mirela Rabulea wrote:
> Add new standard controls as U32 arrays, for sensors with multiple
> captures: V4L2_CID_EXPOSURE_MULTI, V4L2_CID_AGAIN_MULTI and
> V4L2_CID_DGAIN_MULTI. These will be particularly useful for sensors
> that have multiple captures, but the HDR merge is done inside the sensor,
> in the end exposing a single stream, but still requiring AEC control
> for all captures.
It's also useful for sensors supporting DOL or DCG with HDR merge being
performed outside of the sensor.
> All controls are in the same class, so they could all be set
> atomically via VIDIOC_S_EXT_CTRLS, this could turn out to be
> useful in case of sensors with context switching.
Agreed, we should be able to set them all. Are we still unable to set
controls from multiple classes atomatically ? I thought that limitation
has been lifted.
> Each element of the array will hold an u32 value (exposure or gain)
> for one capture. The size of the array is up to the sensor driver which
> will implement the controls and initialize them via v4l2_ctrl_new_custom().
> With this approach, the user-space will have to set valid values
> for all the captures represented in the array.
I'll comment on the controls themselves in patch 2/2.
> The v4l2-core only supports one scalar min/max/step value for the
> entire array, and each element is validated and adjusted to be within
> these bounds in v4l2_ctrl_type_op_validate(). The significance for the
> maximum value for the exposure control could be "the max value for the
> long exposure" or "the max value for the sum of all exposures". If none
> of these is ok, the sensor driver can adjust the values as supported and
> the user space can use the TRY operation to query the sensor for the
> minimum or maximum values.
Hmmmm... I wonder if we would need the ability to report different
limits for different array elements. There may be over-engineering
though, my experience with libcamera is that userspace really needs
detailed information about those controls, and attempting to convey the
precise information through the kernel-userspace API is bound to fail.
That's why we implement a sensor database in libcamera, with information
about how to convert control values to real gain and exposure time.
Exposing (close to) raw register values and letting userspace handle the
rest may be better.
> Mirela Rabulea (2):
> LF-15161-6: media: Add exposure and gain controls for multiple
> captures
> LF-15161-7: Documentation: media: Describe exposure and gain controls
> for multiple captures
Did you forget to remove the LF-* identifiers ? :-)
>
> .../media/v4l/ext-ctrls-image-source.rst | 12 ++++++++++++
> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 8 ++++++++
> include/uapi/linux/v4l2-controls.h | 3 +++
> 3 files changed, 23 insertions(+)
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists