For debugging purposes, threads can be assigned a name, which eases
distinguishing between them in e.g. htop or gdb. This uses a
Linux-specific API for now which is limited to 15 characters (+ null
terminator), so truncation is done and names for existing thread
instantiations were chosen to be consise.
[Kieran: Apply checkstyle suggestions, rebase on proxy rework]
Signed-off-by: Schulz, Andreas <andreas.schulz2@karlstorz.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds configuration options for environment variables used in
the IPA proxy.
The configuration snippet:
configuration:
ipa:
config_paths:
- config path 1
- config path 2
- ...
module_paths:
- module path 1
- module path 2
- ...
proxy_paths:
- proxy path 1
- proxy path 2
- ...
force_isolation: BOOL
LIBCAMERA_<IPA_NAME>_TUNING_FILE remains configurable only via the
environment variable; this is supposed to be used only for testing and
debugging and it's not clear what to do about IPA names like "rpi/vc4"
and "rpi/pisp" exactly.
There are two ways to pass the configuration to the places where it is
needed: Either to pass it as an argument to the method calls that need
it, or to pass it to the class constructors and extract the needed
configuration from there. This patch uses the second method as it is
less polluting the code.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Global configuration is accessed via a GlobalConfiguration instance.
The instance is conceptually a singleton, but singletons are not welcome
in libcamera so we must store the (preferably single) instance
somewhere.
This patch creates a GlobalConfiguration instance in CameraManager and
defines the corresponding access method. CameraManager is typically
instantiated only once or a few times, it is accessible in many places
in libcamera and the configuration can be retrieved from it and passed
to other places if needed (it's read-only once created). Using
CameraManager for the purpose is still suboptimal and we use it only due
to lack of better options. An alternative could be Logger, which is
still a singleton and it's accessible from everywhere. But with Logger,
we have a chicken and egg problem -- GlobalConfiguration should log
contingent problems with the configuration when it's loaded but if it is
created in the logger then there are mutual infinite recursive calls.
One possible way to deal with this is to look at the environment
variables only during logging initialisation and apply the logging
configuration when a CameraManager is constructed. Considering there
are intentions to remove the Logger singleton, let's omit logging
configuration for now.
If there are multiple CameraManager instances, there are also multiple
GlobalConfiguration instances, each CameraManager instance is meant to
be fully independent, including configuration. They may or may not
contain the same data, depending on whether the global configuration
file in the file system was changed in the meantime.
The configuration is stored in the private CameraManager. It's
accessible within libcamera (via CameraManager) but it's not meant to be
accessed by applications.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Camera creation is one of the most important events generated by
libcamera, but we are completely silent about it. The lack of a log
message makes it more difficult to identify problems and provide
support. Fix it by adding an Info message that reports the camera id and
its pipeline handler when the camera is added.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <uajain@igalia.com>
Reviewed-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Both `CameraManager::Private::{add,remove}Camera()` emit the
`camera{Added,Removed}` signals, respectively, while holding the
lock protecting the list of cameras.
This is problematic because if a callback tries to call `cameras()`,
then the same (non-recursive) lock would be locked again.
Furthermore, there is no real need to hold the lock while user code
is running, so release the lock as soon as possible.
Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
Reviewed-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
If the CameraManager fails to initialise at startup during
CameraManager::Private::init(), then the run() function will prepare the
thread for operations, but the thread will immediately close without
executing any cleanup.
This can leave instantiated objects such as the EventNotifier registered
by the udev enumerator constructed in a thread which no longer exists.
The destructor of those objects can then fire an assertion that they are
being executed from an incorrect thread while performing their cleanup.
Ensure that the failure path does not result in reporting thread
ownership assertions by performing cleanup correctly on the
CameraManager thread before it closes.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The API reference pages generated by Doxygen are comprehensive, but
therefore quite overwhelming for application developers who will
likely never need to use the majority of the library's objects. To
reduce the complexity of the documentation, split it into two runs of
doxygen.
The first run of doxygen is for the public API. We pass a specific list
of source files to parse, which is built from the arrays of public
headers and sources in meson build files. This ensures that we only
generate the documentation for code from those files.
A custom Python script is needed to add the list of input files to
Doxyfile, as several of the objects included in the header and source
array are custom_tgt objects, which can't be handled as strings to
populate a variable in the configuration data.
The headers defining the Extensible and Object classes (class.h and
object.h respectively), as well as the corresponding source files, are
excluded from the public API documentation despite being referenced in
the meson public headers and sources arrays. This is due to the fact
that public API classes inherit from Extensible and Object, making the
Extensible and Object classes part of the public ABI. Those two base
classes are however implementation details and must not be accessed
directly by application code.
The second run of doxygen is for the internal API. This contains
documentation for all of the library's objects as it currently does.
This set will now be output into build/Documentation/internal-api-html.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
The IPAManager class implements a singleton pattern due to the need of
accessing the instance in a static member function. The function now
takes a pointer to a PipelineHandler, which we can use to access the
CameraManager, and from there, the IPAManager.
Add accessors to the internal API to expose the CameraManager from the
PipelineHandler, and the IPAManager from the CameraManager. This
requires allocating the IPAManager dynamically to avoid a loop in
includes. Use those accessors to replace the IPAManager singleton.
Update the IPA interface unit test to instantiate a CameraManager
instead of an IPAManager and ProcessManager, to reflect the new way that
the IPAManager is accessed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The *::Private classes are part of the internal API, as their name
implies. They are defined in internal headers, but implemented in the
same source file as their public counterparts. This will cause Doxygen
to complain about missing class definition when splitting the public and
internal API documents, as the internal headers won't be parsed by
Doxygen for the public API documentation.
Marking the classes with \internal isn't enough. The directive prevents
the documentation block from being included in the output, but this
occurs at the generation stage, after the documentation blocks are
parsed. Fix this by completely hidding the implementation of the
*::Private classes from Doxygen using preprocessor conditional
compilation. To do so, introduce a new macro, __DOXYGEN_PUBLIC__, that
will be defined for the public API documentation only.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The libcamera public API exposes classes that have parts considered
internal. They inherit the Extensible class, and their internal parts
are split into a Private class. Those classes are defined in public API
headers, and their Private counterparts are defined in internal headers
sharing a common file name (in a different directory). Both headers are
documented in the same source file.
For instance, include/libcamera/camera.h contains the public API of the
Camera class, and include/libcamera/internal/camera.h its internal
counterpart. Both are documented in src/libcamera/camera.cpp.
As the internal headers are not part of the public API, they need to be
hidden from the future public API builds. To prepare for doing so, mark
them with the \internal Doxygen directive. Hardcode the Doxygen
INTERNAL_DOCS option to YES to include the internal API. This will be
changed later for the public API documentation build.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To match the enumerated media devices, each registered pipeline handler
is used in no specific order. It is a limitation when several pipelines
can match the devices, and user has to select a specific pipeline.
For this purpose, environment variable LIBCAMERA_PIPELINES_MATCH_LIST is
created to give the option to define an ordered list of pipelines to
match on.
LIBCAMERA_PIPELINES_MATCH_LIST="<name1>[,<name2>[,<name3>...]]]"
Example:
LIBCAMERA_PIPELINES_MATCH_LIST="rkisp1,simple"
Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment blocks in all
remaining locations that were not caught by the automated script as they
are out of sync with the file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
The CameraManager::get(dev_t) implementation was provided only for the
V4L2 Adaptation layer. This has now been replaced with the use of the
public SystemDevices property.
Remove the deprecated function entirely, along with the camerasByDevnum_
map which was only used to support this functionality.
This is a clear (and intentional) breakage in both the API and ABI.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Register the identified device numbers with each camera as the
SystemDevices property.
This facilitates camera daemons or other systems to identify which
devices are being managed by libcamera, and can prevent duplication of
camera resources.
As the SystemDevices property now provides this list of devices, use it
directly from within the CameraManager when adding a Camera rather than
passing it through the internal API.
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CameraManager exposes addCamera and removeCamera as public API
calls, while they should never be called from an application. These
calls are only expected to be used by PipelineHandlers to update the
CameraManager that a new Camera has been created and allow the Camera
Manager to expose it to applications.
Remove the public calls and update the private implementations such that
they can be used directly by the PipelineHandler through the internal
CameraManager::Private provided by the Extensible class.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The CameraManager makes use of the Extensible pattern to provide an
internal private implementation that is not exposed in the public API.
Move the Private declaration to an internal header to make it available
from other internal components in preperation for reducing the surface
area of the public interface of the CameraManager.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently the function `createPipelineHandlers` connects itself to the
`devicesAdded` signal at the end of each call. As the Signal object
supports multiple non-unique listeners connected to it, the former
function would be called exponentially often with each new emitted event
on `devicesAdded` (i.e. with udev plugging in a new camera)
Fix it by connecting the createPipelineHandlers() slot to `devicesAdded`
signal in CameraManager::Private::init() instead. This will prevent the
slot getting connected multiple times to the `devicesAdded` signal.
Signed-off-by: Sophie Friedrich <dev@flowerpot.me>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits
from the PipelineHandlerFactory class, and implements a constructor and
a createInstance() function. Replace the code generation through macro
with the C++ equivalent, a class template, as done in libipa with the
Algorithm and CameraSensorHelper factories.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Avoid naked pointer with memory allocation by returning a unique_ptr
from PipelineHandlerFactory::createInstance(), in order to increase
memory allocation safety.
This allows iterating over factories in the CameraManager and unit tests
using const pointers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Use a const reference in range-based for loops to avoid copies of the
loop elements.
While at it, change looping over controls in
PipelineHandlerUVC::processControls to use structured bindings.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
ConditionVariable is alias to std::condition_variable. This replaces
std::condition_variable with the ConditionVariable. It enables
replacing ConditionVariable implementation easily in the following
patches.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
When disconnecting a signal from a receiver, it is usually not necessary
to specify the receiver's slot function explicitly, as the signal is
often connected to a single slot for a given receiver. We can thus use a
simpler version of Signal::disconnect() that takes a pointer to the
receiver object only. This reduces code size, as the disconnect()
function is a template function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The Extensible constructor takes a pointer to a Private instance, whose
lifetime it then manages. Make this explicit in the API by passing the
pointer as a std::unique_ptr<Private>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Extensible and Extensible::Private classes contain pointers to each
other. These pointers are initialized in the respective class's
constructor, by passing a pointer to the other class to each
constructor. This particular construct reduces the flexibility of the
Extensible pattern, as the Private class instance has to be allocated
and constructed in the members initializer list of the Extensible
class's constructor. It is thus impossible to perform any operation on
the Private class between its construction and the construction of the
Extensible class, or to subclass the Private class without subclassing
the Extensible class.
To make the design pattern more flexible, don't pass the pointer to the
Extensible class to the Private class's constructor, but initialize the
pointer manually in the Extensible class's constructor. This requires a
const_cast as the o_ member of the Private class is const.
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>
Now that all Extensible classes expose a _d() function that performs
appropriate casts, the LIBCAMERA_D_PTR brings no real additional value.
Replace it with direct calls to the _d() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Move the functionality for the following components to the new
base support library:
- BoundMethod
- EventDispatcher
- EventDispatcherPoll
- Log
- Message
- Object
- Signal
- Semaphore
- Thread
- Timer
While it would be preferable to see these split to move one component
per commit, these components are all interdependent upon each other,
which leaves us with one big change performing the move for all of them.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The libcamera namespace has been left undefined from the start. While
the documentation doesn't bring much added value, leaving it out
confuses the most recent doxygen master branch:
include/libcamera/transform.h:16: warning: Internal inconsistency: member Identity does not belong to any container!
include/libcamera/transform.h:17: warning: Internal inconsistency: member Rot0 does not belong to any container!
include/libcamera/transform.h:18: warning: Internal inconsistency: member HFlip does not belong to any container!
include/libcamera/transform.h:19: warning: Internal inconsistency: member VFlip does not belong to any container!
include/libcamera/transform.h:20: warning: Internal inconsistency: member HVFlip does not belong to any container!
include/libcamera/transform.h:21: warning: Internal inconsistency: member Rot180 does not belong to any container!
include/libcamera/transform.h:22: warning: Internal inconsistency: member Transpose does not belong to any container!
include/libcamera/transform.h:23: warning: Internal inconsistency: member Rot270 does not belong to any container!
include/libcamera/transform.h:24: warning: Internal inconsistency: member Rot90 does not belong to any container!
include/libcamera/transform.h:26: warning: Internal inconsistency: member Rot180Transpose does not belong to any container!
Document it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Since pipeline registration is done with declaring static factory
objects, there is a risk that pipeline factories will be constructed
before libcamera facilities are ready. For example, logging in the
constructor of a pipeline handler factory may cause a segfault if
threading isn't ready yet. Avoid this issue by moving printing the
registration of the pipeline handler to the camera manager.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
If any Process instances are destroyed after the ProcessManager is
destroyed, then a segfault will occur.
Fix this by making the lifetime of the ProcessManager explicit, and make
the CameraManager construct and deconstruct (automatically, via a member
variable) the ProcessManager.
Update the tests accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Rename Camera::name() to camera::id() to better describe what it
represents, a unique and stable ID for the camera. While at it improve
the documentation for the camera ID to describe it needs to be stable
for a camera between resets of the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Object::deleteLater() ensures that the deletion of the Object
takes place in a thread it is bound to. Deleting the Object
in a different thread is a violation according to the libcamera
threading model.
On hot-unplug of a currently streaming camera, the last reference
of Camera when dropped from the application thread (for e.g. QCam's
thread), the destructor is then called from this thread. This is not
allowed by the libcamera threading model. Camera is meant to be deleted
in the thread it is bound to - in this case the CameraManager's thread.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Emit 'cameraAdded' and 'cameraRemoved' from CameraManager to enable
hotplug and hot-unplug support in application like QCam.
To avoid use-after-free race between the CameraManager and the
application, emit the 'cameraRemoved' with the shared_ptr version
of <Camera *>. This requires to change the function signature of
CameraManager::removeCamera() API.
Also, until now, CameraManager::Private::addCamera() transfers the
entire ownership of camera shared_ptr to CameraManager using
std::move(). This patch changes the signature of Private::addCamera to
accept pass-by-value camera parameter. It is done to make it clear from
the caller point of view that the pointer within the caller will still
be valid after this function returns. With this change in, we can emit
the camera pointer via 'cameraAdded' signal without hitting a segfault.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Emit a signal whenever new MediaDevices are added to the
DeviceEnumerator. This will allow CameraManager to be notified
about the new devices and it can re-emumerate all the devices
currently present on the system.
Device enumeration by the CameraManger is an expensive operation hence,
we want one signal emission per 'x' milliseconds to notify multiple
devices additions as a single batch, by the DeviceEnumerator.
Add a \todo to investigate the support for that.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This commit introduces no functional changes.
Split pipelines creation code into a separate function,
so that the function can be re-used for upcoming hotplug
functionality in subsequent commits.
Also, fixup correct tag for \todo.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The pipes_ vector was initially used to store pipeline handlers
instances with the CameraManager when it cannot be referenced from
anywhere else. It was used to retrieve cameras and deleting pipeline
handlers when stopping the camera manager.
In f3695e9b09 ("libcamera: camera_manager: Register cameras with the
camera manager"), cameras started to get registered directly with camera
manager and in 5b02e03199 ("libcamera: camera: Associate cameras with
their pipeline handler") pipeline handlers started to get stored in a
std::shared_ptr<> with each camera starting to hold a strong reference
to its associated pipeline-handler. At this point, both the camera
manager and the camera held a strong reference to the pipeline handler.
Since the additional reference held by the camera manager gets released
only on cleanup(), this lurking reference held on pipeline handler did
not allow it to get destroyed even when cameras instances have been
destroyed. This situation of having a pipeline handler instance around
without having a camera may lead to problems (one of them explained
below) especially when the camera manager is still running.
It was noticed that, there was a dangling driver directory issue (tested
for UVC camera - in /sys/bus/usb/drivers/uvcvideo) on 'unbind' → 'bind'
operation while the CameraManager is running. The directories were still
kept around even after 'unbind' because of the lurking reference of
pipeline handler holding onto them. That reference would clear if and
only if the CameraManager is stopped and then only directories were
getting removed in the above stated path.
Rather than writing a fix to release the pipeline handlers' reference
from camera manager on camera disconnection, it is decided to eliminate
the pipes_ vector from CameraManager moving forwards. There is no
point in holding a reference to it from camera manager's point-of-view
at this stage. It also helps us to fix the issue as explained above.
Now that the pipeline handler instances are referenced via cameras only,
it can happen that the destruction of last the camera instance may
result in destruction of the pipeline handler itself. Such a possibility
exists in PipelineHandler::disconnect(), where the pipeline handler
itself can get destroyed while removing the camera. This is acceptable
as long as we make sure that there is no access of pipeline handler's
members later on in the code path. Address this situation and also add a
detailed comment about it.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
