When a video device is stopped all the buffers there queued are released
and their state is set to BufferCancelled.
Currently, on buffer completion, cancelled buffers are blindly re-queued
to the ImgU input or CIO2 output devices, preventing them to be
re-started succesfully in future capture sessions.
Fix that by inspecting the buffers status and skip re-queueing if
they're reported as cancelled. For the ImgU output buffer this is not
required, as cancelled request should be reported to applications in
order to report them failure of the capture operations.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
With the current IPU3 kernel driver implementation, a linked pipe shall be
used (buffers should be queued on it) in order not to block all other pipes.
Currently all links on the ImgU device are only disabled at match() time,
implying that once an ImgU pipe gets linked, it should be used until the
whole pipeline is not re-matched and links disabled again. This is a severe
limitation for applications that wants to switch between cameras using
different pipes going through a full library tear-down and reload.
Perform link disabling at configure() time as well, so that a camera
configuration operation always unlock the usage of the assigned pipe,
regardless of the previously linked ones.
Unfortunately this requires a camera start/stop sequence to always go
through a configure step, a requirement that is not enforced by the
Camera state machine.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The internal buffers between the CIO2 and ImgU are freed by the
CIO2Device::stop() method, which is called first when stopping
streaming. The ImgUDevice::stop() method is then called, and attempts to
report completion for all queued buffers, which we have just freed. The
use-after-free corrupts memory, leading to crashes.
Fix this by moving the vector of internal buffers to the IPU3CameraData
where it belongs, and free the buffers after stopping both devices.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
To avoid printing debugging messages related to stream configuration
adjustement when generating a new configuration, set the pixel format
explicitly instead of relying on the internal validate() call to do so.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add support for importing external buffers in all pipeline handlers.
Use the stream memory type in the pipeline handlers during buffer
allocation to import buffers to or export buffers from the video device.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Access the number of allocated buffer for the streams through the stream
configuration instead of the stream's buffers pool.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When stopping the stream buffers have been queued, in which case their
completion is never be notified to the user. This can lead to memory
leaks. Fix it by notifying completion of all queued buffers with the
status set to error.
As a result the base PipelineHandler implementation can be simplified,
as all requests complete as the result of stopping the stream. The
stop() method that manually completes all queued requests isn't needed
anymore.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When starting the stream on a capture video device it is often needed to
queue all the allocated buffers. Add a helper method to do so, and
refactor the existing queueBuffer() method to make it clearer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
libcamera guarantees that requests complete in sequence. This
requirement is currently pushed down to pipeline handlers. Three out of
four of our pipeline handlers implement that requirement based on the
sole assumption that buffers will always complete in sequeuence, while
the IPU3 pipeline handler implements a more complex logic.
It turns out that the logic can be moved to the base PipelineHandler
class with support from the Request class. Do so to simplify the
pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Extend the uvcvideo pipeline with format information and validation. The
format information is gathered by enumerating the v4l2 device. This
enumeration approach is valid for UVC as it has a static and simple
media graph.
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>
The CameraConfiguration class implements a simple storage of
StreamConfiguration with internal validation limited to verifying that
the stream configurations are not empty. Extend this mechanism by
implementing a smart validate() method backed by pipeline handlers.
This new mechanism changes the semantic of the camera configuration. The
Camera::generateConfiguration() operation still generates a default
configuration based on roles, but now also supports generating empty
configurations to be filled by applications. Applications can inspect
the configuration, optionally modify it, and validate it. The validation
implements "try" semantics and adjusts invalid configurations instead of
rejecting them completely. Applications then decide whether to accept
the modified configuration, or try again with a different set of
parameters. Once the configuration is valid, it is passed to
Camera::configure(), and pipeline handlers are guaranteed that the
configuration they receive is valid.
A reference to the Camera may need to be stored in the
CameraConfiguration derived classes in order to access it from their
validate() implementation. This must be stored as a std::shared_ptr<> as
the CameraConfiguration instances belong to applications. In order to
make this possible, make the Camera class inherit from
std::shared_from_this<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Move the pipeline handler camera data classes, defined in the scope of
the respective pipeline handler class, to the top level of the libcamera
namespace. This prepares for the introduction of other classes that will
make use of them in the IPU3 and RkISP1 pipeline handlers. The UVC and
VIMC pipeline handlers are updated as well for consistency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
To prepare for specialising the CameraConfiguration class in pipeline
handlers, return a pointer to a camera configuration instead of a
reference from Camera::generateConfiguration(). The camera configuration
always needs to be allocated from the pipeline handler, and its
ownership is passed to the application.
For symmetry, change Camera::configure() to take a CameraConfiguration
pointer instead of a reference. This aligns with our coding practice of
passing parameters that are modified by the callee by pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Refactor the CameraConfiguration structure to not rely on Stream
instances. This is a step towards making the camera configuration object
more powerful with configuration validation using "try" semantics.
The CameraConfiguration now exposes a simple vector-like API to access
the contained stream configurations. Both operator[]() and at() are
provided to access elements. The isEmpty() method is renamed to empty()
and the methods reordered to match the std::vector class.
As applications need access to the Stream instances associated with the
configuration entries in order to associate buffers with streams when
creating requests, expose the stream selected by the pipeline handler
through a new StreamConfiguration::stream().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
In order to prepare for an API overhall of the camera configuration
generation, remove the StreamUsage class and replace its uses by stream
roles. The size hints can't be specified anymore, and will be replaced
with an API on the StreamConfiguration to negotiate configuration
parameters with cameras.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Rename the configureStreams() and streamConfiguration() methods to
configure() and generateConfiguration() respectively in order to clarify
the API. Both methods deal with CameraConfiguration objects, and are
thus not limited to streams, even if a CameraConfiguration currently
contains streams only.
While at it, remove the qcam MainWindow::configureStreams() method that
is declared but never defined or used.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Instead of requiring each pipeline handle implementation to keep track
of calling release() on its media devices upon deletion, keep track of
them in the base class. Add a helper that pipeline handlers shall use
to acquire a media device instead of directly interacting with the
DeviceEnumerator.
This also means that pipeline handler implementations do no need to keep
a shared_ptr<> reference to the media devices they store locally as the
PipelineHandler base class will keep a shared_ptr<> reference to all
media devices consumed for the entire lifetime of the pipeline handler
implementation.
Centrally keeping track of media devices will also be beneficial
to implement exclusive access to pipelines across processes.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To gain better control of when a file descriptor is open to the media
device and reduce the work needed in pipeline handler implementations,
handle the file descriptor in acquire() and release().
This changes the current behavior where a file descriptor is only open
when requested by the pipeline handler to that one is always open as
long a media device is acquired. This new behavior is desired to allow
implementing exclusive access to a pipeline handler between processes.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In preparation for adding more responsibility to MediaDevice::acquire()
remove unneeded calls to acquire() and release(), and make sure all
needed calls to acquire() are checked and acted on.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Name all instances of CameraConfiguration "config", and all instances of
StreamConfiguration "cfg" accross all pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Several of our structures include width and height fields that model a
size while we have a Size class for that purpose. Use the Size class
through libcamera, and give it a toString() method like other geometry
and format classes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The uvcvideo and vimc pipeline handlers print the requested resolution
in their configureStreams() operation. This duplicates a generic log
statement in the Camera::configureStreams() method, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The IPU3 and RKISP1 pipeline handlers log the camera configuration they
propose in their streamConfiguration() methods. Other pipeline handlers
are expected to log similar information, move it to the Camera class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The viewfinder and main output require identical logic for buffer and
request completion. Connect the viewfinder bufferReady signal to the slot
and handle requests for both main output and viewfinder there.
Update the slot logic to complete the request only when the last buffer
has completed, and make sure to complete requests in the same order they
have been queued to the pipeline handler.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Add support for queueing requests for multiple streams in the IPU3
pipeline handler class.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Perform allocation and setup of memory sharing between the CIO2 output
and the ImgU input and allocate memory for each active stream.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Use and inspect the stream roles provided by the application to
streamConfiguration() to assign streams to their intended roles and
return a default configuration associated with them.
Support a limited number of usages, with the viewfinder stream able to
capture both continuous video streams and still images, and the main
output stream supporting still images only. This is an artificial
limitation until we figure out the exact capabilities of the hardware.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Sub-class the Stream class with an IPU3-specific implementation and
create each IPU3 camera with two streams: 'output' and 'viewfinder'
which represent the video streams from main and secondary ImgU output
respectively.
Rework stream configuration to handle the two video streams 'output'
and 'viewfinder' separately.
As the IPU3 driver requires viewfinder and stat video nodes to be
started not to stall ImgU processing, configure 'output', 'viewfinder'
and 'stat' regardless of the user-requested active streams.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Add a toString() method to the StreamConfiguration class, and replace
all manually coded implementations through the source code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Use the pixel format requested by the application in the
RkISP1PipelineHandler::configureStreams() method instead of hardcoding
NV12. The streamsConfiguration() method still proposes NV12 by default.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The documentation style for the Doxygen comment blocks is inconsistent
in the library. Document the expectations and update all existing
comment blocks to match.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
The pipeline handler for the Rockchip ISP creates one camera instance
per detected raw Bayer CSI-2 sensor. Parallel sensors and YUV sensors
are not supported yet.
As the ISP has a single CSI-2 receiver, only one camera can be used at a
time. Mutual exclusion isn't implemented yet.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a method to retrieve the media entity associated with a subdevice.
The entityName() and deviceNode() methods are not needed anymore as they
can be accessed through the media entity, remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Instead of storing four integers for the minimum and maximum width and
height in the SizeRange class, use two instance of the Size class for
the minimum and maximum sizes.
While it at replace the mention of image size with size in the SizeRange
documentation, as the Size class isn't limited to image sizes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The IPU3 pipeline handler logs the requested configuration in its
configureStreams() handler. This is useful for other pipeline handlers
as well, move it to the Camera class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Do not assume the freeBuffer() function can handle allocateBuffer()
method failures, as error handling and clean up should be performed
by allocateBuffer() method itself.
Perform clean-up on allocations failures in the IPU3 pipeline handler,
now that freeBuffers() is not called anymore.
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>
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>
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>
As the lengthy comment reports, link enable/disable is not trivial, as
links in one ImgU instance interfere with capture operations in the
other one. As it is not yet clear if this behaviour is intended, as of
now reset the media graph during pipeline's match() and enable the
required links at streamConfiguration time.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Jacopo Mondi
Laurent Pinchart
Kieran Bingham
Niklas Söderlund
Paul Elder