| Age | Commit message (Collapse) | Author |
|---|
|
When a ControlList is deserialized, the code searches for a valid
ControlInfoMap in the local cache and use its id map to initialize the
list. If no valid ControlInfoMap is found, as it's usually the case
for lists transporting libcamera controls and properties, the globally
defined controls::controls id map is used unconditionally.
This breaks the deserialization of libcamera properties, for which a
wrong idmap is used at construction time.
As the serialization header now transports an id_map_type field, store
the idmap type at serialization time, and re-use it at
deserialization time to identify the correct id map.
Also make the validation stricter by imposing to list of V4L2 controls to
have an associated ControlInfoMap available, as there is no globally
defined idmap for such controls.
To be able to retrieve the idmap associated with a ControlList, add an
accessor function to the ControlList class.
It might be worth in future using a ControlInfoMap to initialize the
deserialized ControlList to implement controls validation against their
limit. As such validation is not implemented at the moment, maintain the
current behaviour and initialize the control list with an idmap.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ControlValidator passed to a ControlList constructor
is used, but not modified.
Make it const.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
ControlInfoMap does not have a ControlId map associated, but rather
creates one with the generateIdMap() function at creation time.
As a consequence, when in the need to de-serialize a ControlInfoMap all
the ControlId it contains are created by the deserializer instance, not
being able to discern if the controls the ControlIdMap refers to are the
global libcamera controls (and properties) or instances local to the
V4L2 device that has first initialized the controls.
As a consequence the ControlId stored in a de-serialized map will always
be newly created entities, preventing lookup by ControlId reference on a
de-serialized ControlInfoMap.
In order to make it possible to use globally available ControlId
instances whenever possible, create ControlInfoMap with a reference to
an externally allocated ControlIdMap instead of generating one
internally.
As a consequence the class constructors take and additional argument,
which might be not pleasant to type in, but enforces the concepts that
ControlInfoMap should be created with controls part of the same id map.
As the ControlIdMap the ControlInfoMap refers to needs to be allocated
externally:
- Use the globally available controls::controls (or
properties::properties) id map when referring to libcamera controls
- The V4L2 device that creates ControlInfoMap by parsing the device's
controls has to allocate a ControlIdMap
- The ControlSerializer that de-serializes a ControlInfoMap has to
create and store the ControlIdMap the de-serialized info map refers to
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
It would be convenient to be able to iterate over available boolean
values, for example for controls that designate if some function can be
enabled/disabled. The current min/max/def constructor is insufficient,
as .values() is empty, so the values cannot be easily iterated over, and
creating a Span of booleans does not work for the values constructor.
Add new constructors to ControlInfo that takes a set of booleans (if
both booleans are valid values) plus a default, and another that takes
only one boolean (if only one boolean is a valid value).
Update the ControlInfo test accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Fix a small spelling mistake in the ControlInfoMap documentation.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Move the utils functionality to the libcamera/base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ControlList merge operation is protected with an ASSERT to guarantee
that the two lists are compatible.
Unfortunately this assertion fails when we run IPAs in an isolated case
as while the lists are compatible, the isolated IPA has a unique
instance of the id map. This breaks the pointer comparison, and the
assertion fails with a false positive.
Remove the assertion, leaving only a todo in it's place as this breaks
active users of the library.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=31
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a new ControlList::merge() function to merge two control lists by
copying in the values in the list passed as parameters.
This can be used by pipeline handlers to merge metadata they populate
with metadata received from an IPA.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[reimplement the function by not using std::unordered_map::merge()]
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
A few grammatical errors remain in the Control class documentation.
Fix them.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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 C++ boolean types are lower case, and std::ostream::operator<<(bool)
produces a lowercase string (when std::boolalpha is in effect, otherwise
it produces 0 or 1). Switch ControlValue::toString() to produce
lowercase "true" and "false" strings too for consistency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
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>
|
|
The ControlValue::get<T>() method verifies that the T type corresponds
to the ControlValue type. It however accepts int32_t as a return type
for 64-bit integer controls, and int64_t as a return type for 32-bit
integer controls. There's no reason to do so anymore, make the type
check stricter.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Reorder functions in ControlValue class to group const methods together.
Cosmetic change only.
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>
|
|
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>
|
|
We use static local variables to indicate errors in methods that return
a const reference. The local variables can thus be const, make them so.
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>
|
|
ControlInfoMap requires the ControlId and ControlRange of each entry to
have identical types. Check for this and log an error if a mismatch is
detected.
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>
|
|
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>
|
|
We need to construct empty ControlList objects to serialization. Make
the constructor public.
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 class has a move assignment operator from a plain
map, but no corresponding move constructor. Add one.
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>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
Allow comparision of control ranges by adding the required operators.
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 count() and find() methods use at() to lookup the
control numerical ID in the idmap_. This causes an exception to be
thrown if the ID doesn't exist in the map. Fix it by using the find()
method instead in find(), and rely on idmap_.count() in count().
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>
|
|
Add a utils::hex() function that simplifies writing hexadecimal values
to an ostream. The function handles the '0x' prefix, the field width and
the fill character automatically. Use it through the libcamera code
base, and add a test.
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 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>
|
|
Add equality and non equality comparison operators for the ControlValue
class. This simplifies code that deals with control values.
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>
|
|
In order to deserialise a ControlList, we will need to lookup ControlId
instances based on their numerical ID. Generate a global map from the
controls definitions to support such a lookup.
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>
|
