| Age | Commit message (Collapse) | Author |
|---|
|
Rename format() to getFormat() to reflect the v4l2 API names more
closely.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
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>
|
|
Extend the camera to support reading and configuring formats for
groups of streams. The implementation in the Camera are minimalistic as
the heavy lifting are done by the pipeline handler implementations.
The most important functionality the camera provides in this context is
validation of data structures passed to it from the application and
access control to the pipeline handler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
All streams which are to be used for capture need to be configured at
the same time. This allows the pipeline handler to take any dependencies
between the different streams and their configuration into account when
setting up the hardware.
Extend the pipeline API and all pipeline implementations with two new
functions, one to read a default configuration and one to set a new
configuration. Both functions operate on a group of streams which the
pipeline handler should consider when performing the operations.
In the current implemented pipelines this is rather easy as they only
have one stream each per camera. Furthermore as there is yet no way for
the pipeline handlers to interact with the hardware all they do is
return a null format, log that a default configuration has been
requested and log that a new configuration has been set. Future work
based on more components are needed to make the pipelines return a good
default format and actually interact with the hardware.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
A camera consists of one or more video streams originating from the same
video source. The different streams could for example have access to
different hardware blocks in the video pipeline and therefore be able to
process the video source in different ways.
All static information describing each stream need to be recorded at
camera creation. After a camera is created an application can retrieve
the static information about its streams at any time.
Update all pipeline handlers to register one stream per camera, this
will be extended in the future for some of the pipelines.
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>
|
|
Exclusive access must be obtained before performing operations that
change the device state. Define an internal flag to track ownership and
provide a means of protecting functions that change device
configuration.
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>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add an initial StreamConfiguration implementation to hold configuration
data for a single stream of a Camera. In its current form not many
configuration parameters are supported but it's expected the number of
options will grow over time.
At this stage the pixel format is represented as an unsigned int to
allow for easy mapping to the V4L2 API. This might be subject to change
in the future as we finalize how libcamera shall represent pixel
formats.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add an initial Stream implementation. The idea is that once capability
support is added to the library each stream will describe its
capabilities using this class. An application will then select one or
more streams based on these capabilities and use them to configure the
camera and capture.
At this stage the Stream class is empty as capabilities are yet to be
added. The class is still useful as it will be used to communicate how
many streams a Camera object provides.
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>
|
|
The class assignment operator is usually defined as returning a
reference to the object, to allow a = b = c statements. While the return
type makes no difference when deleting the operator in a class
definition, it's still a good practice to use the correct return type.
Fix it in the Camera and CameraManager classes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If for any reason a default video device is not found in the media graph
the creation of the UVC pipeline silently failed. This is not optimal
when debugging problems with the pipeline, add an error to notify the
user of the issue.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide an example post-commit hook which a developer can install, ensuring
that every commit gets the style checker executed on it.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add methods to set and get the image format programmed on a V4L2Device
for both the single and multi planar use case.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a V4L2DeviceFormat class aimed to be used to provide format configuration
requests to a V4L2Device.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Re-work camera data registration to create the cameraData pointer as
unique_ptr<> and make clear its ownership model.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Provide a method for the IPU3 pipeline handler that hides the downcast
required to return an "IPU3CameraData *" reference from the
PipelineHandler::cameraData() method.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
While the C++ allows the redefinition of operator= to return an
arbitrary type, it is customary to return a reference to the assigned
value type.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use static_cast<>() instead of reinterpret_cast<>() to perform
downcasts, as reinterpret_cast<>() isn't meant (and guaranteed to be
safe) for that purpose.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Split multi-line help messages and indent all lines the same way.
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>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Once a pipeline-specific data has been associated with a camera, refuse
to update it in order to avoid invalidating the previously set
reference, which might still be owned by the caller.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Apply some comments improvements pointed out during review.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Remove comment and do not delete a class member, as it will be destroyed
already with the instance that contains it.
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>
|
|
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>
|
|
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>
|
|
Fix one wording issue in documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Prior to kernel v4.19, the MEDIA_IOC_G_TOPOLOGY ioctl didn't expose
entity flags. Fallback to calling MEDIA_IOC_ENUM_ENTITIES for each
entity to retrieve the flags in that case.
Fixes: 67d313240c9b ("libcamera: pipeline: uvcvideo: create a V4L2Device for the default video entity")
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>
|
|
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>
|
|
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>
|
|
Add a V4L2Device for the default video entity in the media graph. The
UVC pipeline needs to search for the entity marked with the
MEDIA_ENT_FL_DEFAULT flag as the entity names in the media graph varies
depending on which device is used.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The name dev_ does a poor job of representing that it holds a media
device, rename it to media_. There is no functional change in this
change just s/dev_/media_/.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The media entity flags can be useful for pipeline handlers to find the
default device in a media graph which is marked with the
MEDIA_ENT_FL_DEFAULT flag. This will be especially useful for the UVC
pipeline handler where the entity names differ per device.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Create V4L2 devices for the CIO2 capture video nodes and associate them
with the camera they are part of.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add class definition and methods to associate a Camera with specific data
in the pipeline_handler base class.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add functions to V4L2Capability to identify if a V4L2 device supports
multiplanar V4L2 APIs.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Create a udev_monitor in the udev device enumerator to listen to media
device disconnection, and emit the corresponding media device's
disconnect signal in response.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
UVC devices can be hot-unplugged. Mark the corresponding media device as
hotpluggable to ensure proper disconnection support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Pipeline handlers are responsible for creating camera instances, but
also for destroying them when devices are unplugged. As camera objects
are reference-counted this isn't a straightforward operation and
involves the camera manager and camera object itself. Add two helper
methods in the PipelineHandler base class to register a camera and to
register a media device with the pipeline handler.
When registering a camera, the registerCamera() helper method will add
it to the camera manager. When registering a media device, the
registerMediaDevice() helper method will listen to device disconnection
events, and disconnect all cameras created by the pipeline handler as a
response.
Under the hood the PipelineHandler class needs to keep track of
registered cameras in order to handle disconnection. They can't be
stored as shared pointers as this would create a circular dependency
(the Camera class owns a shared pointer to the pipeline handler). Store
them as weak pointers instead. This is safe as a reference to the camera
is stored in the camera manager, and doesn't get removed until the
camera is unregistered from the manager by the PipelineHandler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The new removeCamera() method is meant to be used by pipeline handlers
to unregister a camera in case of device disconnection.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
As camera object have the potential to outlive the hardware they
represent, there is a need to inform the camera that the underlying
device has been disconnected, and in turn to notify applications.
Implement a disconnection notification mechanism that can be used by
pipeline handlers to notify the camera of disconnection. The camera then
block all new API calls and emit the disconnected signal.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The signal is emitted when the hardware device corresponding to the
media device is unplugged. This will trigger the full unplug handling
chain.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The MediaDevice class will be the entry point to hot-unplug, as it
corresponds to the kernel devices that will report device removal
events. The class will signal media device disconnection to pipeline
handlers, which will clean up resources as a result.
This can't be performed synchronously as references may exist to the
related Camera objects in applications. The MediaDevice object thus
needs to be reference-counted in order to support unplugging, as
otherwise pipeline handlers would be required to drop all the references
to the media device they have borrowed synchronously with the
disconnection signal handler, which would be very error prone (if even
possible at all in a sane way).
Handle MedieDevice instances with std::shared_ptr<> to support this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The PipelineHandler which creates a Camera is responsible for serving
any operation requested by the user. In order forward the public API
calls, the camera needs to store a reference to its pipeline handler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
Changes since v1:
- Create pipeline handlers is shared pointers, make them inherit from
std::enable_shared_from_this<> and stored them in shared pointers.
|
