| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Add three new classes, EventDispatcher, EventNotifier and Timer, that
define APIs for file descriptor event notification and timers. The
implementation of the EventDispatcher is meant to be provided to
libcamera by the application.
The event dispatcher is integrated twith the camera manager to implement
automatic registration of timers and events.
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>
|
|
There can only be a single camera manager instance in the application.
Creating it as a singleton helps avoiding mistakes. It also allows the
camera manager to be used as a storage of global data, such as the
future event dispatcher.
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>
|
|
Provide a CameraManager class which will handle listing, instancing,
destruction and lifetime management of cameras.
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>
|
