summaryrefslogtreecommitdiff
path: root/test/controls
diff options
context:
space:
mode:
authorJacopo Mondi <jacopo@jmondi.org>2021-07-28 16:03:54 +0200
committerJacopo Mondi <jacopo@jmondi.org>2021-08-12 10:08:28 +0200
commit62c82ab93ff5fb07d581d3a78bc52a621a2a9c8f (patch)
tree98e211febc0f5608576bf45acb655a14df0eb97b /test/controls
parent0d7db1b5111f2ef0418d4f777549b2b9b8ab1df8 (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 'test/controls')
0 files changed, 0 insertions, 0 deletions