[libcamera-devel] Request and Pipeline::Stop() behavior

Naushir Patuck naush at raspberrypi.com
Wed Feb 26 10:03:40 CET 2020


Hi,

Could you help with my understanding on how Requests are handled in
vendor pipeline handlers please?

Given that multiple requests can be queued, I assume the pipeline
handlers must maintain a queue of Request types.  Can we use
CameraData::queuedRequests_ for this, or is that a libcamera internal
queue and we must duplicate?

On a PipelineHandler::stop(), I assume we must go through the Request
queue and call PipelineHandler::completeRequest() on each Request.
However, this will fail if the Request has any outstanding buffers
pending for which we need to call PipelineHandler::completeBuffer().
This in-turn means that each pipeline handler must have a mechanism to
go through all Requests and call PipelineHandler::completeBuffer() on
all streams.  If we call PipelineHandler::completeBuffer() on a stream
that has already previously called PipelineHandler::completeBuffer()
for an in-flight Request, we hit an assert.  So the pipeline handlers
must maintain state of what streams/buffers in the Request is
completed to clean up correctly in these situations.

Now this is not difficult to maintain state in the pipeline handers,
but seems like it would be duplicated code for all vendors.  Given
that there is already a notion of RequestCancelled (in
Request::status_), would it make state to have a
PipelineHandler::cancelRequest() method that explicitly does a
completeBuffer() on all outstanding streams in the Request and markes
status_ as RequestCancelled.  This would avoid any code duplication in
the various vendor pipeline handlers.

Apologies if I have misunderstood and this is not how any of this is
meant to work, please do let me know :)

Regards,
Naush


More information about the libcamera-devel mailing list