| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Ensure that any error from the disableLinks() call during match() is
propogated to the caller.
Fixes: d698ed27494a ("libcamera: ipu3: Create ImgUDevice class")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
As the lengthy comment reports, link enable/disable is not trivial, as
links in one ImgU instance interfere with capture operations in the
other one. As it is not yet clear if this behaviour is intended, as of
now reset the media graph during pipeline's match() and enable the
required links at streamConfiguration time.
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>
|
|
As the procedure to configure the intermediate sizes and the alignement
requirements of the ImgU device have not been clarified yet, return as
default configuration the (2560x1920) resolution that has been validated
for both cameras.
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>
|
|
Use the cached sensor maximum resolution and the pixel format
generated by the ImgU output devices as default stream configuration.
While at it, replace the hardcoded numerical value for the number of
buffers with a named constexpr.
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>
|
|
Connect the CIO2 output bufferRead signal to a slot that simply
queue the received buffer to ImgU for processing, and connect the ImgU
main output bufferReady signal to the cameraData slot that notifies
to applications that a new image buffer is available.
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>
|
|
Implement queueRequest for the IPU3 pipeline manager. When a request is
queued, a new buffer is queued to the ImgU output for capture.
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>
|
|
Start and stop video devices in the pipeline.
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>
|
|
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>
|
|
Cache the sensor maximum size and the media bus code used to produce
it.
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>
|
|
Rename the VIMC pipeline handler to match the naming convention.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Replace the buffer allocation, capture start/stop and request queue
stubs with real implementations.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Create the video devices and subdevices associated with an IPU3 camera.
While at there, move the IPU3 pipeline handler class definition and the
associated IPU3CameraData to a separate header as the class has now
grown enough.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Replace the buffer allocation, capture start/stop and request queue
stubs with real implementations.
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>
|
|
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>
|
|
Replace the buffer allocation, capture start/stop and request queue
stubs with real implementations.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
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>
|
|
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>
|
|
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>
|
|
Log the IPU3 pipeline using IPU3 log category
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
