| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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 libcamera API and the cam tool are now ready to make use of cameras
with more than one stream. Remove the limitation in the tool which
disallows cameras that provide more than one stream.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The completion handler needs to handle all buffers in the request. Solve
this by iterating over all buffers in the completed request. The streams
are named automatically streamX, where X is the order in which the
stream was passed to configureStream().
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Extend the cam tool to allow configuring more than one stream. Add an
optional parameter to the --stream option to specify a usage role for
the stream. The stream role is passed to libcamera to give it control
over which streams to use.
To support multiple streams, creation of requests needs to be reworked
to limit the number of requests to match the stream with the least
number of buffers. This should be improved in the future as the tool and
the library evolve.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
To be able to write multiple buffers captured in the same request (and
hence having the same sequence number) the buffer writer needs to name
each file uniquely. Add a stream name to the writer function which the
buffer writer can add to the part of the pattern it already expands to
the sequence number. As cam only supports one stream, hard code the name
to stream0.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
More than format information needs to be supplied for each stream to
allow multiple streams to be configured. Rename the option and adapt all
usages of it. There is no functional change except the rename.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
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 separate preparation of stream configuration and
application into two different functions. Reason for this is that
preparation of camera configuration will become more complex.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
An empty option list is not necessarily an error. Add a new empty()
function to test the option list for emptiness, and modify the valid()
function to only notify parsing errors. As a side effect this allows
accessing partially parsed options, which may be useful in the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When stopping the stream all pending requests are cancelled, resulting
in the request completion signal being emitted with the request status
set appropriately. Check the request status in the request completion
slot and skip requeuing the request if it has been cancelled.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The arrays that store Stream pointers shall always contain unique
values. Storing them in vectors opens up for the same stream pointer
appearing twice. Remove this possibility by storing them in a set which
guarantees each element is unique.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Upcoming enforcing of order the camera shall be operate on is not
compatible with the cam utility. Requests shall be queued after the
camera is started, not before.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Running the cam tool without any options results in the tool to exit
with EXIT_FAILURE but no usage being printed, this is confusing. Improve
this by also printing the usage text.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Since commit c8c546fe99a343c1 ("cam: options: Add option type handling
to options parser") introduced type handling for options the context the
option is read became important. When reading the camera option for
printing there is no explicit context to print it as a string and
instead the int context was chosen resulting in:
$ cam --camera foo
Camera 0 not found
While the expected output is:
$ cam --camera foo
Camera foo not found
Fix this by providing the correct context for the camera option when
printing it.
Fixes: c8c546fe99a343c1 ("cam: options: Add option type handling to options parser")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The return value when start() and stop() the camera should be checked
and handled.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The allocated buffers needs to be freed once the application is done
with them.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The only caller of configureStreams() stores its return value as an int
and not bool. This is confusing and also prevents the (possibly)
different error codes returned by Camera::configureStreams() to be
propagated inside the cam tool. Fix this by changing the return type to
int and propagate the return value from the camera.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Use the helper BufferWriter to optionally write frames to disk as they
are captured.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an option to capture frames from a camera and keep it running until
the user terminates by sending SIGINT.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an option to configure the first stream of a camera from an argument
with options and parse the width, height and pixel format from that
list.
The pixel format is still specified as a integer which should correspond
to the kernels FOURCC identifiers. Going forward this should be turned
into a string representation and the cam parser should translate between
the two.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Extend the options parser with support for option types. All options
must now specify the type of their argument, and the parser
automatically parses the argument and handles errors internally.
Available types are none, integer or string.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The enumeration of the different possibilities for arguments can be used
by other parser then OptionsParser. Move it outside the class to make it
ready to be used by other parsers.
Signed-off-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>
|
|
Add a simple event loop to the cam application and use it in the main()
function, with an example of how to handle SIGINT to gracefully stop the
loop.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The compiler creates a move constructor automatically when none is
supplied, and it does the right thing by default in this case. Using
std::move() inside the function prevents the compiler from doing
return value optimization and actually hinders performances. Using
std::move() in the caller is unnecessary, the move constructor is used
automatically by the compiler.
For all these reasons remove the tentative optimization that resulted in
worse performances and worse code.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
And turn it into an OptionsParser object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
