The ControlId and Control classes disable the copy constructor and
assignment operator, but they should also prevent move construction and
assignment.
Utilise LIBCAMERA_DISABLE_COPY_AND_MOVE to fully disable these
functions.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Following the C++17 practice, provide is_array_v<T> and is_span_v<T>
helper variable templates as shorter versions of is_array<T>::value and
is_span<T>::value, and use them through the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
C++17 introduces helper variable templates for type traits, allowing
shortening std::is_foo<T>::value to std::is_foo_v<T>. Use them through
the code base.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add a new constructor to the ControlInfo class that allows creating
a class instance from the list of the control valid values with
an optional default one.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The ControlValue<T> constructor for non-array values is a template
function that participates in overload resolution for all T types that
are not Span or std::string. Other T types that are not supported then
result in a compilation error.
This causes issues when calling an overloaded function that can accept
both a ControlValue and a Span with an std::array<U> parameter. The
first overload will be resolved using implicit construction of a
ControlValue from the std::array<U>, while the second overload will be
resolved using implicit construction of a Span<U> from the
std::array<U>. This results in a compilation error due to an ambiguous
function call.
The first overload is invalid, selecting it would result in a
compilation error in the ControlValue constructor, as the
ControlValue<T> constructor doesn't support std::array<U> for type T.
The compiler can't know about that, as overload resolution happens
earlier.
To fix it, we can disable the ControlValue<T> constructor for
unsupported types T, moving the type check from compilation of the
function to overload resolution. The constructor will not participate in
overload resolution, and the call won't be ambiguous. The end result is
the same for unsupported types, compilation will fail.
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Extend the ControlValue class with a reserve() function to set the value
without actually copying data, and a non-const data() function that
allows writing data directly to the ControlValue storage. This allows
allocating memory directly in ControlValue, potentially removing a data
copy.
Note that this change was implemented before ByteStreamBuffer gained the
zero-copy read() variant, and doesn't actually save a copy in the
control serializer. It however still simplifies
ControlSerializer::loadControlValue().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The ControlValue class size should be minimized to save space, as it can
be instantiated in large numbers. The current implementation does so by
specifying several members as bitfields, but does so too aggressively,
resulting in fields being packed in an inefficient to access way on some
platforms. For instance, on 32-bit x86, the numElements_ field is offset
by 7 bits in a 32-bit word. This additionally causes a static assert
that checks the size of the class to fail.
Relax the constraints on the isArray_ and numElements_ fields to avoid
inefficient access, and to ensure that the class size is identical
across all platforms. This will need to be revisited anyway when
stabilizing the ABI, so add a \todo comment as a reminder.
Fixes: 1fa4b43402 ("libcamera: controls: Support array controls in ControlValue")
Reported-by: Jan Engelhardt <jengelh@inai.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The size of the ControlValue class is checked by a static_assert() to
avoid accidental ABI breakages. There's no need to perform the check
every time controls.h is included, move it to controls.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
String controls are stored internally as an array of char, but the
ControlValue constructor, get() and set() functions operate on an
std::string for convenience. Array of strings are thus not supported.
Unlike for other control types, the ControlInfo range reports the
minimum and maximum allowed lengths of the string (the minimum will
usually be 0), not the minimum and maximum value of each element.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To prepare for storage of additional information in the ControlRange
structure, rename it to ControlInfo.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To prepare for the rename of ControlRange to ControlInfo, rename all the
ControlInfoMap instance variables currently named info to infoMap. This
will help avoiding namespace clashes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
gcc 8.3.0 for ARM complains about strict aliasing violations:
../../src/libcamera/controls.cpp: In member function ‘void libcamera::ControlValue::release()’:
../../src/libcamera/controls.cpp:111:13: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
delete[] *reinterpret_cast<char **>(&storage_);
Fix it and simplify the code at the same time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
For array controls, the ControlList::set() function takes a value as a
type convertible to Span<T>. This allows passing an std::array or an
std::vector in addition to an explicit Span, but doesn't accept an
std::initializer list as Span has no constructor that takes an
initializer list. Callers are thus forced to create temporary objects
explicitly, which isn't nice.
Fix the issue by providing a ControlList::set() function that takes an
std::initializer_list, and convert it to a Span internally.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add array controls support to the ControlValue class. The polymorphic
class can now store more than a single element and supports access and
creation through the use of Span<>.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add a data() function to the ControlValue class to expose the raw data
stored by the class as a Span<const uint8_t>. This will be useful to
simplify the serialization of ControlValue instances.
The size computation for the raw data is moved from the
ControlSerializer, which is updated accordingly to use the data()
function in order to access the size. Simplification of the
ControlSerializer will happen in a subsequent change.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To avoid defining all specializations of the Control constructor
manually, move the definition of those functions to controls.h and turn
them into a single template function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To avoid defining all specializations of the ControlValue constructor
manually, move the definition of those functions to controls.h and turn
them into a single template function. The default constructor is still
kept in controls.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To avoid defining all specializations of ControlValue::get() and
ControlValue::set() manually, move the definition of those functions to
controls.h and turn them into single template functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The ControlList::get() and ControlValue::get() methods return the
control value by reference. This requires the ControlValue class to
store the control value in the same form as the one returned by those
functions. For the array controls that are soon to be added, the
ControlValue class would need to store a span<> instance in addition to
the control value itself, which would increase the required storage
space.
Prepare for support of array controls by returning from get() by value.
As all control values are 8 bytes at most, this doesn't affect
efficiency negatively.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The ControlList::set() method takes a reference to a Control<T>, and
requires the value to be a reference to T. This prevents the set()
method from being used with value types that are convertible to T, and
in particular with std::array or std::vector value types when the
Control type is a Span<> to support array controls.
Fix this by decoupling the control type and value type in the template
parameters. The compiler will still catch invalid conversions, including
cases where the constructor of type T from the value type is explicit.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Augment the the ControlRange class to store the control default value.
This is particularly relevant for v4l2 controls used to create
Camera properties, which are constructed using immutable video device
properties, whose value won't change at runtime.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Store a reference to the ControlInfoMap used to create a ControlList and
provide an operation to retrieve it. This will be used to implement
serialization of ControlList.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
In preparation for serialization, index the ControlList by unsigned int.
This will allow deserializing a ControlList without requiring external
information.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The V4L2ControlList class only provides a convenience constructor for
the ControlList, which can easily be moved to the ControlList class and
may benefit it later (to construct a ControlList from controls supported
by a camera). Move the constructor and remove V4L2ControlList.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The ControlInfoMap and V4L2ControlInfoMap classes are very similar, with
the latter adding convenience accessors based on numerical IDs for the
former, as well as a cached idmap. Both features can be useful for
ControlInfoMap in the context of serialisation, and merging the two
classes will further simplify the IPA API.
Import all the features of V4L2ControlInfoMap into ControlInfoMap,
turning the latter into a real class. A few new constructors and
assignment operators are added for completeness.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Now that the V4L2ControlId embedded in V4L2ControlInfo has been moved
out and doesn't require to be copied anymore, the base ControlId class
doesn't need to be copyable either. Delete the ControlId copy
constructor and copy assignment operator.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a V4L2 specialisation of the ControlId class, in order to construct
a ControlId from a v4l2_query_ext_ctrl. The V4L2ControlId is embedded in
V4L2ControlInfo, and thus needs to be copyable to allow for
V4L2ControlInfo to be passed to IPAs. The ControlId copy constructor and
assignment operators are thus restored, but made protected to avoid the
Control class being copyable.
This is needed in order to use ControlList for V4L2 controls, as
ControlList requires ControlId instances for all controls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlList class has template get() and set() methods to get and
set control values. The methods require a reference to a Control
instance, which is only available when calling them with a hardcoded
control. In order to support usage of ControlList for V4L2 controls, as
well as serialisation and deserialisation of ControlList, we need a way
to get and set control values based on a control numerical ID. Add new
contains(), get() and set() overload methods to do so.
As this change prepares the ControlList to be used for other objects
than camera, update its documentation accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlId class stores a pointer to the control name. This works
fine for statically-defined controls, but requires code that allocates
controls dynamically (for instance based on control discovery on a V4L2
device) to keep a list of control names in separate storage. To ease
usage of dynamically allocated controls, store a copy of the control
name string in the ControlId class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlInfo class stores a range of valid values for a control. Its
name is vague, as "info" has multiple meanings. Rename it to
ControlRange.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlInfo id member is only used in the toString() method of the
class, and nowhere else externally. The same way that ControlValue
doesn't store a ControlId, ControlInfo shouldn't. Remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ControlList::update() method is unused. While it is meant to fulfil
a need of applications, having no user means that it is most probably
not correctly designed. Remove the method, we will add it back later if
needed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Rework the control-related classes to improve the API towards
applications. The goal is to enable writing code similar to
Request *req = ...;
ControlList &controls = req->controls();
controls->set(controls::AwbEnable, false);
controls->set(controls::ManualExposure, 1000);
...
int32_t exposure = controls->get(controls::ManualExposure);
with the get and set operations ensuring type safety for the control
values. This is achieved by creating the following classes:
- Control defines controls and is the main way to reference a control.
It is a template class to allow methods using it to refer to the
control type.
- ControlId is the base class of Control. It stores the control ID, name
and type, and can be used in contexts where a control needs to be
referenced regardless of its type (for instance in lists of controls).
This class replaces ControlIdentifier.
- ControlValue is kept as-is.
The ControlList class now exposes two template get() and set() methods
that replace the operator[]. They ensure type safety by infering the
value type from the Control reference that they receive.
The main way to refer to a control is now through the Control class, and
optionally through its base ControlId class. The ControlId enumeration
is removed, replaced by a list of global Control instances. Numerical
control IDs are turned into macros, and are still exposed as they are
required to communicate with IPAs (especially to deserialise control
lists). They should however not be used by applications.
Auto-generation of header and source files is removed for now to keep
the change simple. It will be added back in the future in a more
elaborate form.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Make the control API more explicit when dealing with integer controls by
specifying the size. We already do so for 64-bit integers, using int64_t
and ControlTypeInteger64, do the same for 32-bit integers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
