summaryrefslogtreecommitdiff
path: root/src/qcam/assets/feathericons/play.svg
diff options
context:
space:
mode:
authorLaurent Pinchart <laurent.pinchart@ideasonboard.com>2021-10-19 17:17:59 +0530
committerUmang Jain <umang.jain@ideasonboard.com>2021-10-19 19:15:53 +0530
commite82d7e476759fb76dc280ff4b8a4a4f246deb103 (patch)
tree6ca76cd93973ddcacbad1c5f21a41a59ac49362a /src/qcam/assets/feathericons/play.svg
parentb393edb181a9ec5d0544a453029627fb3e81075c (diff)
android: camera_request: Don't embed full camera3_stream_buffer_t
The camera3_stream_buffer_t structure is meant to communicate between the camera service and the HAL. They are short-live structures that don't outlive the .process_capture_request() operation (when queuing requests) or the .process_capture_result() callback. We currently store copies of the camera3_stream_buffer_t passed to .process_capture_request() in Camera3RequestDescriptor::StreamBuffer to store the structure members that the HAL need, and reuse them when calling the .process_capture_result() callback. This is conceptually not right, as the camera3_stream_buffer_t pass to the callback are not the same objects as the ones received in .process_capture_request(). Store individual fields of the camera3_stream_buffer_t in StreamBuffer instead of copying the whole structure. This gives the HAL full control of how data is stored, and properly decouples request queueing from result reporting. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Diffstat (limited to 'src/qcam/assets/feathericons/play.svg')
0 files changed, 0 insertions, 0 deletions