Pipeline handlers might need to perform allocation of internal buffers,
setup operations, or simple sanity check before going into the
per-stream buffer allocation.
As of now, PipelineHandler::allocateBuffers() is called once for each
active stream, leaving no space for stream-independent configuration.
Change this by providing to the pipeline handlers the full set of active
streams, and ask them to loop over them to perform per-streams
memory allocations and freeing.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
To properly support both multiple streams and stream usages the library
must provide a method to map the stream usages to the returned streams
configurations. Add a camera configuration object to handle this
mapping.
Applications can iterate over the returned camera configuration to
retrieve the streams selected by the library in the same order as the
usages it provided to the library.
Applications can use the operator[] to retrieve the stream pointer and
the stream configuration. Using a numerical index retrieves the stream
pointer, the numerical indexes corresponds to the insertion order of
usages in the CameraConfiguration, using the stream pointer retrieves
the stream's configuration.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of requesting the default configuration for a set of streams
where the application has to figure out which streams provided by the
camera is best suited for its intended usage, have the library figure
this out by using stream usages.
The application asks the library for a list of streams and a suggested
default configuration for them by supplying a list of stream usages.
Once the list is retrieved the application can fine-tune the returned
configuration and then try to apply it to the camera.
Currently no pipeline handler is prepared to handle stream usages but
nor did it make use of the list of Stream IDs which was the previous
interface. The main reason for this is that all cameras currently only
provide one stream each. This will still be the case but the API will be
prepared to expand both pipeline handlers and applications to support
streams usages.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
It is not permitted to configure streams before a camera is acquired.
Fixes: 77100a7578 ("libcamera: camera: add state machine to control access from applications")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Buffers must have all mappings destroyed before buffers can be freed by the
V4L2 device that has allocated them.
Swap the ordering of freeBuffers() and destroyBuffers() to correct this.
Fixes: bd38112b77 ("libcamera: camera: Extend the interface to support capture")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Request complete by themselves when all the buffers they contain have
completed, connecting the buffer's completed signal to be notified of
buffer completion. While this works for now, it prevents pipelines from
delaying request completion until all metadata is available, and makes
it impossible to ensure that requests complete in the order they are
queued.
To fix this, make request completion handling explicit in pipeline
handlers. The base PipelineHandler class is extended with
implementations of the queueRequest() and stop() methods and gets new
completeBuffer() and completeRequest() methods to help pipeline handlers
tracking requests and buffers.
The three existing pipeline handlers connect the bufferReady signal of
their capture video node to a slot of their respective camera data
instance, where they use the PipelineHandler helpers to notify buffer
and request completion. Request completion is handled synchronously with
buffer completion as the pipeline handlers don't need to support more
advanced use cases, but this paves the road for future work.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
There is a need to better control the order of operations an application
performs on a camera for it to function correctly. Add a basic state
machine to ensure applications perform operations on the camera in good
order.
Internal to the Camera states are added; Available, Acquired,
Configured, Prepared and Running. Each state represents a higher state
of configuration of the camera ultimately leading to the highest state
where the camera is capturing frames. Each state supports a subset of
operations the application may perform.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The arrays that store Stream pointers shall always contain unique
values. Storing them in vectors opens up for the same stream pointer
appearing twice. Remove this possibility by storing them in a set which
guarantees each element is unique.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Rapid growth of the library have resulted in slightly different wording
to document that a function returns 0 on success or a negative error
code otherwise. Align all different variations.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The return statement is missing altogether and an error is silently
ignored. Fix this and also update the empty map to use the correct type
for the map key.
Fixes: 65ea2422d2 ("libcamera: camera: extend camera object to support configuration of streams")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In order to support capture, the camera needs methods to allocate and
free buffers, to start and stop the capture and to queue requests.
Define those interfaces in the Camera class and implement them to call
the corresponding pipeline handler methods.
Once a camera is started the pipeline handler of the camera will begin
processing requests queued to the camera by the application until it
gets stopped.
Once a request is created it can be queued to the camera and the
application will be notified asynchronously once the request is
completed and be able to process all the buffers involved in the
request.
At this point the request objects don't support controls. This will be
extended in the future.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Extend the camera to support reading and configuring formats for
groups of streams. The implementation in the Camera are minimalistic as
the heavy lifting are done by the pipeline handler implementations.
The most important functionality the camera provides in this context is
validation of data structures passed to it from the application and
access control to the pipeline handler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
A camera consists of one or more video streams originating from the same
video source. The different streams could for example have access to
different hardware blocks in the video pipeline and therefore be able to
process the video source in different ways.
All static information describing each stream need to be recorded at
camera creation. After a camera is created an application can retrieve
the static information about its streams at any time.
Update all pipeline handlers to register one stream per camera, this
will be extended in the future for some of the pipelines.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
As camera object have the potential to outlive the hardware they
represent, there is a need to inform the camera that the underlying
device has been disconnected, and in turn to notify applications.
Implement a disconnection notification mechanism that can be used by
pipeline handlers to notify the camera of disconnection. The camera then
block all new API calls and emit the disconnected signal.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The PipelineHandler which creates a Camera is responsible for serving
any operation requested by the user. In order forward the public API
calls, the camera needs to store a reference to its pipeline handler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v1:
- Create pipeline handlers is shared pointers, make them inherit from
std::enable_shared_from_this<> and stored them in shared pointers.
The Camera class is explicitly reference-counted to manage the lifetime
of camera objects. Replace this open-coded implementation with usage of
the std::shared_ptr<> class.
This API change prevents pipeline handlers from subclassing the Camera
class. This isn't deemed to be an issue. Mark the class final to make
this explicit.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Provide a Camera class which represents our main interface to handling
camera devices. This is a rework of Kieran's initial proposal and
Laurent's documentation of the file changed to fit the device
enumerators needs.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
