Create a class to represent a pixel format. This is done to add support
for modifiers for the formats. So far no modifiers are added by any
pipeline handler, all plumbing to deal with them is however in place.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of having to include linux/drm_fourcc.h everywhere a DRM FourCC
is used in conjunction with PixelFormat include the header directly in
pixelformats.h.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use the PixelFormat instead of unsigned int where a pixel format is to
be used. PixelFormat is defined as an unsigned int but is about to be
turned into a class to add functionality.
There is no functional change in this patch.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Associate to each Camera a ControlList which contains the Camera
properties as created by pipeline handlers in the pipeline handler's
CameraData and provide an operation to retrieve them.
Collect properties from the camera sensor in all pipeline handlers that
support one (IPU3, RKISP1 and VIMC).
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>
When inserting an element with emplace(), the element is constructed
in-place with the parameters to the emplace() method being forwarded to
the constructor of the element. For std::map containers, the element is
an std::pair<const Key, T>. The constructors of std::pair<T1, T2> fall
into three categories:
(1) Default, copy and move constructors (and related versions)
(2) Constructors that take lvalue or rvalue references to T1 and T2
(3) A forwarding constructor that forwards parameters to the
constructors of T1 and T2
The first category isn't useful in most cases for std::map::emplace(),
as the caller usually doesn't have an existing std::pair<const Key, T>
for the element to be inserted.
The constructor from the third category is useful to avoid constructing
intermediate Key or T instances when the caller doesn't have them
available. This constructor takes two std::tuple arguments that contain
the arguments for the Key and T constructors, respectively. Due to
template deduction rules, usage of such a constructor couldn't be
deduced by the compiler automatically in all cases, so the constructor
takes a first argument of type std::piecewise_construct_t that lets the
caller force the usage ot the forwarding constructor (also known for
this reason as the piecewise constructor). The caller uses a construct
such as
map.emplace(std::piecewise_construct,
std::forward_as_tuple(args_for_Key, ...),
std::forward_as_tuple(args_for_T, ...));
This syntax is a bit heavy, but is required to construct Key and T
in-place from arguments to their non-default constructor (it is also the
only std::pair non-default constructor that can be used for non-copyable
non-movable types).
When the caller of std::map::emplace() already has references to a Key
and a T, they can be passed to the std::pair piecewise constructor, and
this will create std::tuple instance to wrap the Key and T references
arguments to ultimately pass them to the Key and T copy constructors.
map.emplace(std::piecewise_construct,
std::forward_as_tuple(Key_value),
std::forward_as_tuple(T_value));
While this mechanism works, it's unnecessary complex. A constructor of
std::pair that takes references to Key and T can be used without any
performance penalty, as it will also call the copy constructor of Key
and T. In this case we can use a simpler constructor of std::pair, and
thus a simpler call of std::map::emplace.
map.emplace(Key_value, T_value);
We have a couple occurrences of this above misuse of piecewise
construction. Simplify them, which simplifies the code and reduces the
generated code size.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
With the FrameBuffer interface in place there is no need for the Camera
to call into the specific pipelines allocation and freeing of buffers as
it no longer needs to be synchronized with buffer allocation by the
application.
Remove the function prototypes in the pipeline handler base class and
fold the functionality in the pipelines start() and stop() functions
where needed. A follow up patch will remove the now no-op
Camera::allocateBuffers() and Camera::freeBuffers().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Buffer interface is no longer in use and can be removed. While doing
so clean up the two odd names (dequeueFrameBuffer() and
queuedFrameBuffers_) that had to be used when adding the FrameBuffer
interface.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Switch to the FrameBuffer interface where all buffers are treated as
external buffers and are allocated outside the camera. Applications
allocating buffers using libcamera are switched to use the
FrameBufferAllocator helper.
Follow-up changes to this one will finalize the transition to the new
FrameBuffer interface by removing code that is left unused after this
change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Extend the pipeline handlers to support the FrameBuffer API with three
new methods to handle allocation, importing and freeing of buffers. The
new methods will replace allocateBuffers() and freeBuffers().
The FrameBuffer API will use the methods on a stream level and either
allocate or import buffers for each active stream controlled from the
Camera class and an upcoming FrameBufferAllocator helper. With this new
API the implementation in pipeline handlers can be made simpler as all
streams don't need to be handled in allocateBuffers().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Expecting pipeline handler implementations of queueRequest() to call
the base class queueRequest() at the correct point have led to different
behaviors between the pipelines.
Fix this by splitting queueRequest() into a base class implementation
which handles the bookkeeping and a new queueRequestDevice() that is
to be implemented by pipeline handlers and only deals with committing the
request to the device.
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 preparation for serialization, index the ControlList by unsigned int.
This will allow deserializing a ControlList without requiring external
information.
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>
Fill the StreamConfiguration with all supported formats. The list of
supported formats is currently hardcoded based on the limits of the vimc
driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The V4L2ControlList class only provides a convenience constructor for
the ControlList, which can easily be moved to the ControlList class and
may benefit it later (to construct a ControlList from controls supported
by a camera). Move the constructor and remove V4L2ControlList.
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 ControlInfoMap and V4L2ControlInfoMap classes are very similar, with
the latter adding convenience accessors based on numerical IDs for the
former, as well as a cached idmap. Both features can be useful for
ControlInfoMap in the context of serialisation, and merging the two
classes will further simplify the IPA API.
Import all the features of V4L2ControlInfoMap into ControlInfoMap,
turning the latter into a real class. A few new constructors and
assignment operators are added for completeness.
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>
V4L2ControlRange only offers a convenience constructor for a
ControlRange. Store the ControlRange instead of V4L2ControlRange in
V4L2ControlInfoMap to make the map less dependent on V4L2 types.
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 V4L2ControlInfo class only stores a ControlRange. Make it inherit
from ControlRange to provide a convenience constructor from a struct
v4l2_query_ext_ctrl and rename it to V4L2ControlRange.
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 bring the libcamera and V4L2 control info maps closer, index the
latter by ControlId * like the former. As V4L2ControlInfoMap is widely
indexed by V4L2 numerical IDs, add accessors based on numerical IDs.
This allows complete removal of the ControId pointer from the
V4L2ControlInfo, as the ControId is accessible as the key when iterating
over the map. A handful of users have to be modified to adapt to the
change.
The controlInfo argument from V4L2Device::updateControls() can also be
removed as it itsn't used anymore.
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 V4L2Device class uses V4L2ControlList as a controls container for
the getControls() and setControls() operations. Having a distinct
container from ControlList will makes the IPA API more complex, as it
needs to explicitly transport both types of lists. This will become even
more painful when implementing serialisation and deserialisation.
To simplify the IPA API and ease the implementation of serialisation and
deserialisation, replace usage of V4L2ControlList with ControlList in
the V4L2Device (and thus CameraSensor) API. The V4L2ControlList class
becomes a thin wrapper around ControlList that slightly simplifies the
creation of control lists for V4L2 controls, and may be removed in the
future.
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>
Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The IPA acts on a camera and not on a pipeline which can expose more
then one camera. Move the IPA reference to the CameraData.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use the ControlRange class to express the range of a V4L2 control,
replacing the open-coded minimum and maximum fields in the
V4L2ControlInfo class.
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>
Use the ControlValue class to replace the manually crafted data storage
in V4L2Control. This will help sharing code when more data types will be
supported.
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>
The ControlInfo id member is only used in the toString() method of the
class, and nowhere else externally. The same way that ControlValue
doesn't store a ControlId, ControlInfo shouldn't. Remove it.
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>
Rework the control-related classes to improve the API towards
applications. The goal is to enable writing code similar to
Request *req = ...;
ControlList &controls = req->controls();
controls->set(controls::AwbEnable, false);
controls->set(controls::ManualExposure, 1000);
...
int32_t exposure = controls->get(controls::ManualExposure);
with the get and set operations ensuring type safety for the control
values. This is achieved by creating the following classes:
- Control defines controls and is the main way to reference a control.
It is a template class to allow methods using it to refer to the
control type.
- ControlId is the base class of Control. It stores the control ID, name
and type, and can be used in contexts where a control needs to be
referenced regardless of its type (for instance in lists of controls).
This class replaces ControlIdentifier.
- ControlValue is kept as-is.
The ControlList class now exposes two template get() and set() methods
that replace the operator[]. They ensure type safety by infering the
value type from the Control reference that they receive.
The main way to refer to a control is now through the Control class, and
optionally through its base ControlId class. The ControlId enumeration
is removed, replaced by a list of global Control instances. Numerical
control IDs are turned into macros, and are still exposed as they are
required to communicate with IPAs (especially to deserialise control
lists). They should however not be used by applications.
Auto-generation of header and source files is removed for now to keep
the change simple. It will be added back in the future in a more
elaborate form.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Make the control API more explicit when dealing with integer controls by
specifying the size. We already do so for 64-bit integers, using int64_t
and ControlTypeInteger64, do the same for 32-bit integers.
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>
The ControlValue get accessors are implemented with functions of
different names, whlie the set accessors use polymorphism to support
different control types. This isn't very consistent and intuitive. Make
the API clearer by using template methods. This will also have the added
advantage that support for the new types will only require adding
template specialisations, without adding new methods.
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>
The ipa includes are located in include/libcamera/ipa/. This gives an
incorrect impression that they are a sub-part of the rest of the
libcamera API, while they are the API towards the IPA the same way that
include/libcamera/ contains the API towards applications. To clarify
this, move them to include/ipa/.
The IPA headers are however still part of libcamera, so installing them
to ${prefix}/include/ipa/ would make little sense. To fix this, move the
application facing API to ${prefix}/include/libcamera/libcamera/ when
installed, and the IPA to ${prefix}/include/libcamera/ipa/. When major
versions of libcamera will be released, they could then be installed
side by side in ${prefix}/include/libcamera-${version}/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Linux commit 85ab1aa1fac17bcd ("media: vimc: deb: fix default sink bayer
format") which is part of v5.2 changes the default media bus format for
the debayer subdevices. This leads to a -EPIPE error when trying to use
the raw capture video device nodes.
Fix this by moving the vimc pipeline to use the RGB/YUV Capture capture
video node. As a consequence of this change the scaler in the vimc
pipeline is used and a hard coded upscale of 3 is present in the video
pipeline. This limits the sizes exposed and accepted by libcamera to
multiples of 3.
Update the buffer import test case to match this new format constraint
by setting the resolution to 1920x1080, a resolution which works with
both vimc and vivid. With this new resolution the buffer import test
takes a bit more time to complete 60 buffers and it's runtime also needs
to be increased.
The raw capture video node still needs to be handled by the pipeline as
its format needs to be updated to allow the pipeline format validation
to pass.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
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>
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>
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>
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>
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>
