| Age | Commit message (Collapse) | Author |
|---|
|
The V4L2 compatibility layer uses devnum to match video device nodes to
libcamera Cameras. Some pipeline handlers don't report a devnum for
their camera, which prevents the V4L2 compatibility layer from matching
video device nodes to these cameras. To fix this, we first allow the
camera manager to map multiple devnums to a camera. Next, we walk the
media device and entity list and tell the camera manager to map every
one of these devnums that is a video capture node to the camera.
Since we decided that all video capture nodes that belong to a camera
can be opened via the V4L2 compatibility layer to map to that camera, it
would cause confusion for users if some pipeline handlers decided that
only specific device nodes would map to the camera. To prevent this
confusion, remove the ability for pipeline handlers to declare their own
devnum-to-camera mapping. The only pipeline handler that declares the
devnum mapping is the UVC pipeline handler, so remove the devnum there.
We considered walking the media entity list and taking the devnum from
just the one with the default flag set, but we found that some drivers
(eg. vimc) don't set this flag for any entity. Instead, we take all the
video capture nodes (entities with the sink pad flag set).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As the only usage of IPAManager::instance() is by the pipeline handlers
to call IPAManager::createIPA(), remove the former and make the latter
static. Update the pipeline handlers and tests accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
If any ipa_context instances are destroyed after the IPAManager is
destroyed, then a segfault will occur, since the modules have been
unloaded by the IPAManager and the context function pointers have been
freed.
Fix this by making the lifetime of the IPAManager explicit, and make the
CameraManager construct and deconstruct (automatically, via a unique
pointer) the IPAManager.
Also update the IPA interface test to do the construction and
deconstruction of the IPAManager, as it does not use the CameraManager.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The PixelFormat class is a lightweight wrapper around a 32-bit FourCC
and a 64-bit modifier. Make is usable as a constexpr.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
With the internal headers now in include/libcamera/internal/, we may
have identically named headers in include/libcamera/. Their header
guards would clash. Rename the header guards of internal headers to
prevent any issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The control_ids.h.in and property_ids.h.in headers use C++-style
comments, when the coding style mandates C-style comments. Fix them.
While at it, adjust three minor typos in comments.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The libcamera source files are named after class names, using
snake_case. pixelformats.h and pixelformats.cpp don't comply with that
rule. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Virtual functions overriden in derived classes should be marked with the
override keyword. Do so for the logPrefix() implementations inheriting
from the Loggable class.
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 preferred coding style in libcamera is to declare private functions
before private variables in class definitions. This rule isn't followed
by some of the internal classes. Update them accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
|
|
The default SizeRange constructor initializes the min and max members,
but leaves the hStep and vStep members uninitialized. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The FileDescriptor class, when constructed from a numerical file
descriptor, duplicates the file descriptor and takes ownership of the
copy. The caller has to close the original file descriptor manually if
needed. This is inefficient as the dup() and close() calls could be
avoided, but can also lead to resource leakage, as recently shown by
commit 353fc4c22322 ("libcamera: v4l2_videodevice: Fix dangling file
descriptor").
In an attempt to solve this problem, implement move semantics for the
FileDescriptor constructor. The constructor taking a numerical file
descriptor is split in two variants:
- A "fd copy" constructor that takes a const lvalue reference to a
numerical file descriptor and duplicates it (corresponding to the
current behaviour).
- A "fd move" constructor that takes a rvalue reference to a numerical
file descriptor and takes ownership of it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The list of public, IPA and internal header files are stored in three
meson variables, named libcamera_api, libcamera_ipa_api and
libcamera_headers respectively. The lack of uniformity is a bit
confusing. Fix it by renaming those variables to
libcamera_public_headers, libcamera_ipa_headers and
libcamera_internal_headers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The IPA headers are installed into $prefix/include/libcamera/ipa/, but
are located in the source tree in include/ipa/. This requires files
within libcamera to include them with
#include <ipa/foo.h>
while a third party IPA would need to use
#include <libcamera/ipa/foo.h>
Not only is this inconsistent, it can create issues later if IPA headers
need to include each other, as the first form of include directive
wouldn't be valid once the headers are installed.
Fix the problem by moving the IPA headers to include/libcamera/ipa/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
In an attempt to clarify the license terms of all files in the libcamera
project, the build system files deserve particular attention. While they
describe how the binaries are created, they are not themselves
transformed into any part of binary distributions of the software, and
thus don't influence the copyright on the binary packages. They are
however subject to copyright, and thus influence the distribution terms
of the source packages.
Most of the meson.build files would not meet the threshold of
originality criteria required for copyright protection. Some of the more
complex meson.build files may be eligible for copyright protection. To
avoid any ambiguity and uncertainty, state our intent to not assert
copyrights on the build system files by putting them in the public
domain with the CC0-1.0 license.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Acked-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Show Liu <show.liu@linaro.org>
|
|
Expose the image stride which may be retrieved after a video device
has been configured. It may only be retrieved at that point as the
assignment of video devices takes place at this point.
In the future video devices should be assigned at configuration
validation time and the stride value retrieved at that point.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add two control types to store rectangles and sizes. These will be
useful for the properties related to the pixel array.
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 Rectangle class members that represents the rectangle horizontal and
vertical sizes are named 'w' and 'h', in contrast with the Size and
SizeRange classes which use 'width' and 'height', resulting in having to
look at class definition every time to know which names to use.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
DRM fourccs look like they have a per-plane modifier, but in fact each
of them should be same. Hence instead of passing a set of modifiers for
each fourcc in PixelFormat class, we can pass just a single modifier.
So, replace the set with a single value.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[Fix compilation error in src/libcamera/pipeline/ipu3/ipu3.cpp]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add the ability to set the Request a buffer is associated with. This is
needed for buffers that live inside a pipeline handler and is
temporarily associated with a request as it's being processed inside the
pipeline.
While we are at it delete a stray semicolon.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This method may be used to memory copy a whole FrameBuffer content
from another buffer. The operation is not fast and should not be used
without great care by pipelines.
The intended use-case is to have an option to copy out RAW buffers from
the middle of a pipeline.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a role for capturing high resolution, low frame rate, still images
in RAW format.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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: 1fa4b43402a0 ("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>
|
|
The SizeRange constructors take minimum and maximum width and height
values as separate arguments. We have a Size class to convey size
information, use it in the constructors, and update the callers.
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 Camera class currently requires the allocator to have no allocated
buffer before the camera is reconfigured, and the allocator to be
destroyed before the camera is released. There's no basis for these
restrictions anymore, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the V4L2 buffer orphaning feature, exposed through
V4L2VideoDevice::exportBuffers(), to decouple buffer import and export.
The PipelineHandler::importFrameBuffers() function is now called for all
streams regardless of whether exportFrameBuffers() has been called or
not. This simplifies the Camera implementation slightly, and opens the
door to additional simplifications.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
const reference
PixelFormat was previously an alias for unsigned int but is now a
class. Make all functions taking PixelFormat do so as a const reference.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
To achieve the goal of preventing unwanted conversion between a DRM and
a V4L2 FourCC, make the PixelFormat constructor that takes an integer
value explicit. All users of pixel formats flagged by the compiler
are fixed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Create a class to represent a pixel format. This is done to add support
for modifiers for the formats. So far no modifiers are added by any
pipeline handler, all plumbing to deal with them is however in place.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Instead of having to include linux/drm_fourcc.h everywhere a DRM FourCC
is used in conjunction with PixelFormat include the header directly in
pixelformats.h.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
The libcamera_api array is meant to contain all the headers from the
libcamera public API, for the purpose of generating documentation and
creating the libcamera_dep dependency. libcamera.h is part of the
libcamera public API, add it to the array.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The libcamera_api array is meant to contain all the headers from the
libcamera public API, for the purpose of generating documentation and
creating the libcamera_dep dependency. The generated control headers are
part of the libcamera public API, and used to be included in the
libcamera_api array until commit f870591a9bf5 ("libcamera: properties:
Add location property") inadvertently removed them. Add them back.
Fixes: f870591a9bf5 ("libcamera: properties: Add location property")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Split the change out and reworded the commit message]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The gen-header.sh script that generates libcamera.h takes all .h files
in the include/libcamera/ directory, and manually adds the generated
control_ids.h and version.h. This is fragile, as shown by the failure to
add property_ids.h to the list in commit f870591a9bf5 ("libcamera:
properties: Add location property").
To avoid future omissions, take all the .h.in files into account to
generate libcamera.h. This also fixes the missing property_ids.h.
Fixes: f870591a9bf5 ("libcamera: properties: Add location property")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add support for byte values to the control framework and to the control
serializer.
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 support for float values in Control<> and ControlValue classes.
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>
|
|
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>
|
|
These will be used to implement ControlValue::get() and set() as
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>
|
