@@ -734,6 +734,7 @@ void PipelineHandlerBase::stopDevice(Camera *camera)
data->frontendDevice()->setFrameStartEnabled(false);
data->clearIncompleteRequests();
+ data->clearImmediateControls();
/* Stop the IPA. */
data->ipa_->stop();
@@ -1426,6 +1427,11 @@ void CameraData::clearIncompleteRequests()
}
}
+void CameraData::clearImmediateControls()
+{
+ immediateControls_ = {};
+}
+
void CameraData::handleStreamBuffer(FrameBuffer *buffer, RPi::Stream *stream)
{
/*
@@ -89,6 +89,7 @@ public:
void frameStarted(uint32_t sequence);
void clearIncompleteRequests();
+ void clearImmediateControls();
void handleStreamBuffer(FrameBuffer *buffer, Stream *stream);
void handleState();
Immediate controls wait in a queue keyed by request sequence until delayContext catches up. The queue was not cleared on stop while request sequence numbers restart from zero, so stale entries blocked every immediate control of the next session until it outlasted the old one. Fixes: b0dbd5100b1b ("pipeline: rpi: Make control lists in requests properly atomic") Signed-off-by: Danius Kalvaitis <danius@kurokesu.com> --- Reproduced on a Pi 5 with an IMX477, where ColourGains sent through a request after a restart took as many frames to apply as the previous session had run. David, this overlaps with your ControlList queues in https://github.com/raspberrypi/libcamera/pull/351, which probably need clearing on stop too. src/libcamera/pipeline/rpi/common/pipeline_base.cpp | 6 ++++++ src/libcamera/pipeline/rpi/common/pipeline_base.h | 1 + 2 files changed, 7 insertions(+) base-commit: aebe4861c087ce9a0cb417151d5316a1fdb2e792