e34d3a4f27
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. Inf3695e9b09("libcamera: camera_manager: Register cameras with the camera manager"), cameras started to get registered directly with camera manager and in5b02e03199("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>
.. SPDX-License-Identifier: CC-BY-SA-4.0
.. section-begin-libcamera
===========
libcamera
===========
**A complex camera support library for Linux, Android, and ChromeOS**
Cameras are complex devices that need heavy hardware image processing
operations. Control of the processing is based on advanced algorithms that must
run on a programmable processor. This has traditionally been implemented in a
dedicated MCU in the camera, but in embedded devices algorithms have been moved
to the main CPU to save cost. Blurring the boundary between camera devices and
Linux often left the user with no other option than a vendor-specific
closed-source solution.
To address this problem the Linux media community has very recently started
collaboration with the industry to develop a camera stack that will be
open-source-friendly while still protecting vendor core IP. libcamera was born
out of that collaboration and will offer modern camera support to Linux-based
systems, including traditional Linux distributions, ChromeOS and Android.
.. section-end-libcamera
.. section-begin-getting-started
Getting Started
---------------
To fetch the sources, build and install:
::
git clone git://linuxtv.org/libcamera.git
cd libcamera
meson build
ninja -C build install
Dependencies
~~~~~~~~~~~~
The following Debian/Ubuntu packages are required for building libcamera.
Other distributions may have differing package names:
A C++ toolchain: [required]
Either {g++, clang}
for libcamera: [required]
meson (>= 0.47) ninja-build python3-yaml
If your distribution doesn't provide a recent enough version of meson,
you can install or upgrade it using pip3.
.. code::
pip3 install --user meson
pip3 install --user --upgrade meson
for device hotplug enumeration: [optional]
pkg-config libudev-dev
for documentation: [optional]
python3-sphinx doxygen
for gstreamer: [optional]
libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
for IPA module signing: [required]
libgnutls28-dev openssl
for qcam: [optional]
qtbase5-dev libqt5core5a libqt5gui5 libqt5widgets5
Using GStreamer plugin
~~~~~~~~~~~~~~~~~~~~~~
To use GStreamer plugin from source tree, set the following environment so that
GStreamer can find it.
export GST_PLUGIN_PATH=$(pwd)/build/src/gstreamer
The debugging tool `gst-launch-1.0` can be used to construct and pipeline and test
it. The following pipeline will stream from the camera named "Camera 1" onto the
default video display element on your system.
.. code::
gst-launch-1.0 libcamerasrc camera-name="Camera 1" ! videoconvert ! autovideosink
.. section-end-getting-started