As camera names can be cumbersome to type, selection of cameras by index
from a list can be useful. Print the list of detected cameras with an
index for each item, and interpret the camera name as an index if it is
a numerical value in the range from 1 to the number of cameras.
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 cam utility does not terminate correctly if invoked with only
--help. It prints the help information and then segfaults due to the
application incorrectly handling the return value. Fix this by moving
the return code check of the option parsing to main().
Reported-by: Emmanuel Arias <eamanu@eamanu.com>
Suggested-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add more structure to main.cpp by breaking up the logic into a CamApp
class. This makes the code easier to read and removes all of the
organically grown global variables.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of manually adding the libcamera library and include path to
every target that requires it, declare a dependency that groups the
headers as source, the library and the include path, and use it through
the project. This simplifies handling of the dependency.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Naming a variable that refers to command line options 'conf' is
confusing as we using 'config' and 'cfg' to refer to camera and stream
configurations. Rename it to 'opt'.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
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>
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>
Add a flag to indicate if an option can be repeatable. If an option is
repeatable it must be accessed thru the array interface, even if it's
only specified once by the user.
Also update the usage generator to indicate which options are
repeatable.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To allow specifying the same argument option multiple times a new type
of OptionValue is needed. As parsing of options is an iterative process
there is a need to append options as they are parsed so instead of
setting values using the constructor a new addValue() method is used.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In preparation for support of multiple instances of the same option,
create a separate enum for the OptionValue types as it will diverge from
enum OptionType.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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 c8c546fe99 ("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: c8c546fe99 ("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 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>
The OptionValue class defines operators to convert the variant to all
the supported option types. As a convenience, add explicit methods to
perform the same operations, avoiding the need to write long
static_cast<>() statements in the caller.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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>
Some options passed to the cam utility need to be complex and specify a
list of key=value pairs. Add a new parser to deal with these options,
usable on its own to parse key=value pairs from any string.
Integrate the KeyValueParser into the existing OptionsParser. The cam
application can fully describe all its options in one location and
perform full parsing of all arguments in one go. The KeyValueParser also
integrates itself with the usage() printing of the OptionsParser.
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>
When option are added to the parser, they are stored in the
OptionsParser::options_ vector, and a pointer to the option referencing
the vector entry is indexed in the OptionsParser::optionsMap_ map. When
the next option is added the vector may be resized, which invalidates
the pointers stored in the map.
Fix this by storing the options in an std::list<> instead of
std::vector<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
To later extend the options handling to cover subparsing of arguments it
will be needed to know if the addition of the option itself was
successful or not. The information is already present in addOption()
this change just makes it available.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In preparation to adding more parsers create a template class to hold
the parsed information. The rational for making it a template are that
different parsers can index the options using different data types.
The OptionsParser index its options using an int while the upcoming
KeyValyeParser will index its options using strings for example.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Option structure is declared within the OptionsParser, but will
later be needed by other parsers. Move it outside the OptionsParser
class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
It's not stated in the getopt_long documentation but optional arguments
need to be specified as '--foo=bar' instead of '--foo bar', otherwise
the value is not propagated to optarg during argument parsing. Update
the usage printing helper to reflect this requirement.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Laurent Pinchart
Niklas Söderlund