| Age | Commit message (Collapse) | Author |
|---|
|
The Buffer class is a large beast the stores information about the
buffer memory, dynamic metadata related to the frame stored in the
buffer, and buffer reference data (in the index). In order to implement
buffer import we will need to extend this with dmabuf file descriptors,
making usage of the class even more complex.
Refactor the Buffer class by splitting the buffer memory information to
a BufferMemory class, and repurposing the Buffer class to reference a
buffer and to store dynamic metadata. The BufferMemory class becomes a
long term storage, valid and stable from the time buffer memory is
allocated to the time it is freed. The Buffer class, on the other hand,
becomes transient, is created on demand when an application requires a
buffer, is given to a request, and is deleted when the request
completes.
Buffer and BufferMemory don't need to be copied, so their copy
constructor and assignment operators are deleted.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Applications often have to map requests queued to a camera to external
resources. To make this easy, add a 64-bit integer cookie to the Request
class that is set when the request is created and can be retrieved at
any time, especially in the request completion handler. The cookie is
completely transparent for libcamera and is never modified.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add a field to IPAModuleInfo to contain the license of the module.
This license field will be used to determine whether the IPA module
should be run in an isolated process or not. If the license is open
source, then the IPA module will be allowed to run without process
isolation, if the user enables it. If the license is not open source,
then the IPA module will be run with process isolation.
Update the dummy IPA and IPA test to conform to the new struct layout.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Currently the log file and the log level can only be set via environment
variables, but applications may also want to set the log file and the
log level at run time. Provide an API for this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
gcc complains that the recently template specialisation of the
SlotBase::match() method is invalid as it is in a non-namespace scope.
Luckily this can easily be fixed by removing the specialisation for the
fully specialised implementation. As an additional safety measure, using
std::enable_if<!std::is_same<Object, T>> on the template implementation
ensures that it will never be called for an Object instance.
Fixes: 56c2e653008a ("libcamera: signal: Fix Object handling in multiple inheritance cases")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The SlotBase implementation stores the receiver object pointer as a void
pointer internally. The pointer is then cast back to an Object pointer
when the receiver object class derives from Object. When the receiver is
an object that inherits from both the Object class and other classes,
the Object data members may not be stored at the beginning of the object
memory. The cast back to an Object pointer is thus incorrect.
Fix this by casting the receiver object pointer to an Object pointer
where the type of the receiver object is known, and pass it along with
the receiver void pointer to the SlotBase class. The SlotBase class
stores both pointers internally, and doesn't need the isObject_ field
anymore as the same information is obtained from checking if the Object
pointer is null.
To avoid confusing the two pointers, use the same naming scheme through
the whole implementation: "obj" points to a receiver object as an
unknown type, and "object" to the receiver object cast to an Object. The
latter is null when the receiver object doesn't inherit from the Object
class.
To further clarify the code, remove direct access to the SlotBase "obj"
and "object" fields as much as possible. They are replaced by two new
methods :
- SlotBase::disconnect() to disconnect a signal from the slot's receiver
object
- SlotBase::match() to test if an object pointer matches the slot
The match() method is a template method with a specialisation for the
Object type, to compare either the obj or the object pointer depending
on the type of the parameter. This is required as the Object destructor
calls the SignalBase::disconnect() method for signal connected to the
object, and passes a pointer to Object to that method, while the actual
object may have a different address due to the issue explained above.
The pointer must thus be compared with the stored Object pointer in that
case, not to the pointer to the receiver object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Allow signals to cross thread boundaries by posting them to the
recipient through messages instead of calling the slot directly when the
recipient lives in a different thread.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Create a new Message class to model a message that can be passed to an
object living in another thread. Only an invalid message type is
currently defined, more messages will be added in the future.
The Thread class is extended with a messages queue, and the Object class
with thread affinity.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The new Thread class wraps std::thread in order to integrate it with the
Object, Signal and EventDispatcher classes. By default new threads run
an internal event loop, and their run() method can be overloaded to
provide a custom thread loop.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Commit b817bcec6b53 ("libcamera: Auto generate version information")
generates version information in order to automatically include it
various locations (Sphinx and Doxygen documentation, libcamera::version
variable available at runtime, and version.h available at compile time).
Unfortunately this causes lots of unnecessary rebuilds when modifying
the git tree state, which hinders development.
The problem is caused by the generated version.h being listed as a
dependency for the whole libcamera. This is required as meson (to the
best of my knowledge) doesn't provide a way to explicitly specify the
dependency of a single object file (camera_manager.o in this case, as
camera_manager.cpp is the only consumer of the generated version string)
on the custom target used to generate version.h. The dependency can't be
automatically detected at build time, like dependencies on normal
headers that are generated by parsing the source, because the version.h
header may not exist yet. The build could then fail in a racy way.
This change attempts at solving the issue by generating a version.cpp
instead of a version.h to set the git-based version. This minimises the
number of files that need to be rebuild when then git tree state
changes, while retaining the main purpose of the original automatic
version generation, the ability to access the git-based version string
at runtime. We however lose the ability to access git-based version
information at build time in an application building against libcamera,
but there is no expected use case for this.
The version string is moved from the libcamera namespace to the
CameraManager class in order to avoid including version.h inside
libcamera (in version.cpp and in camera_manager.cpp), which would create
dependencies causing more rebuild steps, as described above.
On the other hand, major, minor and patch level version numbers are
useful at build time. This commit changes the generation of version.h in
order to add three macros named LIBCAMERA_VERSION_MAJOR,
LIBCAMERA_VERSION_MINOR and LIBCAMERA_VERSION_PATCH for this purpose.
version.h is not included by any other libcamera header or source file,
and thus doesn't force a rebuild of the library.
The Sphinx and Doxygen documentation keep their git-based version
information, which is set during the configuration of the build and then
doesn't track git commits. We may want to investigate how to improve
this, but given that git-based version for the documentation has very
few use cases outside of tagging nightly builds, this isn't considered
an issue at the moment.
The documentation install directory now uses the base version string, in
order to avoid increasing the number of documentation directories
needlessly. This shouldn't cause any issue as the API should not change
without a change to the version number.
The version number generation and handling code now also standardises
the version variables to not start with a 'v' prefix in meson, in order
to simplify their handling. The prefix is added when generating the
relevant files.
Note that we go back to specifying the fallback version in the main
meson.build, in the call to the project() function. For the time being I
believe this should be a good compromise to avoid unnecessary
recompilation, and moving the fallback version to a different file for
tarball releases can be built on top of this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Generate a version string, and provide a global string object which
allows applications to interrogate the current libcamera version
information.
The version header is automatically updated by meson on each build.
The string roughly follows the semver [0] conventions of
major.minor.patch-label as a value.
[0] https://semver.org/
A script (utils/gen-version.sh) is provided which is modelled upon the
processing from autoconf's git-version-gen. The gen-version.sh script
will look for tags in the form vX.Y as starting points for the version
string. While the repository does not have any matching tags, v0.0 will
be assumed, resulting in versions with both major and minor being set to
'0', and the patch count resulting from the number of patches in the
history to that point.
Finally, a uniquely identifying shortened hash is provided from git:
v0.0.509+0ec0edf7
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
IPA modules must be implemented in C++, which means we no longer need
__cplusplus guards, so remove them.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an initial set of controls to demonstrate how controls are defined.
Proper documentation for each control is missing.
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>
|
|
Provide a ControlList on request objects to facilitate setting controls.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The ControlList class implements a map from control specifier to control
ID. To avoid constant lookups of ControlInfo when using the class in the
libcamera core or in pipeline handlers, the map uses ControlInfo
pointers instead of ControlId values. This is however not very
convenient for applications or pipeline handlers, as they would be
forced to first look up the ControlInfo pointers for the controls they
want to access. Facilitate ease of use of ControlLists by implementing
an internal lookup of the ControlInfo from the controls provided by the
Camera.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Extend the Camera class to expose the controls it supports. Each
pipeline should generate a list of controls supported by each camera it
creates. These are represented by a ControlInfoMap, and an associated
ControlList of default values.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Add a set of data types to support controls:
- ControlValue stores a control type and value in a generic way
- ControlId enumerates all the control identifiers
- ControlIdentifier declares the types of a control and map their names
- ControlInfo stores runtime information for controls
- ControlList contains a set of control info and value pairs
The control definitions map is generated from the controls documentation
to ensure that the two will always be synchronised.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
If a timer is running while it's deleted it is still register with the
event dispatcher. This causes a segmentation fault when the timer
time-out and its signal is emitted. Fix this my stopping the timer when
it's deleted.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The files() function generates a variable with the location of the
referenced files.
This is shorter than joining the current_source_dir() of which use is
somewhat frowned upon.
Fixes: 90de3690c456 ("libcamera: Auto-generate libcamera.h")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In preparation of creating a new V4L2Device base class, rename
V4L2Device to V4L2VideoDevice.
This is a project wide rename without any intended functional change.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Allow StreamFormats to be associated to a StreamConfiguration. The
intention is that pipeline handlers should associate formats to a
StreamConfiguration when it's created in generateConfiguration().
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>
|
|
Add a StreamFormats class which describes all the formats supported by a
stream. The object does not collect any information itself but can
simplify user interactions with formats as it's able to translate a
stream format range into a discrete list and a discrete list to a range.
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>
|
|
Add a method to check if a Size can fit inside a SizeRange. When
determining if a size is containable take step values into account if
they are not set to 0.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
It's useful to be able to print a string representation of a SizeRange
to the log or console, add a toString() method. While at it turn the
structure into a class as it contains functions as well as data.
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 size range described might be subject to certain step
limitations. Make it possible to record this information.
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 SizeRange can describe a single size where min == max. Add a
constructor to help create such a description.
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>
|
|
We need a way to match pipelines with IPA modules, so add fields in
IPAModuleInfo to hold the IPA module API version number, the pipeline
name, and the pipeline version.
The module API version is used to determine the layout of struct
IPAModuleInfo.
Also update IPA module tests and Doxygen accordingly. Doxygen needs to
be updated to accomodate __attribute__((packed)).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Define an IPAInterface class which will contain an IPA implementation.
The methods that the IPAInterface exposes form the interface to the IPA
implementation, hence the name. IPA module shared objects will implement
this class.
This also means that IPA module shared objects must be implemented in
C++, so remove the C test IPA module.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Update kernel headers to v5.1
The most notable introduction for libcamera is support for
V4L2_BUF_TYPE_META_OUTPUT.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As shown by two missing includes, keeping the libcamera.h file in sync
when adding or removing headers is an error-prone manual process.
Automate it by generating the header automatically.
The libcamera.h header is also added to the libcamera dependency
libcamera_dep to ensure that the headers gets generated before any
source depending on it gets compiled.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@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>
|
|
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>
|
|
Implement a class to wrap around an IPA module shared object.
For now, just load a struct IPAModuleInfo with symbol name
ipaModuleInfo from an IPA module .so shared object.
Also provide a public header file including the struct IPAModuleInfo,
structured such that both C and C++ IPA modules are supported.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
Several structures are forward-declarated as classes. Fix this by using
the struct keyword where appropriate, or removing the forward
declaration when not needed.
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>
|
|
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>
|
|
Add equality and inequality comparison operators for the Rectangle, Size
and SizeRange classes.
For the Size class, also add ordering operators. Sizes are first
compared on combined width and height, then on area, and finally on
width only to achieve a stable ordering.
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>
|
|
Move the Size class before the SizeRange class. No functional change.
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>
|
|
Add to the Buffer class methods to set and retrieve a reference to the
Request instance the buffer is part of.
As buffers outlive the Request they are associated with, the reference
is only temporary valid during the buffer completion interval (from when
the buffer gets queued to Camera for processing, until it gets marked as
completed).
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>
|
|
Add to the Request class a method to access the map of Stream to Buffer.
With the introduction of multiple stream support, pipeline handler
should be able to access the map of streams at request queueing time.
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>
|
|
Add method to verify if a request has pending buffers yet to be
completed.
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>
|
|
In preparation for multiple streams support prepare to allow sub-classing
the Stream class by removing the 'final' specifier from the class
definition and make its private members protected.
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>
|
|
Implement the camera configuration thru out the library, tests, cam and
qcam tools.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
In preparation of reworking how a default configuration is retrieved
from a camera add stream usages. The usages will be used by applications
to describe how they intend to use a camera and replace the Stream IDs
when retrieving default configuration from the camera using
streamConfiguration().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
