| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Move the utils functionality to the libcamera/base library.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Fixes: e9b47217b44c ("libcamera: camera_manager: Introduce signals when a camera is added or removed")
Signed-off-by: Umang Jain <email@uajain.com>
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>
|
|
The destructor stops the camera manager if it is running. This is at the
moment an implementation detail, but makes sense to guarantee in the
API. Document it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
There's no user of the EventDispatcher (and the related EventNotifier
and Timer classes) outside of libcamera. Move those classes to the
internal API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the d-pointer infrastructure offered by the Extensible class to
replace the custom implementation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The mutex_ stored in the CameraManager::Private class is used to protect
members that may need to be accessed from const functions. Make it
mutable to allow this.
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: Paul Elder <paul.elder@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>
|
|
The camera ID is documented that it should be unique but it's not
enforced. Change this by refusing to add cameras to the CameraManager
that would create two cameras with the exact same ID.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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 f3695e9b09ce ("libcamera: camera_manager: Register cameras with the
camera manager"), cameras started to get registered directly with camera
manager and in 5b02e03199b7 ("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>
|
|
The V4L2 compatibility layer uses devnum to match video device nodes to
libcamera Cameras. Some pipeline handlers don't report a devnum for
their camera, which prevents the V4L2 compatibility layer from matching
video device nodes to these cameras. To fix this, we first allow the
camera manager to map multiple devnums to a camera. Next, we walk the
media device and entity list and tell the camera manager to map every
one of these devnums that is a video capture node to the camera.
Since we decided that all video capture nodes that belong to a camera
can be opened via the V4L2 compatibility layer to map to that camera, it
would cause confusion for users if some pipeline handlers decided that
only specific device nodes would map to the camera. To prevent this
confusion, remove the ability for pipeline handlers to declare their own
devnum-to-camera mapping. The only pipeline handler that declares the
devnum mapping is the UVC pipeline handler, so remove the devnum there.
We considered walking the media entity list and taking the devnum from
just the one with the default flag set, but we found that some drivers
(eg. vimc) don't set this flag for any entity. Instead, we take all the
video capture nodes (entities with the sink pad flag set).
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If any ipa_context instances are destroyed after the IPAManager is
destroyed, then a segfault will occur, since the modules have been
unloaded by the IPAManager and the context function pointers have been
freed.
Fix this by making the lifetime of the IPAManager explicit, and make the
CameraManager construct and deconstruct (automatically, via a unique
pointer) the IPAManager.
Also update the IPA interface test to do the construction and
deconstruction of the IPAManager, as it does not use the CameraManager.
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>
|
|
The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Relying on the application event loop to process all our internal events
is a bad idea for multiple reasons. In many cases the user of libcamera
can't provide an event loop, for instance when running through one of
the adaptation layers. The Android camera HAL and V4L2 compatibility
layer create a thread for this reason, and the GStreamer element would
need to do so as well. Furthermore, relying on the application event
loop pushes libcamera's realtime constraints to the application, which
isn't manageable.
For these reasons it's desirable to always run the camera manager, the
pipeline handlers and the cameras in a separate thread. Doing so isn't
too complicated, it only involves creating the thread internally when
starting the camera manager, and synchronizing a few methods of the
Camera class. Do so as a first step towards defining the threading model
of libcamera.
The event dispatcher interface is still exposed to applications, to
enable cross-thread signal delivery if desired.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Making CameraManager::cameras() thread-safe requires returning a copy of
the cameras vector instead of a reference. This is also required for
hot-plugging support and is thus desirable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Use the d-pointer idiom ([1], [2]) to hide the private data members from
the CameraManager class interface. This will ease maintaining ABI
compatibility, and prepares for the implementation of the CameraManager
class threading model.
[1] https://wiki.qt.io/D-Pointer
[2] https://en.cppreference.com/w/cpp/language/pimpl
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
device numbers
The V4L2 compatibility layer will need a way to map device numbers to
libcamera Camera instances. Expose a method in the camera manager to
retrieve Camera instances by devnum. The mapping from device numbers to
Camera instances is optionally declared by pipeline handlers when they
register cameras with the camera manager.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix a typo in the CameraManager documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraManager class is not supposed to be instantiated multiple
times, which led to a singleton implementation. This requires a global
instance of the CameraManager, which is destroyed when the global
destructors are executed.
Relying on global instances causes issues with cleanup, as the order in
which the global destructors are run can't be controlled. In particular,
the Android camera HAL implementation ends up destroying the
CameraHalManager after the CameraManager, which leads to use-after-free
problems.
To solve this, remove the CameraManager::instance() method and make the
CameraManager class instantiable directly. Multiple instances are still
not allowed, and this is enforced by storing the instance pointer
internally to be checked when an instance is created.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraManager class uses the event dispatcher of the current thread.
This makes the CameraManager::eventDispatcher() and
CameraManager::setEventDispatcher() methods inconsistent, as they access
different event dispatcher instances depending on the calling thread.
Fix this by inheriting from the Object class, which binds the
CameraManager to a thread, and use the event dispatcher of the bound
thread.
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 new Thread class wraps std::thread in order to integrate it with the
Object, Signal and EventDispatcher classes. By default new threads run
an internal event loop, and their run() method can be overloaded to
provide a custom thread loop.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Commit b817bcec6b53 ("libcamera: Auto generate version information")
generates version information in order to automatically include it
various locations (Sphinx and Doxygen documentation, libcamera::version
variable available at runtime, and version.h available at compile time).
Unfortunately this causes lots of unnecessary rebuilds when modifying
the git tree state, which hinders development.
The problem is caused by the generated version.h being listed as a
dependency for the whole libcamera. This is required as meson (to the
best of my knowledge) doesn't provide a way to explicitly specify the
dependency of a single object file (camera_manager.o in this case, as
camera_manager.cpp is the only consumer of the generated version string)
on the custom target used to generate version.h. The dependency can't be
automatically detected at build time, like dependencies on normal
headers that are generated by parsing the source, because the version.h
header may not exist yet. The build could then fail in a racy way.
This change attempts at solving the issue by generating a version.cpp
instead of a version.h to set the git-based version. This minimises the
number of files that need to be rebuild when then git tree state
changes, while retaining the main purpose of the original automatic
version generation, the ability to access the git-based version string
at runtime. We however lose the ability to access git-based version
information at build time in an application building against libcamera,
but there is no expected use case for this.
The version string is moved from the libcamera namespace to the
CameraManager class in order to avoid including version.h inside
libcamera (in version.cpp and in camera_manager.cpp), which would create
dependencies causing more rebuild steps, as described above.
On the other hand, major, minor and patch level version numbers are
useful at build time. This commit changes the generation of version.h in
order to add three macros named LIBCAMERA_VERSION_MAJOR,
LIBCAMERA_VERSION_MINOR and LIBCAMERA_VERSION_PATCH for this purpose.
version.h is not included by any other libcamera header or source file,
and thus doesn't force a rebuild of the library.
The Sphinx and Doxygen documentation keep their git-based version
information, which is set during the configuration of the build and then
doesn't track git commits. We may want to investigate how to improve
this, but given that git-based version for the documentation has very
few use cases outside of tagging nightly builds, this isn't considered
an issue at the moment.
The documentation install directory now uses the base version string, in
order to avoid increasing the number of documentation directories
needlessly. This shouldn't cause any issue as the API should not change
without a change to the version number.
The version number generation and handling code now also standardises
the version variables to not start with a 'v' prefix in meson, in order
to simplify their handling. The prefix is added when generating the
relevant files.
Note that we go back to specifying the fallback version in the main
meson.build, in the call to the project() function. For the time being I
believe this should be a good compromise to avoid unnecessary
recompilation, and moving the fallback version to a different file for
tarball releases can be built on top of this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Generate a version string, and provide a global string object which
allows applications to interrogate the current libcamera version
information.
The version header is automatically updated by meson on each build.
The string roughly follows the semver [0] conventions of
major.minor.patch-label as a value.
[0] https://semver.org/
A script (utils/gen-version.sh) is provided which is modelled upon the
processing from autoconf's git-version-gen. The gen-version.sh script
will look for tags in the form vX.Y as starting points for the version
string. While the repository does not have any matching tags, v0.0 will
be assumed, resulting in versions with both major and minor being set to
'0', and the patch count resulting from the number of patches in the
history to that point.
Finally, a uniquely identifying shortened hash is provided from git:
v0.0.509+0ec0edf7
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
libcamera depends on libudev for device enumeration. It is however
useful to allow building documentation without requiring the dependency
to be installed. Make the libudev dependency optional and compile the
udev-based device enumerator out when libudev is not present.
Note that while libcamera will compile without libudev, it will not be
able to enumerate devices. A sysfs-based device enumerator is planned as
a fallback but not implemented yet.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Some \todo comments are outdated and refer to tasks that have been
completed. Remove them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Include the header file corresponding to the source file in the very
first position. This complies with the Google C++ coding style
guideliens, and helps ensuring that the headers are self-contained.
Three bugs are already caught by this change (missing includes or
forward declarations) in device_enumerator.h, event_dispatcher_poll.h
and pipeline_handler.h. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The documentation style for the Doxygen comment blocks is inconsistent
in the library. Document the expectations and update all existing
comment blocks to match.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Rapid growth of the library have resulted in slightly different wording
to document that a function returns 0 on success or a negative error
code otherwise. Align all different variations.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The new removeCamera() method is meant to be used by pipeline handlers
to unregister a camera in case of device disconnection.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
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>
|
|
There is no need for pipeline_handler.h to include camera.h, instead it
should be included in the source file which needs it;
camera_manager.cpp.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
In the case that someone calls CameraManager::start() and it has already
started/enumerated, instead of returning -ENODEV, return -EBUSY.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Use log categories in the whole existing code base.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
The CameraManager takes ownership of the dispatcher passed to the
setEventDispatcher() function. Enforces this by using std::unique_ptr<>.
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>
|
|
Convey the fact that the CameraManager class owns the DeviceEnumerator
instance it creates by using std::unique_ptr<> to store the pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The PipelineHandlerFactory::handlers() static method returns a list of
factories, not a list of handlers. Rename it accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Move documentation from the \file directive to the CameraManager class,
as it documents the class, not the file. Improve the documentation to
provide a brief overview of how the camera manager operates, and fix a
few typos and inconsistencies.
The documentation mentions hotplug even though it isn't implement yet,
as this is a planned feature. More improvements are needed for the
documentation of the CameraManager member functions, and will be added
as part of the API improvements in the near future.
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>
|
|
Pipeline handler factories are register in a map indexed by their name,
and the list of names is used to expose the factories and look them up.
This is unnecessary cumbersome, we can instead store factories in a
vector and expose it directly. The pipeline factory users will still
have access to the factory names through the factory name() function.
The PipelineHandlerFactory::create() method becomes so simple that it
can be inlined in its single caller, removing the unneeded usage of the
DeviceEnumerator in the factory.
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>
|
|
Provide a poll-based event dispatcher implementation as convenience for
applications that don't need a custom event loop. The poll-based
dispatcher is automatically instantiated if the application doesn't
provide its own dispatcher.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
