The allocation and freeing of buffers for the CIO2 is handled in the
IPU3 pipeline handlers start() and stop() functions. These functions
also call CIO2Device start() and stop() at the appropriate times so
move the CIO2 buffer allocation/freeing inside the CIO2Device and reduce
the complexity of the exposed interface.
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>
In order to make the CIO2 easier to extend with new features make the
V4L2 devices (sensor, CIO2 and video device) private members. This
requires a few helper functions to be added to allow for the IPU3 driver
to still be able to interact with all parts of the CIO2. These helper
functions will later be extended to add new features to the IPU3
pipeline.
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>
Collect the code used to generate configurations for the CIO2 block in
the CIO2Device class. This allows simplifying the code and allow further
changes to only happen at one code location.
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>
Instead of spreading the mapping between media bus codes and V4L2 FourCC
all over the CIO2 code collect it in a single map and extract the data
from it. This is done in preparation of adding PixelFormat information
to the mix.
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>
Decouple the number of buffers to allocate for the ImgU from the number
of buffers allocated for the CIO2. Instead of blindly following the CIO2
pick the maximum number of buffers requested for any stream facing
applications.
This is potentially wasteful, as each stream could allocate just as many
buffers as requested by the application instead of the maximum from the
set. But this is not more wasteful than what is already used by the
pipeline and should be fixed on top after the decoupling of the two
processing units.
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>
Selecting which stream is the most suitable for the requested
configuration is mixed with adjusting the requested format when
validating configurations. This is hard to read and got worse when
support for Bayer formats was added. Break it out to a separate
function.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The pipeline handler documentation incorrectly references an old API
usage of setCameraData, which should have been updated to
registerCamera() while updating pipeline handlers to ensure they all
have a pipeline-specific "CameraData" allocation.
Update the remaining documentation reference.
Fixes: b581b9576a ("libcamera: pipeline_handler: Make pipeline-specific data mandatory")
Signed-off-by: Chris Chinchilla <chris@gregariousmammal.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Print format names defined in formats namespace instead of the hex
values in toString() as they are easier to comprehend. For this add
a property of 'name' in PixelFormatInfo' so as to map the formats
with their names. Print fourcc for formats which are not used in
libcamera.
Signed-off-by: Kaaira Gupta <kgupta@es.iitr.ac.in>
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>
When replacing DRM FourCCs with libcamera formats IPU3 format
descriptors where missing resulting in RAW capture not being possible.
Fix this by adding the missing descriptors.
Fixes: 56c99424ed ("libcamera: pipeline: Replace explicit DRM FourCCs with libcamera formats")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The id in the camera name is confusing and is of little use for users.
Camera names are not (yet) required to be unique and appending which
numerical CIO2 unit the sensor is attached to is just as good as
depending on the i2c bus information already present in the entity name.
Before this change,
$ cam -l
Available cameras:
1: ov13858 2-0010 0
2: ov5670 4-0036 1
After this change,
$ cam -l
Available cameras:
1: ov13858 2-0010
2: ov5670 4-0036
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 two public unsigned integer fields of StreamConfiguration, stride
and bufferCount where not initialized, fix this to match other members
being initialized to their 'zero' state.
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>
Use the new pixel format constants to replace usage of macros from
drm_fourcc.h.
The IPU3 pipeline handler still uses DRM FourCCs for IPU3-specific
formats that are not defined in the libcamera public API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
libcamera uses pixel format FourCC and modifier values from DRM. This
requires inclusion of drm_fourcc.h, creating a dependency on a header
that is packaged differently between distributions, and causing possible
issues with third-party applications.
Define constants for the supported pixel formats in the new formats.h
public API header, in order to remove the dependency on drm_fourcc.h.
The header is generated by a Python script from a list of supported
formats. The numerical values for the FourCC and modifier are extracted
from drm_fourcc.h by the script, ensuring that numerical values are not
inadvertently modified and preserving the direct interoperability.
The pixel formats constants can't be generated solely from drm_fourcc.h,
as that header defines FourCC values and modifier values, but doesn't
list the valid combinations. The supported formats are thus stored in a
YAML file, which contains the FourCC and optional modifier for each
supported format. We may later extend the YAML file to include formats
documentation, and possibly formats metadata to populate the
pixelFormatInfo map (in formats.cpp) automatically.
Now that two formats.h header are present (one in include/libcamera/ and
one in include/libcamera/internal/), we need to explicitly qualify the
Doxygen \file directive with a path.
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>
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>
As the ELF parsing code uses non-const pointers to the ELF mapping, we
have to map the module in private read-write mode. This causes issues
with valgrind, due to the IPA manager mapping the module in shared
read-only mode and valgrind having trouble loading debugging symbols
later at dlopen time due to conflicting mappings.
This is likely a bug in valgrind (reported as [1]), but we can easily
work around it by using shared read-only mappings only. As such a
mapping shouldn't be less efficient than private read-write mappings,
switch the mapping type. This requires modifying the ELF parsing
functions to operate on const memory, which is a good idea anyway as
they're not supposed to modify the ELF file.
[1] https://bugs.kde.org/show_bug.cgi?id=422601
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The logic of the code guarantees that the PipelineHandler pointer passed
to the RkISP1Frames constructor is an instance of PipelineHandlerRkISP1.
We can thus use static_cast<> instead of dynamic_cast<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
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>
As the only usage of IPAManager::instance() is by the pipeline handlers
to call IPAManager::createIPA(), remove the former and make the latter
static. Update the pipeline handlers and 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>
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>
Given how the elfSection() function uses the sub-expression
(idx * eHdr->e_shentsize)
it has effectively two (16 bits, unsigned) operands.
The sub-expression is promoted to type int (32 bits, signed) for
multiplication and then added to eHdr->e_shoff, which is uint32_t on
32-bit platforms and uint64_t on 64-bit platforms. Since eHdr->e_shoff
is unsigned, the integer conversion rules dictate that the other signed
operand (i.e. the result of aforementioned sub-expression) will be
converted to unsigned type too. This causes sign-extension for both of
the above operands to match eHdr->e_shoff's type and should be avoided.
The solution is to explicitly cast one of the operands of the
sub-expression with unsigned int type. Hence, the other operand will be
integer promoted and the resultant will also be of unsigned int type,
not requiring to bother about a sign-extension.
Reported-by: Coverity CID=280008
Reported-by: Coverity CID=280009
Reported-by: Coverity CID=280010
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 libcamera source files are named after class names, using
snake_case. pixelformats.h and pixelformats.cpp don't comply with that
rule. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The DRM(BGRA8888)/V4L2(ARGB8888) format is not supportable by the current
configurations of VIMC.
Remove it from the list of supported configurations.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Fail and return the Camera::configure() operation if any
of the stream turns out to be a nullptr even after the
PipelineHandler handler seems to have configured the config
successfully. This prevents a null-dereference below in the
loop.
Reported-by: Coverity CID=279069
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: Kieran Bingham <kieran.bingham@ideasonboard.com>
The reset function in staggered write was using the wrong index when
looking for the last updated camera parameters. This would cause
possibly stale exposure values to be written to the camera on a
mode switch for captures.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We don't use full stops at the end of \return directives in Doxygen
documentation. Drop it.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Extend the SimpleConverter to support scaling, with reporting of the
minimum and maximum output sizes supported for a given input size.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Report the stride when configuring the camera. The stride is retrieved
from the capture device first, and overridden by the converter if used.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The RPiCameraData class destructor tries to stop its ipa_ instance
without making sure it has been initialized.
If the RPiCameraData gets destroyed before its ipa_ member is
initialized, for example if the sensor initialization fails during the
match() function, a nullptr dereference segfault is triggered preventing
a graceful library teardown.
Fix this by checking for ipa_ to be initialized before stopping it.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
