summaryrefslogtreecommitdiff
path: root/src/android/camera_ops.h
diff options
context:
space:
mode:
authorDavid Plowman <david.plowman@raspberrypi.com>2022-11-09 10:49:40 +0000
committerKieran Bingham <kieran.bingham@ideasonboard.com>2022-11-14 11:03:32 +0000
commit75e7befb1667f620410f0f15a10eccb32d7df66d (patch)
tree9831a812562421e5f882fd2bf3852f00ed7ab760 /src/android/camera_ops.h
parentbf7226f4c46de0bbadff63eb531dbd3dd4c900a0 (diff)
Revert "pipeline: raspberrypi: Do not unconditionally free buffers on close"
This reverts commit 30d704732badc675f72fe73d14749669cb645c23. It turns out that this commit causes some regressions and is in fact unnecessary because the related commit "libcamera: v4l2_videodevice: Guard against releasing unallocated buffers" (a2bdff6d0b67475492ac7cf9318866b6d89a28fd) fixes the problem completely (if the buffers were never allocated, the video device avoids trying to free them even if the pipeline handler asks). The reason for the regressions is that in this new (broken) scheme we would never call clearBuffers() on all the streams if the internal buffers were never allocated (i.e. buffersAllocated_ is never set). This causes the stream's bufferMap_ list to get longer and longer if there are multiple back-to-back calls to configure, and dev_->importBuffers() will ultimately to fail. So either we need to think more carefully about how to stop the pipeline handler from freeing buffers that it doesn't own, or we just leave it as the other commit resolves the problem on its own. In the interim, simply reverting this commit certainly seems like the best solution. Fixes: 30d704732bad ("pipeline: raspberrypi: Do not unconditionally free buffers on close") Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Diffstat (limited to 'src/android/camera_ops.h')
0 files changed, 0 insertions, 0 deletions