The ControlInfo id member is only used in the toString() method of the
class, and nowhere else externally. The same way that ControlValue
doesn't store a ControlId, ControlInfo shouldn't. Remove it.
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>
Rework the control-related classes to improve the API towards
applications. The goal is to enable writing code similar to
Request *req = ...;
ControlList &controls = req->controls();
controls->set(controls::AwbEnable, false);
controls->set(controls::ManualExposure, 1000);
...
int32_t exposure = controls->get(controls::ManualExposure);
with the get and set operations ensuring type safety for the control
values. This is achieved by creating the following classes:
- Control defines controls and is the main way to reference a control.
It is a template class to allow methods using it to refer to the
control type.
- ControlId is the base class of Control. It stores the control ID, name
and type, and can be used in contexts where a control needs to be
referenced regardless of its type (for instance in lists of controls).
This class replaces ControlIdentifier.
- ControlValue is kept as-is.
The ControlList class now exposes two template get() and set() methods
that replace the operator[]. They ensure type safety by infering the
value type from the Control reference that they receive.
The main way to refer to a control is now through the Control class, and
optionally through its base ControlId class. The ControlId enumeration
is removed, replaced by a list of global Control instances. Numerical
control IDs are turned into macros, and are still exposed as they are
required to communicate with IPAs (especially to deserialise control
lists). They should however not be used by applications.
Auto-generation of header and source files is removed for now to keep
the change simple. It will be added back in the future in a more
elaborate form.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Make the control API more explicit when dealing with integer controls by
specifying the size. We already do so for 64-bit integers, using int64_t
and ControlTypeInteger64, do the same for 32-bit integers.
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 ControlValue get accessors are implemented with functions of
different names, whlie the set accessors use polymorphism to support
different control types. This isn't very consistent and intuitive. Make
the API clearer by using template methods. This will also have the added
advantage that support for the new types will only require adding
template specialisations, without adding new methods.
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 ipa includes are located in include/libcamera/ipa/. This gives an
incorrect impression that they are a sub-part of the rest of the
libcamera API, while they are the API towards the IPA the same way that
include/libcamera/ contains the API towards applications. To clarify
this, move them to include/ipa/.
The IPA headers are however still part of libcamera, so installing them
to ${prefix}/include/ipa/ would make little sense. To fix this, move the
application facing API to ${prefix}/include/libcamera/libcamera/ when
installed, and the IPA to ${prefix}/include/libcamera/ipa/. When major
versions of libcamera will be released, they could then be installed
side by side in ${prefix}/include/libcamera-${version}/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Linux commit 85ab1aa1fac17bcd ("media: vimc: deb: fix default sink bayer
format") which is part of v5.2 changes the default media bus format for
the debayer subdevices. This leads to a -EPIPE error when trying to use
the raw capture video device nodes.
Fix this by moving the vimc pipeline to use the RGB/YUV Capture capture
video node. As a consequence of this change the scaler in the vimc
pipeline is used and a hard coded upscale of 3 is present in the video
pipeline. This limits the sizes exposed and accepted by libcamera to
multiples of 3.
Update the buffer import test case to match this new format constraint
by setting the resolution to 1920x1080, a resolution which works with
both vimc and vivid. With this new resolution the buffer import test
takes a bit more time to complete 60 buffers and it's runtime also needs
to be increased.
The raw capture video node still needs to be handled by the pipeline as
its format needs to be updated to allow the pipeline format validation
to pass.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
As the device pointers are deleted in the pipelines destructor it's not
a good idea to have them uninitialized.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add support for importing external buffers in all pipeline handlers.
Use the stream memory type in the pipeline handlers during buffer
allocation to import buffers to or export buffers from the video device.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
When stopping the stream buffers have been queued, in which case their
completion is never be notified to the user. This can lead to memory
leaks. Fix it by notifying completion of all queued buffers with the
status set to error.
As a result the base PipelineHandler implementation can be simplified,
as all requests complete as the result of stopping the stream. The
stop() method that manually completes all queued requests isn't needed
anymore.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
libcamera guarantees that requests complete in sequence. This
requirement is currently pushed down to pipeline handlers. Three out of
four of our pipeline handlers implement that requirement based on the
sole assumption that buffers will always complete in sequeuence, while
the IPU3 pipeline handler implements a more complex logic.
It turns out that the logic can be moved to the base PipelineHandler
class with support from the Request class. Do so to simplify the
pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Implement control support in the VIMC pipeline handler by dynamically
querying the V4L2 device for the supported V4L2 controls and populating
the list of camera controls accordingly.
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>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In preparation of creating a new V4L2Device base class, rename
V4L2Device to V4L2VideoDevice.
This is a project wide rename without any intended functional change.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Make the vimc pipeline handler get the dummy IPA, to show how an IPA can
be acquired by a pipeline handler.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
Move the pipeline handler camera data classes, defined in the scope of
the respective pipeline handler class, to the top level of the libcamera
namespace. This prepares for the introduction of other classes that will
make use of them in the IPU3 and RkISP1 pipeline handlers. The UVC and
VIMC pipeline handlers are updated as well for consistency.
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>
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>
Instead of requiring each pipeline handle implementation to keep track
of calling release() on its media devices upon deletion, keep track of
them in the base class. Add a helper that pipeline handlers shall use
to acquire a media device instead of directly interacting with the
DeviceEnumerator.
This also means that pipeline handler implementations do no need to keep
a shared_ptr<> reference to the media devices they store locally as the
PipelineHandler base class will keep a shared_ptr<> reference to all
media devices consumed for the entire lifetime of the pipeline handler
implementation.
Centrally keeping track of media devices will also be beneficial
to implement exclusive access to pipelines across processes.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
In preparation for adding more responsibility to MediaDevice::acquire()
remove unneeded calls to acquire() and release(), and make sure all
needed calls to acquire() are checked and acted on.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Name all instances of CameraConfiguration "config", and all instances of
StreamConfiguration "cfg" accross all pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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 uvcvideo and vimc pipeline handlers print the requested resolution
in their configureStreams() operation. This duplicates a generic log
statement in the Camera::configureStreams() method, remove it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Several overridden virtual functions are not marked with override. Fix
it.
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>
Pipeline handlers might need to perform allocation of internal buffers,
setup operations, or simple sanity check before going into the
per-stream buffer allocation.
As of now, PipelineHandler::allocateBuffers() is called once for each
active stream, leaving no space for stream-independent configuration.
Change this by providing to the pipeline handlers the full set of active
streams, and ask them to loop over them to perform per-streams
memory allocations and freeing.
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>
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>
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>
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>
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>
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>
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>
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>
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.
