Now that V4L2PixelFormat::fromPixelFormat() returns a list of formats
to chose from, select the one supported by the video device by matching
against the list of supported pixel formats.
The first format found to match one of the device supported ones is
returned.
As the list of pixel formats supported by the video device does not
change at run-time, cache it at device open() time. Maximize the
lookup efficiency by storing the list of supported V4L2PixelFormat in an
std::unordered_set<>.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Multiple V4L2 formats can be associated with a single PixelFormat.
Now that users of V4L2PixelFormat::fromPixelFormat() have been converted
to use V4L2VideoDevice::toV4L2PixelFormat(), return the full list of
V4L2 formats in order to prepare to match them against the ones
supported by the video device.
The V4L2 compatibility layer, not having any video device to interact
with, is converted to use the first returned format unconditionally.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
This is a partial revert of commit 395d43d6d7 ("libcamera:
v4l2_videodevice: Drop toV4L2PixelFormat()")
The function was removed because it incorrectly maps non-contiguous V4L2
format variants (ie V4L2_PIX_FMT_YUV420M) to the API version supported
by the video device (singleplanar API and multiplanar API). It was
decided at the time to remove the function and let its users call
directly V4L2PixelFormat::fromPixelFormat() which accepts a
'multiplanar' flags.
As we aim to associate multiple V4L2PixelFormat to a single libcamera
format, the next patches will verify which of them is actually supported
by the video device. For now, return the contiguous version
unconditionally.
Re-introduce V4L2VideoDevice::toV4L2PixelFormat() and convert all
the V4L2PixelFormat::fromPixelFormat() users to use it.
The V4L2 compatibility layer is the only outlier as it doesn't have a
video device to poke, hence it still uses
V4L2PixelFormat::fromPixelFormat().
Next patches will implement the device format matching logic and handle
the non-contiguous plane issue in V4L2VideoDevice::toV4L2PixelFormat().
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
To each libcamera PixelFormat two V4L2 formats are associated, the
'single' and 'multi' format variants.
The two versions list plane contiguous and non-contiguous format
variants, and an optional argument to V4L2PixelFormat::fromPixelFormat()
was used to select which one to pick.
In order to prepare to remove V4L2PixelFormat::fromPixelFormat(), and
considering that no caller in the codebase uses the non-contiguous
format variant, merge the two formats vectors in a single one and
default the selection to the first available one, which is functionally
equivalent to what is currently implemented.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
The PixelFormatInfo::info(const V4L2PixelFormat &format) function
returns the PixelFormatInfo associated with a V4L2 pixel format.
As the pixelFormatInfo map is indexed using PixelFormat and a V4L2
format can easily be converted to a PixelFormat, simply return
the info() function overload instead of maintaining two similar
implementations of the same function.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Denoise and Sharpness filters will be applied by RkISP1 during the
demosaicing step. The denoise filter is responsible for removing noise
from the image, while the sharpness filter will enhance its acutance.
Add filter algorithm with denoise and sharpness values based on user
controls.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The std::optional<T>::value_or(U &&default_value) function returns the
contained value if available, or default_value if the std::optional has
no value. If the desired default value is a default-constructed T, the
obvious option is to call std::optional<T>::value_or(T{}). This approach
has two drawbacks:
- The \a default_value T{} is constructed even if the std::optional
instance has a value, which impacts efficiency.
- The T{} default constructor needs to be spelled out explicitly in the
value_or() call, leading to long lines if the type is complex.
Introduce a defopt variable that solves these issues by providing a
value that can be passed to std::optional<T>::value_or() and get
implicitly converted to a default-constructed T.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The std::map container used to store dictionary items in YamlObject
doesn't preserve the YAML data order, as maps are ordered by key, not by
insertion order. While this is compliant with the YAML specification
which doesn't guarantee ordering of mappings, the Raspberry Pi IPA
relies on elements being ordered as in the YAML data. To replace the
dependency on boost with the YamlParser class, we thus need to guarantee
that the order is preserved.
Preserve the order by storing items in list_ unconditionally. Turn the
list_ vector from storing YamlObject unique pointers to storing
key-value pairs, with the key being absent when the object is a list,
not a dictionary.
The YamlObject implementation is updated to preserve the existing API,
with the only difference being that YamlObject::memberNames() now
returns member names in the same order as in the YAML file.
The ordering is an implementation detail, so changing it doesn't violate
the YAML specification. The documentation is not updated to reflect
this, as we don't want any new user to rely on a particular ordering.
This commit could be reverted if desired when the Raspberry Pi IPA
updates to a new tuning data format and drops support for the old
format.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
The YamlObject::get() function takes a default value and an optional
bool ok flag to handle parsing errors. This ad-hoc mechanism complicates
error handling in callers.
A better API is possible by dropping the default value and ok flag and
returning an std::optional. Not only does it simplify the calls, it also
lets callers handle errors through the standard std::optional class
instead of the current ad-hoc mechanism.
Provide a get() wrapper around std::optional::value_or() to further
simplify callers that don't need any specific error handling.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The logic used to match asynchronous image and embedded buffers was being overly
aggressive by possibly allowing an unmatched image buffer to be sent to the IPA
if the matching embedded buffer had not yet been dequeued. This condition only
occurs when the system is heavily loaded and dropping frames.
Fix this by holding image buffer in the queue during these conditions until the
next embedded buffer dequeue event.
Reported-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Tested-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The ControlList::contains(const ControlId &id) function isn't used, as
it has been replaced by usage of the get() function. Document get as
being the preferred way to check for the presence of a control in a
ControlList, and drop the contains() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The ControlList::get(const Control<T> &ctrl) function has been modified
in commit 1c4d480185 ("libcamera: controls: Use std::optional to
handle invalid control values") to return an std::optional<>, but its
documentation wasn't updated. Fix it.
Fixes: 1c4d480185 ("libcamera: controls: Use std::optional to handle invalid control values")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The doxygen document blocks of various ControlList function qualify
functions with full template and return type specification. This isn't
needed, and the extra verbosity makes the documentation blocks more
difficult to read. Drop the template qualifiers and return types. The
generated documentation is not affected.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Some hardware supported by the rkisp1 driver, such as the ISP in the
i.MX8MP, don't have a self path. Although at the moment the driver still
exposes the self path, prepare the rkisp1 pipeline handler for when the
self path will be removed for devices that don't support it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Now that the ControlList::get() function returns an instance of
std::optional<>, we can replace the ControlList::contains() calls with a
nullopt check on the return value of get(). This avoids double lookups
of controls through the code base.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Previously, ControlList::get<T>() would use default constructed objects to
indicate that a ControlList does not have the requested Control. This has
several disadvantages: 1) It requires types to be default constructible,
2) it does not differentiate between a default constructed object and an
object that happens to have the same state as a default constructed object.
std::optional<T> additionally stores the information if the object is valid
or not, and therefore is more expressive than a default constructed object.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
If the pixel format gets adjusted to the default NV12 format during
validation, it gets currently ignored and the user-supplied format is
used nonetheless.
Fix it by using the adjusted pixel format.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The controls::ScalerCrop in the ControlInfoMap was advertised based on
the ISP output Rectangle. This is incorrect, it needs to be set based on
the sensor analogue crop Rectangle. Fix this.
Additionally, do not use emplace to be consistent with the other
controls set in the ControlInfoMap.
Fixes: 9dacde0d65 (pipeline: raspberrypi: Advertise ScalerCrop from the pipeline handler)
Reported-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The rkisp1 hardware supports both a CSI-2 input and a parallel input,
where the sensor is connected directly to the ISP. On RK3399, the CSI-2
receiver is internal, but on the i.MX8MP, the CSI-2 receiver is a
separate IP core, connected to the parallel input of the ISP, and gets
exposed to userspace as a V4L2 subdev. To prepare for this, handle an
optional CSI-2 receiver subdev in the pipeline.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Compiling backtrace.cpp for ARM32 produces the following error with the
clang-11 (and later) compiler:
--------------------
../src/libcamera/base/backtrace.cpp:195:12: error: use of SP or PC in the list is deprecated [-Werror,-Winline-asm]
int ret = unw_getcontext(&uc);
^
/usr/include/arm-linux-gnueabihf/libunwind-common.h:114:29: note: expanded from macro 'unw_getcontext'
^
/usr/include/arm-linux-gnueabihf/libunwind-arm.h:270:5: note: expanded from macro 'unw_tdep_getcontext'
"stmia %[base], {r0-r15}" \
^
<inline asm>:1:2: note: instantiated into assembly here
stmia r0, {r0-r15}
--------------------
Suppress this compilation error with a clang-specific pragma around the
offending statements.
Further information about this error can be found at
https://github.com/dotnet/runtime/issues/38652
Bug: https://bugs.libcamera.org/show_bug.cgi?id=136
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@rasbperrypi.com>
Tested-by: Naushir Patuck <naush@rasbperrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
We now have V4L2VideoDevice ensuring that sensor sequence numbers
start from zero [1], and we desire that these should match the Request
sequence number as well.
[1] 1c9dc0fd89 ("libcamera: v4l2_videodevice: Identify non-zero stream starts")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The DelayedControls implementation tracked the sequence numbers to
determine the offset if a device did not commence with a sequence number
of 0.
This guarantee is now handled by the V4L2VideoDevice.
Remove the firstSequence_ offset and the corresponding running_ flag
which was used to track setting firstSequence_ from the DelayedControls.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Pass the path name of the YAML IPA tuning file to the IPA module. The
file name is derived from the sensor name ("${sensor_name}.yaml"), with
a fallback to "uncalibrated.yaml".
The tuning file name can be manually overridden with the
LIBCAMERA_RKISP1_TUNING_FILE environment variable.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.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 ScalerCrop control is handled directly by the pipeline handler. Remove the
control from the IPA's static ControlInfoMap, and let the pipeline handler add
it to the ControlInfoMap advertised to the application, ensuring the limits
are set appropriately based on the current sensor mode.
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>
The ipa currently advertises a static ControlInfoMap to specify the available
controls and their limits. Fix this limitation by having the IPA populate a new
ControlInfoMap with updated limits for ExposureTime, AnalogueGain, and
FrameDurationLimits controls based on the current sensor mode. This new
ControlInfoMap is then returned back to the pipeline handler and available to
the application after a successful Camera::configure() call.
Before the first call to Camera::configure(), this ControlInfoMap provides some
reasonable default limits for ExposureTime, AnalogueGain, and
FrameDurationLimits. However, applications must not rely on these values, but
obtain the correct limits after the call to Camera::configure().
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>
Currently the pipeline handler advertises controls handled by the IPA from a
static ControlInfoMap defined in the raspberrypi.h header. This change removes
this header file, and instead the IPA returns the ControlInfoMap to the pipeline
handler from the ipa::init() function. This is done to allow the IPA to adjust
the limits of the controls based on the sensor mode in a subsequent change.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=83
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>
Now that YamlObject supports iteration, the memberNames() function isn't
useful anymore as it can be implemented using utils::map_keys() if
really needed. Drop it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
Allow using range-based for loops over YamlObject instances by
implementing iterators. New YamlObject::DictAdapter and
YamlObject::ListAdapter adapter classes are introduced to provide
different iterators depending on the object type.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
As the simple pipeline handler targets simple pipelines on the SoC side,
it often gets used with platforms that have a YUV sensor capable of
outputting different sizes. Extend the heuristics used for pipeline
discovery and configuration to scale as much as possible on the sensor
side, in order to minimize the required bandwidth.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When enumerating the supported configurations, store the corresponding
sensor resolution in the SimpleCameraData::Configuration structure and
use it when configuring the camera, instead of hardcoding the sensor
full resolution. This prepares for support of downscaling in the camera
sensor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
THe FILE object isn't very user-friendly as it requires manual close.
Replace it with File to provide RAII-style resource management in the
YamlParser API.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Turn the Type enum into an enum class to force qualifying 'List' and
'Dictionary' in the YamlObject namespace scope. This will help avoiding
ambiguities when adding iterator support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Extend the logger to support coloring messages. The log level is
colorized with per-level colors, and the category with a fixed color.
This makes the log output more readable.
Coloring is enabled by default when logging to std::cerr, and can be
disabled by setting the LIBCAMERA_LOG_NO_COLOR environment variable.
When logging to a file with LIBCAMERA_LOG_FILE, coloring is disabled. It
can be enabled for file logging using the logSetFile() function.
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>
If a sensor driver does not support test patterns (e.g. IMX477),
libcamera throws an unnecessary error message during initialisation when
it sets the test pattern to off.
Fix this by moving the error message into setTestPatternMode() where the
pipeline handler explicitly requests to set a test pattern.
Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
