The intention is that the "main" colour space is the colour space of
the largest non-raw stream. Unfortunately the use of "config_[i].size"
is clearly incorrect, and has been copied from prior versions of the
code. This patch corrects the error.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
The PipelineHandler::generateConfiguration() function allocates a
CameraConfiguration instance and returns it. The ownership of the
instance is transferred to the caller. This is a perfect match for a
std::unique_ptr<>, which the Camera::generateConfiguration() function
already returns. Update PipelineHandler::generateConfiguration() to
match it. This fixes a memory leak in one of the error return paths in
the IPU3 pipeline handler.
While at it, update the Camera::generateConfiguration() function
documentation to drop the sentence that describes the ownership
transfer, as that is implied by usage of std::unique_ptr<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CameraConfiguration::validateColorSpaces() function performs color
space validation on a camera configuration, by validating the color
space of each stream individually, and optionally ensuring that all
streams share the same color space. The individual validation is very
basic, limited to ensuring that raw formats use a raw color space.
Color spaces are more constrained than that:
- The Y'CbCr encoding and quantization range for RGB formats must be
YcbcrEncoding::None and Range::Full respectively.
- The Y'CbCr encoding for YUV formats must not be YcbcrEncoding::None.
Instead of open-coding these constraints in the validateColorSpaces()
function, create a new ColorSpace::adjust() function to centralize color
space validation and adjustment, and use it in validateColorSpaces().
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
libcamera implements a pipeline handler locking mechanism based on
advisory locks on media devices, to prevent concurrent access to cameras
from the same pipeline handler from different processes (this only works
between multiple libcamera instances, as other processes won't use
advisory locks on media devices).
A side effect of the implementation prevents multiple cameras created by
the same pipeline handler from being used concurrently. Fix this by
turning the PipelineHandler lock() and unlock() functions into acquire()
and release(), with a use count to replace the boolean lock flag. The
Camera class is updated accordingly.
As a consequence of this change, the IPU3 pipeline handler will fail to
operate properly when the cameras it exposes are operated concurrently.
The android.hardware.camera2.cts.MultiViewTest#testDualCameraPreview
test fails as a result. This should be fixed in the IPU3 pipeline
handler to implement mutual exclusion between cameras.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
We now have V4L2VideoDevice ensuring that sensor sequence numbers
start from zero [1], and we desire that these should match the Request
sequence number as well.
[1] 1c9dc0fd89 ("libcamera: v4l2_videodevice: Identify non-zero stream starts")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Provide a call allowing requests to be registered and associated with
the pipeline handler after being constructed by the camera.
This provides an opportunity for the PipelineHandler to connect any
signals it may be interested in receiving for the request such as
getting notifications when the request is ready for processing when
using a fence.
While here, update the existing usage of the d pointer in
Camera::createRequest() to match the style of other functions.
Bug: https://github.com/raspberrypi/libcamera-apps/issues/217
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This function forces raw streams to have the "raw" color space, and
also optionally makes all non-raw output streams to share the same
color space as some platforms may require this.
When sharing color spaces we take the shared value to be the one from
the largest of these streams. This choice is ultimately arbitrary, but
can be appropriate if smaller output streams are used for image
analysis rather than human consumption, when the precise colours may
be less important.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Many signals used in internal and public APIs carry the emitter pointer
as a signal argument. This was done to allow slots connected to multiple
signal instances to differentiate between emitters. While starting from
a good intention of facilitating the implementation of slots, it turned
out to be a bad API design as the signal isn't meant to know what it
will be connected to, and thus shouldn't carry parameters that are
solely meant to support a use case specific to the connected slot.
These pointers turn out to be unused in all slots but one. In the only
case where it is needed, it can be obtained by wrapping the slot in a
lambda function when connecting the signal. Do so, and drop the emitter
pointer from all signals.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The documentation suggests to use CameraConfiguration::operator[] to
access the StreamConfiguration it contains, but as CameraConfiguration
instances are generated by the Camera class and are returned wrapped in
a unique_ptr<>, the usage of operator[] would require an awkward syntax such
as (*config)[i].
Better to suggest the usage of the CameraConfiguration::at() function
instead to access the StreamConfigurations.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The PipelineHandler controls() and properties() functions are only used
by the Camera class. Now that the controls and properties are stored in
the Camera::Private class, we can drop those functions and access the
private data directly in Camera::controls() and Camera::properties().
Suggested-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
With pipeline handlers now being able to subclass Camera::Private, start
the migration from CameraData to Camera::Private by moving the members
of the base CameraData class. The controlInfo_, properties_ and pipe_
members are duplicated for now, to allow migrating pipeline handlers one
by one.
The Camera::Private class is now properly documented, don't exclude it
from documentation generation.
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 allow subclassing Camera::Private in pipeline handlers, pass
the pointer to the private data to the Camera constructor, and to the
Camera::createCamera() function.
The Camera::Private id_ and streams_ members now need to be initialized
by the Camera constructor instead of the Camera::Private constructor, to
allow storage of the streams in a pipeline handler-specific subclass of
Camera::Private.
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 Extensible constructor takes a pointer to a Private instance, whose
lifetime it then manages. Make this explicit in the API by passing the
pointer as a std::unique_ptr<Private>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Camera::Private class is defined in camera.cpp. To prepare for
allowing it to be subclassed by pipeline handlers, move it to a new
internal/camera.h header.
The \file comment block in camera.cpp now needs to explicitly tell which
camera.h file it refers to.
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 Extensible and Extensible::Private classes contain pointers to each
other. These pointers are initialized in the respective class's
constructor, by passing a pointer to the other class to each
constructor. This particular construct reduces the flexibility of the
Extensible pattern, as the Private class instance has to be allocated
and constructed in the members initializer list of the Extensible
class's constructor. It is thus impossible to perform any operation on
the Private class between its construction and the construction of the
Extensible class, or to subclass the Private class without subclassing
the Extensible class.
To make the design pattern more flexible, don't pass the pointer to the
Extensible class to the Private class's constructor, but initialize the
pointer manually in the Extensible class's constructor. This requires a
const_cast as the o_ member of the Private class is const.
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>
Now that all Extensible classes expose a _d() function that performs
appropriate casts, the LIBCAMERA_D_PTR brings no real additional value.
Replace it with direct calls to the _d() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Make Camera::stop() idempotent so that it can be called in any state and
consecutive times. When called in any state other than CameraRunning, it
is a no-op. This simplifies the cleanup path for applications.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When the camera manager calls stop on a pipeline, it is expected that
the pipeline handler guarantees all requests are returned back to the
application before the camera has stopped.
Ensure that this guarantee is met by providing an accessor on the
pipeline handler to validate that all pending requests are removed.
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
PipelineHandler::queueRequest() is asynchronously invoked in
Camera::queueRequest(). Therefore the return value of
PipelineHandler::queueRequest() is useless. This changes the
function to a void function.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
When the camera is being stop()ped, active requests will complete. These
may trigger an application to re-queue those requests to the camera but
that is not permitted, and is an error in the application.
Extend the camera state to include a stopping state which is entered as
soon as a call to stop() is made. At this point, any request queued will
be rejected with a warning, while any pending requests are either
successfully completed or cancelled.
When the pipeline handler has finished stopping, the camera state will
transition to the CameraConfigured state where it can begin to accept
requests again, and be restarted.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The camera object has a state machine to ensure calls are only made
when in the correct state. It isn't easy to identify where things happen
when assertions fail so add extra information to make this clearer.
The error level of the isAccessAllowed is raised from Debug to Error as
this is important information for applications to know if they have made
a request in an invalid state.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
All requests must have completed before the Camera has fully stopped.
Requests completing when the camera is not running represent an internal
pipeline handler bug.
Trap this event with a fatal error.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
There is no need to pass the Camera pointer to queueRequest(),
completeBuffer() and completeRequest() as the Request also passed
contains the same information. Remove the Camera argument to avoid
situations where the information in the Request and the argument differ.
There is no functional change and no public API change as the interface
is only used between the Camera and PipelineHandler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Applications now have the ability to pass in controls that need to be
applied on startup, rather than doing it through Request where there might
be some frames of delay in getting the controls applied.
This commit adds the ability to pass in a set of libcamera controls into
the pipeline handlers through the pipeline_handler::start() method. These
controls are provided by the application through the camera::start()
public API.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Introduce a pipeline model that lists the operations applied by the
camera pipeline. This is a first step towards defining explicitly how
the camera processes images, and how the libcamera controls affect the
processing.
The initial list of operations is meant to be expanded, and possibly
refactored (a block diagram should also be considered to make this
easier to read). How the controls affect the pipeline is largely missing
at this stage, with only a short explanation of the digital zoom to show
how this is meant to be documented. More documentation will be added
over time.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke.linux@gmail.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Allow reuse of the Request object by implementing reuse(). This means
the applications now have the responsibility of freeing the Request
objects, so make all libcamera users (cam, qcam, v4l2-compat, gstreamer,
android) do so.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a field to the CameraConfiguration (including the necessary
documentation) to represent a 2D transform requested by the
application. All pipeline handlers are amended to coerce this to the
Identity, marking the configuration as "adjusted" if something
different had been requested.
Pipeline handlers that support Transforms can be amended subsequently.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In most cases the last reference to a Camera instance will be the one
held by the CameraManager. That reference gets released when the
CameraManager thread cleans up, just before it stops. There's no need to
delete the camera with deleteLater() in that case.
To optimize this case, use deleteLater() only when the camera gets
deleted from a different thread, and delete is synchronously otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
The Stream pointer just acts as a key in the Request object. There is no
good use-case to modify a stream from a pointer retrieved from the
Request, make it const. This allows pipeline handlers to better express
that the Stream pointer is retrieved in a Request should just be treated
as a key.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Rename Camera::name() to camera::id() to better describe what it
represents, a unique and stable ID for the camera. While at it improve
the documentation for the camera ID to describe it needs to be stable
for a camera between resets of the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The current implementation of the Camera::configure() method zeroes the
stream pointers assigned to the StreamConfiguration items before calling
the pipeline handler configure() operation, just after the
CameraConfiguration has been validated.
This discards the stream assignment performed at pipeline hander
validation time, requiring platforms that need to perform that early
assignment to maintain the association in place with custom data
structures.
To allow pipeline handlers to use StreamConfiguration::setStream() at
validate() time, zero the stream assignment before calling validate().
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>
Object::deleteLater() ensures that the deletion of the Object
takes place in a thread it is bound to. Deleting the Object
in a different thread is a violation according to the libcamera
threading model.
On hot-unplug of a currently streaming camera, the last reference
of Camera when dropped from the application thread (for e.g. QCam's
thread), the destructor is then called from this thread. This is not
allowed by the libcamera threading model. Camera is meant to be deleted
in the thread it is bound to - in this case the CameraManager's thread.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fail and return the Camera::configure() operation if any
of the stream turns out to be a nullptr even after the
PipelineHandler handler seems to have configured the config
successfully. This prevents a null-dereference below in the
loop.
Reported-by: Coverity CID=279069
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We don't use full stops at the end of \return directives in Doxygen
documentation. Drop it.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
