Implement buffer allocation and release in IPU3 pipeline handlers.
As the pipeline handler currently supports a single stream, provide two
internal buffer pools for 'viewfinder' and 'stat' video devices, and
export the 'output' video device buffers to the stream's pool. This
works around the fact that the ImgU requires buffers to be queued on all
its outputs, even when they are not in use.
Share buffers between the CIO2 output and the ImgU input video devices,
as the output of the former should immediately be provided to the
latter for further processing.
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>
Apply the requested stream configuration to the CIO2 device, and
propagate formats through the the ImgU subdevice and its input and
output video devices.
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>
Group ImgU components in a class associated with a camera at camera
registration time and provide an intialization method to create and open
all video devices and subdevices of the ImgU.
Statically assign imgu0 to the first camera and imgu1 to the second one
and limit support to two cameras. This will have to be revised in the
future.
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>
Group CIO2 components (cio2, csi2 and image sensor) in a class
associated with the CameraData, to ease management and initialization of
CIO2 unit at camera registration time. A CIO2 unit will always be
associated with a single Camera only.
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>
Request complete by themselves when all the buffers they contain have
completed, connecting the buffer's completed signal to be notified of
buffer completion. While this works for now, it prevents pipelines from
delaying request completion until all metadata is available, and makes
it impossible to ensure that requests complete in the order they are
queued.
To fix this, make request completion handling explicit in pipeline
handlers. The base PipelineHandler class is extended with
implementations of the queueRequest() and stop() methods and gets new
completeBuffer() and completeRequest() methods to help pipeline handlers
tracking requests and buffers.
The three existing pipeline handlers connect the bufferReady signal of
their capture video node to a slot of their respective camera data
instance, where they use the PipelineHandler helpers to notify buffer
and request completion. Request completion is handled synchronously with
buffer completion as the pipeline handlers don't need to support more
advanced use cases, but this paves the road for future work.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Mandate creationg of pipeline-specific data by pipeline handlers. This
allows simplifying the API by passing the pipeline-specific data to the
registerCamera() method and removing the separate setCameraData()
method.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Extend the CameraData class with two member variables pipe_ and camera_
that store pointers to the pipeline handler and camera that the
CameraData instance is related to. This will be used by pipeline
handlers to access the camera and the pipeline in member methods of
their CameraData derived classes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The start(), stop() and queueRequest() methods receive a const pointer
to the related Camera object. The stop() request will need to modify the
state of the camera, in order to report completion of pending requests.
Un-constify the Camera pointer to that method, and update the start()
and queueRequest() methods similarly for coherency.
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>
Subclassing CameraData will become mandatory for pipeline handlers.
Create a new VimcCameraData class and instantiate it when creating
cameras to prepare for that change. The video_ and stream_ fields of the
VIMC pipeline handler belong to the camera data, move them there.
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>
Subclassing CameraData will become mandatory for pipeline handlers.
Create a new UVCCameraData class and instantiate it when creating
cameras to prepare for that change. The video_ and stream_ fields of the
UVC pipeline handler belong to the camera data, move them there.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Media devices are acquired in the match() function of pipeline handlers,
and explicitly released if no match is found. The pipeline handler is
then deleted, which causes a second release of the media device in the
destructor. Fix this by removing the explicit release in the match()
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
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>
The format requested by configureStreams() should exactly match what is
programmed on the video device. If they do not match the call should
fail as the application in that case will not know what configuration
was actually programmed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The format requested by configureStreams() should exactly match what is
programmed on the video device. If they do not match the call should
fail as the application in that case will not know what configuration
was actually programmed.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Remove the std::move() call on the shared_ptr<MediaDevice *> returned by
the search() method and remove the std::move() call on temporary return
value in pipeline handlers that use the method.
Thanks to copy elision, the regular constructor of the newly created
object is called, avoiding un-necessary copies.
Furthermore, the use of std::move() in the return and assignment
statements prevents the compiler from performing copy elision, forcing
it to generate two sequences of un-necessary calls to the class'
move constructor and destructor.
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>
exportBuffers() can only operate on an existing BufferPool allocation. The
pool identifies its size through its .count() method.
Passing a count in to the exportBuffers() call is redundant and can be
incorrect if the value is not the same as the BufferPool size.
Simplify the function and remove the unnecessary argument, correcting all uses
throughout the code base.
While we're here, remove the createBuffers() helper from the V4L2DeviceTest
which only served to obfuscate which pool the buffers were being allocated for.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Pick a default format for the one stream in a vimc camera. This is
just a starting point to define a good default format for the vimc
camera, and is expected to evolve over time as the capabilities of the
library grows.
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>
In order to support capture, the pipeline handler needs methods to
allocate and free buffers, to start and stop the capture and to queue
requests. Define those interfaces in the PipelineHandler class and
implement them as stubs in the existing pipeline handlers.
This initial implementation only considers the allocation of new
buffers. Future work would need to expand this to also cover importing
buffers from an external source.
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>
The V4L2Device constructor wants a "const MediaEntity &", while
entities are usually retrieved by pointer before being used to construct
a V4L2Device. Change the constructor argument to "const MediaEntity *".
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Pick a default format for the UVC one stream in a UVC camera. This is
just a starting point to define a good default format for the UVC camera
it's expected to evolve over time as the capabilities of the library
grows.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Create a camera for Sensor B of the vimc pipeline. At this stage only
Sensor B is exposed while the are in total two sensors in the graph.
Going forward Sensor A should also be exposed as another camera. Sensor
B was chosen since the graph is configured correctly for it out of the
box. As we lack control over sub devices formats it's not really
possible to use Sensor A yet with the library.
Once both cameras are registered with the library they should be
extended to provide two streams each, one for the raw output and one for
the output which uses the shared scaler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@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>
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>
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>
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>
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>
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 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.
Instead of passing the camera manager pointer to the match() function,
and later to more PipelineHandler functions, store it in the
PipelineHandler::manager_ member variable at construction time and
access it from there.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Provide a pipeline handler for uvcvideo devices. The entity names for
UVC devices are different for different cameras so matching on entity
names is not possible in the generic case. This leaves options to create
specialized UVC pipeline handlers if needed to fit a specific model's
needs.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add a pipeline handler for the Intel IPU3 device.
The pipeline handler creates a Camera for each image sensor it finds to be
connected to an IPU3 CSI-2 receiver, and enables the link between the two.
Tested on Soraka, listing detected cameras on the system, verifying the
pipeline handler gets matched and links properly enabled.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The Camera class is explicitly reference-counted to manage the lifetime
of camera objects. Replace this open-coded implementation with usage of
the std::shared_ptr<> class.
This API change prevents pipeline handlers from subclassing the Camera
class. This isn't deemed to be an issue. Mark the class final to make
this explicit.
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>
Cameras are listed through a double indirection, first iterating over
all available pipeline handlers, and then listing the cameras they each
support. To simplify the API make the pipeline handlers register the
cameras with the camera manager directly, which lets the camera manager
easily expose the list of all available cameras.
The PipelineHandler API gets simplified as the handlers don't need to
expose the list of cameras they have created.
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>
Replace usage of the DeviceInfo class with MediaDevice in the
DeviceEnumerator and remove the DeviceInfo class.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Jacopo Mondi
Laurent Pinchart
Niklas Söderlund
Kieran Bingham