diff options
author | Jacopo Mondi <jacopo@jmondi.org> | 2021-07-28 16:03:54 +0200 |
---|---|---|
committer | Jacopo Mondi <jacopo@jmondi.org> | 2021-08-12 10:08:28 +0200 |
commit | 62c82ab93ff5fb07d581d3a78bc52a621a2a9c8f (patch) | |
tree | 98e211febc0f5608576bf45acb655a14df0eb97b /.reuse/dep5 | |
parent | 0d7db1b5111f2ef0418d4f777549b2b9b8ab1df8 (diff) |
libcamera: controls: Use ControlIdMap in deserialization
Introduce a new field in the controls serialization protocol to
allow discerning which ControlIdMap a ControlInfoMap refers to.
The newly introduced IdMapType enumeration describes the possible
info maps:
- Either the globally available controls::controls and
properties::properties maps, which are valid across IPC boundaries
- A ControlIdMap created locally by the V4L2 device, which is not valid
across the IPC boundaries
At de-serialization time the idMapType field is inspected and
- If the idmap is a globally defined one, there's no need to create
new ControlId instances when populating the de-serialized
ControlInfoMap. Use the globally available map to retrieve the
ControlId reference and use it.
- If the idmap is a map only available locally, create a new ControlId
as it used to happen before this patch.
As a direct consequence, this change allows us to perform lookup by
ControlId reference on de-serialized ControlIdMap that refers to the
libcamera defined controls::controls and properties::properties.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Diffstat (limited to '.reuse/dep5')
0 files changed, 0 insertions, 0 deletions