[libcamera-devel] [PATCH] libcamera: pipeline: simple: Add support for controls
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Fri Dec 10 00:20:31 CET 2021
Hello,
On Thu, Dec 09, 2021 at 01:35:12PM +0100, Jacopo Mondi wrote:
> On Thu, Dec 09, 2021 at 10:57:43PM +1100, Benjamin Schaaf wrote:
> > On Thu, Dec 9, 2021 at 10:33 PM Jacopo Mondi wrote:
> > > On Thu, Dec 09, 2021 at 09:55:33PM +1100, Benjamin Schaaf wrote:
> > > > Thanks for the review, I'll put the updated patch at the end.
> > >
> > > Please don't :)
> > >
> > > Always send a new patch for new versions!
> >
> > No worries, I'll do that.
Another small comment, when sending a new version, could you tag the
patch(es) with the version number on the subject line ? There are plenty
of examples on the list. The -v option to git format-patch can help
there.
> > > > On Thu, Dec 9, 2021 at 7:57 PM Jacopo Mondi wrote:
> > > > > On Wed, Dec 08, 2021 at 11:35:23PM +1100, Benjamin Schaaf wrote:
> > > > > > Controls and control info are translated between libcamera and V4L2
> > > > > > inside the simple pipeline. Request controls are applied when a request
> > > > > > is next to be completed.
> > > > > >
> > > > > > This also adds some additional draft controls needed for the PinePhone.
This should likely be split in multiple patches:
- V4L2_CTRL_TYPE_BUTTON support
- New controls
- Simple pipeline handler changes
> > > > > Sorry to get straight to this before looking at the patch content, but
> > > > > we do enforce a code style as reported here
> > > > > https://libcamera.org/coding-style.html#coding-style-guidelines
> > > > >
> > > > > We have a tool that might help you catching style issues at
> > > > > utils/checkstyle.py
> > > > >
> > > > > Care to reformat your patches to comply with the project code style ?
Running checkstyle.py can also be automated with a git commit hook, this
is documented in coding-style.html too.
> > > > > > Signed-off-by: Benjamin Schaaf <ben.schaaf at gmail.com>
> > > > > > ---
> > > > > > src/libcamera/control_ids.yaml | 24 +++
> > > > > > src/libcamera/controls.cpp | 6 -
> > > > > > src/libcamera/pipeline/simple/controls.cpp | 230 +++++++++++++++++++++
> > > > > > src/libcamera/pipeline/simple/controls.h | 26 +++
> > > > > > src/libcamera/pipeline/simple/meson.build | 1 +
> > > > > > src/libcamera/pipeline/simple/simple.cpp | 30 ++-
> > > > > > 6 files changed, 310 insertions(+), 7 deletions(-)
> > > > > > create mode 100644 src/libcamera/pipeline/simple/controls.cpp
> > > > > > create mode 100644 src/libcamera/pipeline/simple/controls.h
> > > > > >
> > > > > > diff --git a/src/libcamera/control_ids.yaml b/src/libcamera/control_ids.yaml
> > > > > > index 9d4638ae..2af230c3 100644
> > > > > > --- a/src/libcamera/control_ids.yaml
> > > > > > +++ b/src/libcamera/control_ids.yaml
> > > > > > @@ -406,6 +406,30 @@ controls:
> > > > > > The camera will cancel any active or completed metering sequence.
> > > > > > The AE algorithm is reset to its initial state.
> > > > > >
> > > > > > + - AutoGain:
> > > > > > + type: bool
> > > > > > + draft: true
> > > > > > + description: |
> > > > > > + Control for Automatic Gain. Currently identical to V4L2_CID_AUTOGAIN.
Control of auto-exposure and auto-gain is under development. Patches are
available on the list, the latest version is
https://lists.libcamera.org/pipermail/libcamera-devel/2021-October/025410.html
if I'm not mistaken. Could you perhaps have a look and see if that would
cover your use cases ?
> > > > > > +
> > > > > > + - AfEnabled:
> > > > > > + type: bool
> > > > > > + draft: true
> > > > > > + description: |
> > > > > > + Control for AF. Currently identical to V4L2_CID_FOCUS_AUTO.
We'll also work on this, but a draft control as a shortcut is OK to
start with.
> > > > > > + - AfStart:
> > > > > > + type: void
> > > > >
> > > > > Why type void ? Isn't this a boolean ?
> > > >
> > > > V4L2_CID_AUTO_FOCUS_START has type V4L2_CTRL_TYPE_BUTTON, which simply
> > > > performs an action when the control is set. Thus type void. Same for
> > > > V4L2_CID_AUTO_FOCUS_END.
> > > >
> > > > It seems I forgot to include some required type conversion logic in
> > > > v4l2_device, not sure how that got missed.
> > >
> > > So you use void to indicate that we don't care about the value but the
> > > control presence signify that, in example, the autofocus routine
> > > should be started.
> > >
> > > We don't have 'one shot' control so far (the assumption is that once a
> > > control is set to a value, the value stays the same until it's not
> > > updated), and this could be a valid usage of type: void indeed
Interesting topic. I'm tempted to propose splitting it out to allow
discussing this without impacting the rest of the changes.
> > > > > > + draft: true
> > > > > > + description: |
> > > > > > + Control for AF. Currently identical to V4L2_CID_AUTO_FOCUS_START.
> > > > > > +
> > > > > > + - AfStop:
> > > > > > + type: void
> > > > > > + draft: true
> > > > > > + description: |
> > > > > > + Control for AF. Currently identical to V4L2_CID_AUTO_FOCUS_END.
> > > > > > +
> > > > >
> > > > > We're in the process of reworking controls related to gain and focus,
> > > > > but for the moment, as we comply with Android by having their controls
> > > > > defined as draft, I'm not opposed to have these here.
> > > > >
> > > > > I'm worried once we have applications use them, we will never move to
> > > > > the newly defined ones though unless we forcefully remove them in
> > > > > future...
> > > >
> > > > FWIW given that libcamera doesn't have versions/releases I don't
> > > > personally expect a stable API.
> > >
> > > In the long term, draft control will be replaced by standard controls.
> > > What I'm afraid of is that if applications start relying on draft
> > > controls it will be harder to remove them, as it will likely require a
> > > different type of mapping. But I have no better suggestions to provide
> > > atm
Applications should not rely on any part of the API being stable at the
moment :-)
This being said, don't those two controls duplicate AfTrigger ?
> > > > > > - AfTrigger:
> > > > > > type: int32_t
> > > > > > draft: true
> > > > > > diff --git a/src/libcamera/controls.cpp b/src/libcamera/controls.cpp
> > > > > > index 0d8c0a5c..1f65fc73 100644
> > > > > > --- a/src/libcamera/controls.cpp
> > > > > > +++ b/src/libcamera/controls.cpp
> > > > > > @@ -1052,9 +1052,6 @@ const ControlValue *ControlList::find(unsigned
> > > > > > int id) const
> > > > > > {
> > > > > > const auto iter = controls_.find(id);
> > > > > > if (iter == controls_.end()) {
> > > > > > - LOG(Controls, Error)
> > > > > > - << "Control " << utils::hex(id) << " not found";
> > > > > > -
> > > > >
> > > > > Ouch, why remove the error message ?
> > > >
> > > > My bad, seems I was misinterpreting when that error could show up.
> > > > I'll add it back in.
> > > >
> > > > > > return nullptr;
> > > > > > }
> > > > > >
> > > > > > @@ -1064,9 +1061,6 @@ const ControlValue *ControlList::find(unsigned
> > > > > > int id) const
> > > > > > ControlValue *ControlList::find(unsigned int id)
> > > > > > {
> > > > > > if (validator_ && !validator_->validate(id)) {
> > > > > > - LOG(Controls, Error)
> > > > > > - << "Control " << utils::hex(id)
> > > > > > - << " is not valid for " << validator_->name();
> > > > > > return nullptr;
> > > > > > }
> > > > > >
> > > > > > diff --git a/src/libcamera/pipeline/simple/controls.cpp
> > > > > > b/src/libcamera/pipeline/simple/controls.cpp
> > > > > > new file mode 100644
> > > > > > index 00000000..32695749
> > > > > > --- /dev/null
> > > > > > +++ b/src/libcamera/pipeline/simple/controls.cpp
> > > > > > @@ -0,0 +1,230 @@
> > > > >
> > > > > File license ? You can copy the SPDX header from other files and
> > > > > attribute the copyright to you or any one you like
> > > > >
> > > > > > +#include "controls.h"
> > > > > > +
> > > > > > +#include <linux/v4l2-controls.h>
> > > > > > +
> > > > > > +#include <libcamera/base/log.h>
> > > > > > +
> > > > > > +#include <libcamera/control_ids.h>
> > > > > > +
> > > > > > +namespace libcamera {
> > > > > > +
> > > > > > +LOG_DECLARE_CATEGORY(SimplePipeline)
> > > > > > +
> > > > > > +/*
> > > > > > + * These controls can be directly mapped between libcamera and V4L2 without
> > > > > > + * doing any conversion to the ControlValue.
> > > > > > + */
> > > > > > +static std::unordered_map<unsigned int, unsigned int> controlsToV4L2 = {
> > > > > > + { controls::AUTO_GAIN, V4L2_CID_AUTOGAIN },
> > > > > > + { controls::AF_ENABLED, V4L2_CID_FOCUS_AUTO },
> > > > > > + { controls::AF_START, V4L2_CID_AUTO_FOCUS_START },
> > > > > > + { controls::AF_STOP, V4L2_CID_AUTO_FOCUS_STOP },
> > > > > > + { controls::AE_ENABLE, V4L2_CID_EXPOSURE_AUTO },
> > > > > > + { controls::EXPOSURE_VALUE, V4L2_CID_EXPOSURE },
> > > > > > + { controls::DIGITAL_GAIN, V4L2_CID_GAIN },
> > > > > > + { controls::ANALOGUE_GAIN, V4L2_CID_ANALOGUE_GAIN },
> > > > > > + { controls::AF_STATE, V4L2_CID_AUTO_FOCUS_STATUS },
> > > > > > +};
> > > > >
> > > > > If them map is meant for internal use only you can declare it in an
> > > > > anonymous namespace
> > > > >
> > > > > namsepace {
> > > > > std::unordered_map<>...
> > > > >
> > > > > };
> > > > >
> > > > > namespace libcamera {
> > > > >
> > > > > };
> > > >
> > > > That's the same as static though?
> > >
> > > Yes but we usually prefer anonymous namespaces... Not a big deal
> > > though.
> > >
> > > > > > +
> > > > > > +/*
> > > > > > + * Convert from a libcamera control to a V4L2 control, optionally
> > > > > > also convert a
> > > > > > + * set of ControlValues.
> > > > > > + */
> > > > >
> > > > > We use doxygen for documenting the code. Please see other files as an
> > > > > example.
> > > > >
> > > > > > +bool simpleControlToV4L2(unsigned int control,
> > > > > > + unsigned int *v4l2_control,
> > > > > > + const ControlValue *control_values,
> > > > > > + ControlValue *v4l2_values,
> > > > > > + size_t num_values)
> > > > >
> > > > > Before looking at the implementation, let's reason a bit on the
> > > > > architecture.
> > > > >
> > > > > Is this control mapping valid for all platforms using the simple
> > > > > pipeline handler ?
> > > > >
> > > > > Is the device on which controls have to be applied the same for all
> > > > > platforms ?
> > > > >
> > > > > Should control handling be broken down to a platform specific
> > > > > component to be selected at compile time ?
> > > >
> > > > I'm not sure what you mean by platform here? Do you mean Linux vs
> > > > Android, x86 vs arm or PinePhone vs Librem 5?
> > >
> > > I mean the SoC.
> > >
> > > Simple is used (afaik) on imx6, imx8mq, allwinner, mediatek and
> > > possibly others.
> > >
> > > The mapping between v4l2 controls and libcamera controls does
> > > generically apply to all of them ? Surely not the values the controls
> > > transport, but if we assume the application knows what platform it
> > > operates on that's fine.
> >
> > I don't see how they wouldn't. The V4L2 controls are standardized in
> > the same way the android ones are. FWIW the controls aren't SoC
> > specific, they're sensor + SoC + device-tree specific.
>
> Oh I wish they are. They're definition is, that's for sure, where to
> apply them and how their values are interpreted much less so :)
>
> You know, I think the foundamental issue here is that if for
> SoC-specific pipeline handlers we have some sort of control about how
> the platform work and how the kernel infrastructure looks like, much
> less so can be assumed for simple.
>
> The first example which comes to mind is two platforms that registers the
> same control one on the sensor subdev the other on the video subdev.
> Maybe one requires only the sensor subdev to be operated, the other
> demands the video device to be operated too to have the control set ?
> Am I overthinking this ?
>
> In general, given that simple applies to many different platforms,
> where we have much less control on which kernel they run on, I'm a bit
> hesitant to assume anything generally applies and that's why I'm
> pushing for a platform-specific backend. Maybe I'm over concerned.
> Let's see what Laurent and others think, maybe my argument is just
> moot.
When it comes to this patch at least, sensors seem to be only related to
the camera sensor. I don't see anything that will apply to the entities
on the SoC side. I would (at least for now) hardcode this fact, and
apply controls on the CameraSensor only, ignoring all other entities and
video nodes.
> > > >
> > > > The way I see it, the simple pipeline is just a simple abstraction on
> > > > V4L2 and this is a simple conversion between V4L2 and libcamera
> > > > controls.
> > >
> > > This is a bit of a stretch.
> > >
> > > What's happening here is that you defined controls equal to the V4L2
> > > ones, and have the app set the 'right' values for the sensor/platform
> > > in use (a 'gain' value does not have the same meaning between
> > > different sensors, in example).
> > >
> > > In 'regular' platforms with an ISP, an IPA etc the pipeline receives
> > > libcamera::controls and with the help of IPA and statistics computes
> > > the right v4l2 controls for the platform (the pipeline handler knows
> > > what platform it runs on, except for simple) and for the sensor
> > > through a set of CameraSensorHelpers that aid with the translation.
> > >
> > > Now we change the landscape a bit, and we assume the app knows what
> > > platforms it runs on, something that defeats the purpose of libcamera
> > > usage, but I understand there aren't may way around that to support
> > > your use case.
> > >
> > > As a pipeline handler is charge of:
> > >
> > > 1) Registering what control it supports to expose that to application
> > > 2) Translate libcamera control to v4l2 controls (not in your case)
> > > 3) Apply controls to the right device/subdevice at the right time (the
> > > time when to set a control is not trivially calculated as most
> > > controls have a delay and should be applied in advance)
> > >
> > > Now assuming point 2) is moved to the app in your case, point 1 and 3
> > > do not apply generically to all platforms using the simple pipeline
> > > handler. Some might support control the other does not support. Some
> > > might want to set a control to the video devices while others will
> > > apply the same control on the sensor subdev. It all very depends on
> > > the driver architecture of the SoC.
> > >
> > > Now, even for simple boolean/button controls like the ones you're dealing with,
> > > for which not much reasoning and translations are required, a platform
> > > specific component seems to be needed to address 1) and 3).
> > >
> > > Does it make sense to you ?
> >
> > In terms of registering what controls are exposed that's done
> > generically in SimpleCameraData::init right? As for when controls are
>
> Only the ones available from the sensor in your implementation.
>
> I have no problems with that in general, I just wonder if this
> shouldn't be made specific to your platform. As an example
> libcamera::controls relative to the CropRectangle might need to be
> registered and those depends on the whole capture pipeline
> configuration, not just the sensor.
>
> > applied the assumption being made in libcamera is that they can be
> > applied before a frame no?
>
> Ah well, applying them -after- a frame would not help much :)
>
> Long story short: as long as you don't care about per-frame control
> you can apply a control more or less whenever. V4L2 has a weird way of
> handling some controls (the way VBLANK and EXPOSURE inter-operates in
> example requires you to prioritize updating the blankings to be able
> to apply the desired exposure) and some controls might take several
> frames to apply (VCM which has mechanical moving parts is the first example,
> but also gains and exposure according to what I see in the delays
> registered in example by RPi in src/ipa/raspberrypi/cam_helper_*).
> But yes, assuming you don't care about precise controls handling,
> apply a control as soon as you receive it might work to some extents.
I think we could greatly improve the timings by applying controls in a
V4L2Device::frameStart() handler and using DelayedControls. This doesn't
have to be implemented immediately, but that's the target we should
eventually reach.
VBLANK is something I wouldn't expose through libcamera controls. We
have frame durations, manual exposure times and auto/manual exposure
control, VBLANK (and other timing parameters) should be computed from
those. That's usually the job of the IPA, but we could do so in the
pipeline handler too. Another option would be to create a generic IPA
module, but I think that would be a bit overkill in this case as it
would do very little.
> I was more concerned about where the control should be applied, video
> device, sensor subdevice, VCM subdev etc. This is platform dependent
> and again, simple works on many different platforms we're not in
> control of and as soon as the list of supported contorls grows beyond
> the ones you have defined here I'm afraid things might quickly go out
> of synch.
Generally speaking I'd agree, but I think we can set some baseline
requirements that drivers need to comply with to be supported by the
simple pipeline handler. One of them could be that the camera sensor
controls must be exposed by the camera sensor subdev. We already require
an MC-centric driver, so this should already be the case.
I'm thus a bit less concerned than Jacopo, but there's one concern I
have that he hasn't voiced. The code needs to translate the value of the
controls between libcamera and V4L2. Unlike V4L2, libcamera standardizes
control units and values. There's an implementation of this in the UVC
pipeline handler, but we'll need something more complex here as the UVC
pipeline handler can rely on V4L2 controls being compliant with the UVC
specification, and we ca make no assumption.
A very good example is the analog gain control, which is exposed as a
number by V4L2 without any unit or model. You can see what we have to do
to translate gains to control values in
src/ipa/libipa/camera_sensor_helper.cpp, with sensor-specific data. We
discussed in the past the option of adding V4L2 controls to expose the
gain model parameters to userspace, and decided to hardcode them in
libcamera instead.
One way forward would be to move the CameraSensorHelper from libipa to
libcamera, and handle the translate in the CameraSensor class. IPA
modules would have to be updated to pass libcamera controls through the
IPA API (that shouldn't be too hard). We would lose the ability on the
IPA side to know how a value will be rounded to a V4L2 control, but that
doesn't seem to be an issue.
This would simplify the implementation in the simple pipeline handler,
as it will be able to rely on the CameraSensor class implementing the
translation of control values.
> Again, maybe I'm over concerned, let's see what others think.
>
> > > > > Also, I would like to see this implemented thorough a componenet with
> > > > > a single interface towards the pipeline handler rather than a raw set
> > > > > of helper functions. We can indeed help designing that once we have
> > > > > the previous question clarified.
> > > > >
> > > > > I'm not even sure this is the direction we want to got with the simple
> > > > > pipeline handler (platform-specific backends), and I would like to
> > > > > hear Laurent's opinion on this, but I see a potential for doing what
> > > > > we do with the android backend selection through the
> > > > > 'android_platform' build option.
> > > > >
> > > > > option('android_platform',
> > > > > type : 'combo',
> > > > > choices : ['cros', 'generic'],
> > > > > value : 'generic',
> > > > > description : 'Select the Android platform to compile for')
> > > > >
> > > > > > +{
> > > > > > + // Convert controls
> > > > > > + if (v4l2_control) {
> > > > > > + auto it = controlsToV4L2.find(control);
> > > > > > + if (it == controlsToV4L2.end())
> > > > > > + return false;
> > > > > > +
> > > > > > + *v4l2_control = it->second;
> > > > > > + }
> > > > > > +
> > > > > > + // Convert values
> > > > > > + if (num_values == 0)
> > > > > > + return true;
> > > > > > +
> > > > > > + switch (control) {
> > > > > > + case controls::AE_ENABLE:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + v4l2_values[i] = ControlValue((int32_t)(control_values[i].get<bool>() ? V4L2_EXPOSURE_AUTO : V4L2_EXPOSURE_MANUAL));
> > > > > > + return true;
> > > > > > + case controls::EXPOSURE_VALUE:
> > > > > > + case controls::DIGITAL_GAIN:
> > > > > > + case controls::ANALOGUE_GAIN:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + v4l2_values[i] = ControlValue((int32_t)control_values[i].get<float>());
> > > > > > + return true;
> > > > > > + // Read only
> > > > > > + case controls::AF_STATE:
> > > > > > + return false;
> > > > > > + default:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + v4l2_values[i] = control_values[i];
> > > > > > + return true;
> > > > > > + }
> > > > > > +
> > > > > > +}
> > > > > > +
> > > > > > +static std::unordered_map<unsigned int, unsigned int> controlsFromV4L2;
> > > > > > +
> > > > > > +/*
> > > > > > + * Convert from a V4L2 control to a libcamera control, optionally also convert a
> > > > > > + * set of ControlValues.
> > > > > > + */
> > > > > > +bool simpleControlFromV4L2(unsigned int v4l2_control,
> > > > > > + unsigned int *control,
> > > > > > + const ControlValue *v4l2_values,
> > > > > > + ControlValue *control_values,
> > > > > > + size_t num_values)
> > > > > > +{
> > > > > > + // Initialize the inverse of controlsToV4L2
> > > > > > + if (controlsFromV4L2.empty()) {
> > > > > > + for (const auto &v : controlsToV4L2) {
> > > > > > + controlsFromV4L2[v.second] = v.first;
> > > > > > + }
> > > > > > + }
> > > > > > +
> > > > > > + // Convert control
> > > > > > + if (control) {
> > > > > > + auto it = controlsFromV4L2.find(v4l2_control);
> > > > > > + if (it == controlsFromV4L2.end())
> > > > > > + return false;
> > > > > > +
> > > > > > + *control = it->second;
> > > > > > + }
> > > > > > +
> > > > > > + // Convert values
> > > > > > + if (num_values == 0)
> > > > > > + return true;
> > > > > > +
> > > > > > + switch (v4l2_control) {
> > > > > > + case V4L2_CID_EXPOSURE_AUTO:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + control_values[i] = ControlValue(v4l2_values[i].get<int32_t>() == V4L2_EXPOSURE_AUTO);
> > > > > > + return true;
> > > > > > + case V4L2_CID_EXPOSURE:
> > > > > > + case V4L2_CID_GAIN:
> > > > > > + case V4L2_CID_ANALOGUE_GAIN:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + control_values[i] = ControlValue((float)v4l2_values[i].get<int32_t>());
> > > > > > + return true;
> > > > > > + case V4L2_CID_AUTO_FOCUS_STATUS:
> > > > > > + for (size_t i = 0; i < num_values; ++i) {
> > > > > > + switch (v4l2_values[i].get<int32_t>()) {
> > > > > > + case V4L2_AUTO_FOCUS_STATUS_IDLE:
> > > > > > + control_values[i] = ControlValue((int32_t)controls::draft::AfStateInactive);
> > > > > > + break;
> > > > > > + case V4L2_AUTO_FOCUS_STATUS_BUSY:
> > > > > > + control_values[i] = ControlValue((int32_t)controls::draft::AfStateActiveScan);
> > > > > > + break;
> > > > > > + case V4L2_AUTO_FOCUS_STATUS_REACHED:
> > > > > > + control_values[i] = ControlValue((int32_t)controls::draft::AfStatePassiveFocused);
> > > > > > + break;
> > > > > > + case V4L2_AUTO_FOCUS_STATUS_FAILED:
> > > > > > + control_values[i] = ControlValue((int32_t)controls::draft::AfStatePassiveUnfocused);
> > > > > > + break;
> > > > > > + default:
> > > > > > + LOG(SimplePipeline, Error)
> > > > > > + << "AUTO_FOCUS_STATUS has invalid value: "
> > > > > > + << utils::hex(v4l2_values[i].get<int32_t>());
> > > > > > + /*TODO: Log Error*/
> > > > > > + return false;
> > > > > > + }
> > > > > > + }
> > > > > > + return true;
> > > > > > + default:
> > > > > > + for (size_t i = 0; i < num_values; ++i)
> > > > > > + control_values[i] = v4l2_values[i];
> > > > > > + return true;
> > > > > > + }
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Convert a ControlInfoMap from V4L2 to libcamera. Converts both the control
> > > > > > + * identifiers as well as all values.
> > > > > > + */
> > > > > > +ControlInfoMap simpleControlInfoFromV4L2(const ControlInfoMap &v4l2_info_map)
> > > > > > +{
> > > > > > + ControlInfoMap::Map info_map;
> > > > > > +
> > > > > > + for (const auto &pair : v4l2_info_map) {
> > > > > > + unsigned int v4l2_control = pair.first->id();
> > > > > > + const ControlInfo &v4l2_info = pair.second;
> > > > > > +
> > > > > > + unsigned int control;
> > > > > > + ControlValue def;
> > > > > > + if (!simpleControlFromV4L2(v4l2_control, &control, &v4l2_info.def(), &def, 1))
> > > > > > + continue;
> > > > > > +
> > > > > > + const ControlId *control_id = controls::controls.at(control);
> > > > > > +
> > > > > > + // ControlInfo has either a list of values or a minimum and
> > > > > > + // maximum. This includes controls that have no values or are
> > > > > > + // booleans.
> > > > > > + ControlInfo info;
> > > > > > + if (v4l2_info.values().empty()) {
> > > > > > + ControlValue min, max;
> > > > > > + simpleControlFromV4L2(v4l2_control, nullptr, &v4l2_info.min(), &min, 1);
> > > > > > + simpleControlFromV4L2(v4l2_control, nullptr, &v4l2_info.max(), &max, 1);
> > > > > > + info = ControlInfo(std::move(min), std::move(max), std::move(def));
> > > > > > + } else {
> > > > > > + std::vector<ControlValue> values;
> > > > > > + values.resize(v4l2_info.values().size());
> > > > > > + simpleControlFromV4L2(v4l2_control, nullptr, v4l2_info.values().data(), values.data(), values.size());
> > > > > > + info = ControlInfo(std::move(values), std::move(def));
> > > > > > + }
> > > > > > + info_map.emplace(control_id, std::move(info));
> > > > > > + }
> > > > > > +
> > > > > > + return ControlInfoMap(std::move(info_map), controls::controls);
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Convert a control list from libcamera to V4L2.
> > > > > > + */
> > > > > > +ControlList simpleControlListToV4L2(const ControlList &controls)
> > > > > > +{
> > > > > > + ControlList v4l2_controls;
> > > > > > + for (const auto &pair : controls) {
> > > > > > + unsigned int control = pair.first;
> > > > > > + const ControlValue &value = pair.second;
> > > > > > +
> > > > > > + unsigned int v4l2_control;
> > > > > > + ControlValue v4l2_value;
> > > > > > + if (!simpleControlToV4L2(control, &v4l2_control, &value, &v4l2_value, 1)) {
> > > > > > + LOG(SimplePipeline, Warning)
> > > > > > + << "Control " << utils::hex(control)
> > > > > > + << " does not have a V4L2 equivalent";
> > > > > > + continue;
> > > > > > + }
> > > > > > +
> > > > > > + v4l2_controls.set(v4l2_control, v4l2_value);
> > > > > > + }
> > > > > > + return v4l2_controls;
> > > > > > +}
> > > > > > +
> > > > > > +/*
> > > > > > + * Convert a control list from V4L2 to libcamera.
> > > > > > + */
> > > > > > +ControlList simpleControlListFromV4L2(const ControlList &v4l2_controls)
> > > > > > +{
> > > > > > + ControlList controls;
> > > > > > + for (const auto &pair : v4l2_controls) {
> > > > > > + unsigned int v4l2_control = pair.first;
> > > > > > + const ControlValue &v4l2_value = pair.second;
> > > > > > +
> > > > > > + unsigned int control;
> > > > > > + ControlValue value;
> > > > > > + if (simpleControlFromV4L2(v4l2_control, &control, &v4l2_value, &value, 1))
> > > > > > + controls.set(control, value);
> > > > > > + }
> > > > > > + return controls;
> > > > > > +}
> > > > > > +
> > > > > > +} /* namespace libcamera */
> > > > > > diff --git a/src/libcamera/pipeline/simple/controls.h
> > > > > > b/src/libcamera/pipeline/simple/controls.h
> > > > > > new file mode 100644
> > > > > > index 00000000..114c5fc2
> > > > > > --- /dev/null
> > > > > > +++ b/src/libcamera/pipeline/simple/controls.h
> > > > >
> > > > > Same comment, license and copyright
> > > > >
> > > > > > @@ -0,0 +1,26 @@
> > > > > > +#ifndef __LIBCAMERA_PIPELINE_SIMPLE_CONTROLS_H__
> > > > > > +#define __LIBCAMERA_PIPELINE_SIMPLE_CONTROLS_H__
> > > > >
> > > > > #pragma once
> > > >
> > > > All the code I've seen uses #ifndef instead of #pragma once. I'd
> > > > prefer to use #pragma once but it seems inconsistent with the rest of
> > > > the codebase?
> > >
> > > Not since
> > > https://patchwork.libcamera.org/project/libcamera/list/?series=2749&state=*
> > >
> > > > > > +
> > > > > > +#include <libcamera/controls.h>
> > > > > > +
> > > > > > +namespace libcamera {
> > > > > > +
> > > > > > +bool simpleControlToV4L2(unsigned int control,
> > > > > > + unsigned int *v4l2_control,
> > > > > > + const ControlValue *control_values,
> > > > > > + ControlValue *v4l2_values,
> > > > > > + size_t num_values);
> > > > > > +bool simpleControlFromV4L2(unsigned int v4l2_control,
> > > > > > + unsigned int *control,
> > > > > > + const ControlValue *v4l2_values,
> > > > > > + ControlValue *control_values,
> > > > > > + size_t num_values);
> > > > > > +
> > > > > > +ControlInfoMap simpleControlInfoFromV4L2(const ControlInfoMap &v4l2_info);
> > > > > > +
> > > > > > +ControlList simpleControlListToV4L2(const ControlList &controls);
> > > > > > +ControlList simpleControlListFromV4L2(const ControlList &controls);
> > > > > > +
> > > > > > +} /* namespace libcamera */
> > > > > > +
> > > > > > +#endif /* __LIBCAMERA_PIPELINE_SIMPLE_CONTROLS_H__ */
> > > > > > diff --git a/src/libcamera/pipeline/simple/meson.build
> > > > > > b/src/libcamera/pipeline/simple/meson.build
> > > > > > index 9c99b32f..0c60d65a 100644
> > > > > > --- a/src/libcamera/pipeline/simple/meson.build
> > > > > > +++ b/src/libcamera/pipeline/simple/meson.build
> > > > > > @@ -1,6 +1,7 @@
> > > > > > # SPDX-License-Identifier: CC0-1.0
> > > > > >
> > > > > > libcamera_sources += files([
> > > > > > + 'controls.cpp',
> > > > > > 'converter.cpp',
> > > > > > 'simple.cpp',
> > > > > > ])
> > > > > > diff --git a/src/libcamera/pipeline/simple/simple.cpp
> > > > > > b/src/libcamera/pipeline/simple/simple.cpp
> > > > > > index a597e27f..b0d4a62a 100644
> > > > > > --- a/src/libcamera/pipeline/simple/simple.cpp
> > > > > > +++ b/src/libcamera/pipeline/simple/simple.cpp
> > > > > > @@ -37,6 +37,7 @@
> > > > > > #include "libcamera/internal/v4l2_videodevice.h"
> > > > > >
> > > > > > #include "converter.h"
> > > > > > +#include "controls.h"
We sort headers alphabetically.
> > > > > >
> > > > > > namespace libcamera {
> > > > > >
> > > > > > @@ -181,6 +182,7 @@ public:
> > > > > > int setupLinks();
> > > > > > int setupFormats(V4L2SubdeviceFormat *format,
> > > > > > V4L2Subdevice::Whence whence);
> > > > > > + int setRequestControls(Request *request);
> > > > > > void bufferReady(FrameBuffer *buffer);
> > > > > >
> > > > > > unsigned int streamIndex(const Stream *stream) const
> > > > > > @@ -519,7 +521,8 @@ int SimpleCameraData::init()
> > > > > > formats_[fmt] = &config;
> > > > > > }
> > > > > >
> > > > > > - properties_ = sensor_->properties();
> > > > > > + properties_ = simpleControlListFromV4L2(sensor_->properties());
I don't think this is right, CameraSensor::properties() returns a
ControlList of libcamera controls, not V4L2 controls.
> > > > > > + controlInfo_ = simpleControlInfoFromV4L2(sensor_->controls());
> > > > > >
> > > > > > return 0;
> > > > > > }
> > > > > > @@ -624,6 +627,23 @@ int
> > > > > > SimpleCameraData::setupFormats(V4L2SubdeviceFormat *format,
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +int SimpleCameraData::setRequestControls(Request *request)
> > > > > > +{
> > > > > > + SimplePipelineHandler *pipe = SimpleCameraData::pipe();
> > > > > > +
> > > > > > + // Apply controls only to one entity. If there's a subdevice use that.
> > > > > > + V4L2Device *control_device = video_;
> > > > > > + for (const SimpleCameraData::Entity &e : entities_) {
> > > > > > + V4L2Subdevice *subdev = pipe->subdev(e.entity);
> > > > > > + if (subdev) {
> > > > > > + control_device = subdev;
> > > > > > + }
> > > > > > + }
> > > > > > +
> > > > > > + ControlList controls = simpleControlListToV4L2(request->controls());
> > > > > > + return control_device->setControls(&controls);
Could this be simplified by setting controls on the CameraSensor
unconditionally ?
> > > > > > +}
> > > > > > +
> > > > > > void SimpleCameraData::bufferReady(FrameBuffer *buffer)
> > > > > > {
> > > > > > SimplePipelineHandler *pipe = SimpleCameraData::pipe();
> > > > > > @@ -666,6 +686,10 @@ void SimpleCameraData::bufferReady(FrameBuffer *buffer)
> > > > > > return;
> > > > > > }
> > > > > >
> > > > > > + // Set the controls for the next queued request
> > > > > > + if (!queuedRequests_.empty())
> > > > > > + setRequestControls(queuedRequests_.front());
We should ideally apply controls in a frame start handler (connected to
the V4L2Device::frameStart signal), but we can start with setting
controls here. A \todo comment would be good.
> > > > > > +
> > > > > > /*
> > > > > > * Record the sensor's timestamp in the request metadata. The request
> > > > > > * needs to be obtained from the user-facing buffer, as internal
> > > > > > @@ -1033,6 +1057,10 @@ int SimplePipelineHandler::start(Camera
> > > > > > *camera, [[maybe_unused]] const ControlL
> > > > > > return ret;
> > > > > > }
> > > > > >
> > > > > > + // Apply controls from first request
> > > > > > + if (!data->queuedRequests_.empty())
> > > > > > + data->setRequestControls(data->queuedRequests_.front());
This should also apply controls passed to the start() function.
> > > > > > +
> > > > > > if (data->useConverter_) {
> > > > > > ret = data->converter_->start();
> > > > > > if (ret < 0) {
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list