Provide a call allowing requests to be registered and associated with
the pipeline handler after being constructed by the camera.
This provides an opportunity for the PipelineHandler to connect any
signals it may be interested in receiving for the request such as
getting notifications when the request is ready for processing when
using a fence.
While here, update the existing usage of the d pointer in
Camera::createRequest() to match the style of other functions.
Bug: https://github.com/raspberrypi/libcamera-apps/issues/217
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Support easier usage of the v4l2 compatibility layer with a script that
handles the LD_PRELOAD for applications.
The wrapper can be prefixed to launch any application with the preload
set:
$ libcamera-v4l2 v4l2-ctl --list-devices
\_SB_.PCI0.GP13.XHC0.RHUB.PRT4- (libcamera:0):
/dev/video0
platform/vimc.0 Sensor B (libcamera:1):
/dev/video2
/dev/video3
/dev/video4
Specifying '-d' once before the command to run will enable V4L2Compat
layer debug output from libcamera.
Specifying '-d' twice will enable all debug levels from all libcamera
components and provide a very detailed log for analysis.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Currently, a subproject is used to fetch gtest dependency unconditionally
for any Linux distribution besides ChromeOS. But it leads to a regression
in distros whose builders are not allowed to download files during build.
This change was introduced by commit 0d50a04cc9 ("lc-compliance: Build
with gtest in subprojects") and the rationale is that some distros, such
as Debian ship libgtest-dev as a static library. And this could be built
with a different toolchain than the one used to build libcamera itself.
But this seems to be a corner case, usually users will either build both
libcamera and all its dependencies using the same toolchain or build it
using both the libgtest library and toolchain as provided by the distro.
If someone doesn't want for meson to pick up the non-compatible static
library provided by the distro, then instead should make sure that their
build root does not have the package providing this installed.
Let's simplify the logic to find the dependency and just use the built-in
support in dependency() function to fallback to a subproject if not found.
This covers to common case of attempting to use the gtest provided by the
system or pulling from source if not found or is not preferred.
To force meson to fallback to the wrap for gtest you can use this command:
meson configure -Dforce_fallback_for=gtest
and to force fallback for all the dependencies, you can use the following:
meson build --wrap-mode=forcefallback
Fixes: commit 0d50a04cc9 ("lc-compliance: Build with gtest in subprojects")
Reported-by: Eric Curtin <ecurtin@redhat.com>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Increase the maximum allowable gain from 6.0 to 8.0 in the normal and short
exposure profiles for all camera sensors. Increase this limit to 12.0 for the
long exposure profiles for sensors where this has been defined.
The 6.0x value was somewhat arbitrarily chosen, and does limit the total
exposure in dark conditions.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Limit the gain code to the maximum value reported by the sensor controls
when sending to DelayedControls. The AGC algorithm will handle a lower
gain used by the sensor, provided it knows the actual gain used. This
change ensures that DelayedControls will never report an unclipped gain
used.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
V4L2 is happy to map buffers read-only for capture devices (but rejects
write-only mappings). We can support this as the dmabuf mmap()
implementation supports it. This change fixes usage of the V4L2
compatibility layer with OpenCV.
While at it, attempt to validate the other flags. videobuf2 requires
MAP_SHARED and doesn't check other flags, so mimic the same behaviour.
While unlikly, other flags could get rejected by other kernel layers for
V4L2 buffers but not for dmabuf. This can be handled later if the need
arises.
Reported-by: Nejc Galof <galof.nejc@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Nejc Galof <galof.nejc@gmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
It's to fix build errors with mojom in ChromeOS chroot. The reason is that
ChromeOS recently moves native mojom generators module into site-packages,
which has higher import precedence than the local namespace package and shadows
the local package of the same. Add __init__.py to make it an explicit package
to avoid shadowing.
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul ELder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add support for PREPARE_BUF as one of the ioctl. Since this is a compat
layer, there doesn't seem to be an equivalent to the "transfer ownership
of the buffer to kernel driver" in V4L2Camera class. Thus, simply
duplicate the checks done by vidioc_qbuf.
To match the error checks done by kernel implementation, we'd have to
check if dmabuf fd is valid and that the buffer size is large enough.
Doing so will not add any particular value to the program as
applications most likely don't depend on these conditions being
handled correctly.
Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The fence and mapped-buffer tests both use the VIMC test device and must
not be run at the same time.
Split these tests to a new group to force their isolation from running
in parallel.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The libcamerasrc gstreamer component does seem to not allow stream resolutions
that are not advertised by PipelineHandler::generateConfiguration(). This has
been raised in a bug report [1].
Fix this behavior by advertising a SizeRange from the minimum ISP resolution, up
to the sensor resolution from PipelineHandlerRPi::generateConfiguration().
[1] https://bugs.libcamera.org/show_bug.cgi?id=105
Fixes: f16acb275c ("pipeline: raspberrypi: Restrict the advertised maximum ISP output resolution")
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Now that the sensor is defined to list mbus codes using its native
(untransformed) Bayer order, the method of obtaining it can be
simplified. We don't have to try and reset the flips, we just use the
value directly from the sensor.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
We clear the V4L2_CID_HFLIP and V4L2_CID_VFLIP controls immediately
after opening the camera device. This means the camera's Bayer format
and mbus codes will be in the sensor's "native" order, and we document
this to be the case so that it can be relied upon.
Clearing the flips is harmless where sensor flips do not affect the
Bayer order.
This also fixes a bug in the Raspberry Pi pipeline handler where the
native Bayer order was being computed wrongly, but the new behaviour
here will be helpful to other pipeline handlers too. A subsequent
commit will tidy up the Raspberry Pi pipeline handler in this area as
it can now be simplified.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Fixes: 83a5128161 (pipeline: raspberrypi: Convert the pipeline handler to use media controller)
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Debug messages in V4L2CameraProxy print the numerical file descriptor,
which isn't very human-friendly. Replace it with the V4L2CameraFile
description that includes the full path. While at it, refactor the
messages to use __func__ instead of manually copying function names.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The mmaps_ map stores a pointer to the V4L2CameraProxy to avoid
increasing the reference count on the V4L2CameraFile shared pointer
needlessly. While this provides a small optimization, it prevents
accessing the V4L2CameraFile from the munmap() function which doesn't
take an fd as argument.
To prepare for improved debugging that will require access to
V4L2CameraFile in munmap(), store the V4L2CameraFile pointer in mmaps_.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The V4L2 compat layer prints debug messages that mention the file
descriptor of the video device, but no message that links the device
path to the file descriptor. Fix it by adding a debug message in
openat().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The V4L2 compatibility layer doesn't support any of the VIDIOC_REQBUFS
flags. They are all correctly ignored, but also need to be zeroed
before returning to indicate that they haven't been taken into account.
This fixes a v4l2-compliance failure:
Buffer ioctls (Input 0):
fail: ../../utils/v4l2-compliance/v4l2-test-buffers.cpp(682): coherent
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL
Fixes: aa45336399 ("include: linux: Update kernel headers to version v5.16-rc7")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
If the sensor exposes the V4L2_CID_NOTIFY_GAINS control, assume it
means the sensor wants to be told the latest colour gains.
We store whether the control exists and if so its default value, to
save us checking for it on every frame.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This change will allow the pipeline handler to enumerate and control Video
Mux or Bridge devices that may be attached between sensors and a particular
Unicam instance. Cascaded mux or bridge devices are also handled.
A new member function RPiCameraData::enumerateVideoDevices(), called from
PipelineHandlerRPi::registerCamera(), is used to identify and open all mux and
bridge subdevices present in the sensor -> Unicam link.
Relevant links are enabled/disabled and pad formats correctly set in
PipelineHandlerRPi::configure() before the camera is started.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Enumerate the sensor device entities in PipelineHandlerRPi::match() and loop
over PipelineHandlerRPi::registerCamera() for each sensor found. This will
allow the pipeline handler to register multiple cameras attached to a single
Unicam instance with a Video Mux device.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Building the libcamera Android layer currently makes use of features
from meson 0.55. The core libcamera framework in the default configuration
without android enabled uses the 'summary' feature available in 0.53, and
is the lowest supportable meson version if the Android HAL is excluded.
Ubuntu 20.04 LTS currently provides meson 0.53 and represents an
acceptable minimum version to support. Platforms utilising the Android
component will have full control over their build environment and can
ensure that they provide a more recent version of meson.
Reduce the supported meson version for the project to 0.53 to facilitate
building on more distributions without having to manually update the
meson package.
Meson will output a warning that features not available in 0.53 are used
if the Android HAL is enabled. This is considered as an acceptable
middleground to improve the experience on the latest Ubuntu LTS, until
22.04 LTS is released and provides a newer meson version.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
[Kieran: Add comment about the android meson requirements]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The MediaDevice lock is meant to prevent concurrent usage of multiple
cameras from the same pipeline handlers. As media devices are acquired
by pipeline handlers, we can't have multiple pipeline handlers trying to
lock the same media device. The recursive locking detection can thus be
moved to the pipeline handler. This simplifies the media device
implementation that now implements true lock semantics, and prepares for
support of concurrent camera usage.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The intel-ipu3.h header has moved in the v5.14 kernel. Update the kernel
headers update script accordingly.
While at it, add a missing directory separator to fix a failure when the
path to the kernel tree doesn't end with a /.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The type of elements of the capability vector that is set in the static
metadata must be uint8_t. The enum will not suffice, as it is int32_t.
Fix this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add setEntry() helper, that automatically detects if updateEntry() or
addEntry() should be used.
Note that updateEntry() will fail if the entry was not yet added, and
addEntry() will fail is the entry was already added. They are silent
failures that cause unexpected values to find their way into the android
metadata instance.
Previously this helper was not necessary, as (with respect to the
current use case) the preview template generator would always add a key
so the other template generators that used the preview template as
boilerplate could reliably use updateEntry(). The preview template
generator will soon decide based on capabilities whether or not to add
keys, so the other template generators need a helper to decide whether
to use updateEntry() or addEntry().
For now only implement it for enums and arithmetic values, as they will
mainly be used in populating templates.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
A libcamera camera that supports the manual sensor capability also
satisfies all the requirements for the read sensor settings capability.
Set it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Print messages when some feature is missing that causes hardware level
FULL to not be supported.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The gen-tp-header script does not have execute permissions set on the
file.
Add the execute permission to ensure that meson runs this script
consistently in the same configuration as other scripts, without
invoking python itself separately.
Signed-off-by: Brian Olson <icic@bolson.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The build/ and patches/ directories are listed in .gitignore as they're
commonly used respectively as the meson build directory (this is the
directory name used in README.rst) and as a local patches store (this
usage pattern isn't official though, and may need to be reconsidered if
not used anymore). As those two directories are supposed to be at the
root of the source tree, restrict the corresponding .gitignore patterns
to avoid matching other locations.
While at it, sort the entries alphabetically, with the absolute path
entries separate from the entries that match any location within the
source tree.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The unit test associates a fence with a framebuffer and makes sure
the fence is correctly signalled.
Once a fence is correctly signalled, it is released by the core, and the
underlying file descriptor closed.
The unit test however tries to write on the fence file descriptor every
time the designated Request is queued, an error which is now visible
as the return value of the fence signalling write() is checked.
Fix that by associating a fence with a framebuffer only once.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The ::write() function used to signal a framebuffer fence in the unit
test is marked with the 'warn_unused_result'.
When building in debugoptimized mode not checking for the return
value causes issues at build time:
/test/fence.cpp:254:2: error: ignoring return value of function declared with 'warn_unused_result' attribute
Fix that by checking the ::write() return value and emitting an
error message in case the write fails.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reported-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The Raspberry Pi pipeline handler now sets color spaces correctly.
In generateConfiguration() it sets them to reasonable default values
based on the stream role.
validate() now calls validateColorSpaces() to ensure that the
requested color spaces are sensible, before proceeding to check what
the hardware can deliver.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
