summaryrefslogtreecommitdiff
path: root/src/qcam/assets/feathericons/alert-circle.svg
diff options
context:
space:
mode:
authorJacopo Mondi <jacopo@jmondi.org>2021-09-01 12:11:08 +0200
committerJacopo Mondi <jacopo@jmondi.org>2021-09-27 14:37:39 +0200
commitb516ffb3bd9be3ae40b4d979ae4cdff01e816db7 (patch)
tree10adb35413a0433b1280c611f3a90d8a7607e751 /src/qcam/assets/feathericons/alert-circle.svg
parent7fde7c7aeb1e0a993cca479009feb7f487a998c7 (diff)
libcamera: control_serializer: Use the right idmap
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>
Diffstat (limited to 'src/qcam/assets/feathericons/alert-circle.svg')
0 files changed, 0 insertions, 0 deletions