| Age | Commit message (Collapse) | Author |
|---|
|
Allow manually setting auto focus window. Currently only one window is
enabled, but ISP allows up to three of them.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Add the OV5675 tuning file with default values and enabled AF algorithm.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Pass the controls set by top level API to the AF algorithm if it
was enabled.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
This function allows to get pointer to the algorithm of specific type
from the list of loaded algorithms.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
This will expose the AF controls and will allow controlling them using
the top level API.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Rockchip ISP AF block allows calculation of sharpness and luminance
in up to three user defined windows. If no windows are set, there are
some default settings applied for the first window and exposed through
the driver. For each frame, use the sharpness value calculated for this
default window and feed the hill climbing algorithm with them. Then set
the lens position to value calculated by the algorithm.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Move the code that was common for IPU3 and RPi AF algorithms to
a separate class independent of platform specific code.
This way each platform can just implement contrast calculation and
run the AF control loop basing on this class.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Define common interface with basic functions that should be supported
by Auto Focus algorithms.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Check if lens are available and have ability to control the focus.
Connect IPA setLensControls() signal to the pipeline slot that controls
the lens. If lens are valid, allow changing the focus from IPA by
emitting signal to the pipeline.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
As additional controls will be added to the IPA (like lens), we want to
have more specific names for each ControlInfoMap.
Signed-off-by: Daniel Semkowicz <dse@thaumatec.com>
|
|
Control lens focus from rkisp1 pipeline, using CameraLens controller
and expose lens controls to the IPA during configure().
Signed-off-by: Daniel Semkowicz <dse@thaumatec.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: 9dacde0d651d (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>
|
|
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
It's not safe to assume `-include config.h` works, since this depends on
the functionality of the compiler that the cwd when running the compiler
is searched first.
When libcamera is included as a Meson subproject, the cwd of the
compiler is the cwd of the main project, not of libcamera's build dir,
and thus cannot be found. Instead, pass the include filename as a path
based on the current build dir.
Signed-off-by: Eli Schwartz <eschwartz93@gmail.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 load_image function would throw errors with JPEG or JPG files containing
no raw data.
Prevent throwing these errors by returning 0 if an error has occurred.
Signed-off-by: William Vinnicombe <william.vinnicombe@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit 6f539a6d2fa9 ("delayed_controls: Remove reduandant firstSequence_")
removed support for frame number start offset from the DelayedControls
class, as it is now guaranteed that the first sequence number as it comes
from the V4L2VideoDevice will always be 0.
However the delayed_controls.cpp unit still has two tests that passes
a non-zero first sequence number to the DelayedControl class, causing
the test to spin forever and consequentially fail.
Remove the two tests from the unit to fix this.
The first removed test was testing the class against frame start
sequence numbers greater than zero and can safely be removed.
The second test was instead validating the class against sequence number
overflow, which is now not possible to test anymore as the DelayedControls
class now assumes 0 as first frame sequence number.
Fixes: 6f539a6d2fa9 ("delayed_controls: Remove reduandant firstSequence_")
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@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] 1c9dc0fd89cf ("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>
|
|
The task run function races with two other threads that want to resume
the task: the requestCompleted() handler and the buffer-notify signal
handler. If the former queues completed requests or the latter queues
back buffers to the pool, and then resume the task, after the task run
handler checks the queues but before it attemps to pause the task, then
the task may be paused without noticing that more work is available.
The most immediate way to fix this is to take the stream_lock in the
requestCompleted() and buffer-notify signal handlers, or cover the whole
task run handler with the GstLibcameraSrcState lock. This could cause
long delays in the requestCompleted() handler, so that's not a good
option.
Instead, pause the task unconditionally at the beginning of its run
function, and track while processing buffers and requests if the task
needs to be resumed. It may also get resumed externally by the
buffer-notify signal handler or the request completion handler, which
are guaranteed not to race due to the lock taken by the gst_task_pause()
and gst_task_resume() functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Simplify the task run function futher by moving the processing of
completed requests to a separate function. No functional change
intended, only increased readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
In order to prepare for creation and queuing of multiple requests, move
the request creation and queueing code to a separate function. No
functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The srcpads_ vector is protected by two different locks, the GstObject
lock of the libcamerasrc element, and the stream_lock that covers the
run function of the thread. This isn't correct. Use the stream_lock
consistently to protect the pads.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add a new lock to the GstLibcameraSrcState class to protect the queued
and completed requests queues. This replaces the GstObject lock, and
minimizes the lock contention between the request completion handler and
the task run handler as the former must run as fast as possible.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
This simplifies the code, and allows removing the internal queue in the
GstLibcameraPad object.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Move the request wrap to a completed queue in the request completion
handler to move more of the request completion processing to the
libcamerasrc task. This lowers the amount of time spent in the
completion handler, and prepares for reworking the usage of locks.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
To prepare for the addition of a completed requests queue, rename the
existing queued requests queue from requests_ to queuedRequests_.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The buffer pts and the pad latency are computed from the framebuffer
timestamp, separately for each pad. Use the sensor timestamp provided
through the request metadata instead, to compute the values once outside
of the pads loop.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
For symmetry with RequestWrap::removeBuffer(), pass the Stream pointer
to addBuffer(). This handles streams at the GstPad level instead of the
GstBuffer level, which allows making the GstLibcameraPool API a bit
cleaner by removing the gst_libcamera_buffer_get_stream() helper
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The GstBuffer variable in GstLibcameraSrcState::requestCompleted() is
only used within the loop scope. Make it a local loop variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The gst_libcamera_resume_task() helper is an implementation of the
gst_task_resume() function that predates its addition to GStreamer. Use
gst_task_resume() when available, and rename gst_libcamera_resume_task()
to gst_task_resume() to support older GStreamer versions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
|
|
To allow associating pointers with FrameBuffer instances, turn the
cookie into a 64-bit integer. This matches the Request cookie with is
also a uint64_t.
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>
|
|
Get the Black Level Correction algorithm parameters from YAML tuning
data.
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>
|
|
Add the OV5640 tuning file containing default values for 'black level
correction' algorithm.
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>
|
|
Add a skeleton for the IMX219 tuning file, with data for the BLC
algorithm.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Retrieve root node in YAML tuning file and provide to
each algorithm this YamlObject to allow them to grab their default
parameters by calling init() function.
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>
|
|
To prepare for dynamic instantiation of algorithms from the tuning file,
register the algorithms with the Module class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@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>
|
|
To help attribute messages logged by the Module class to a particular
IPA module, make the class loggable. The logPrefix() function must be
implemented by the IPA module-specific derived class.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Add a Module::createAlgorithms() function to instantiate algorithms from
a YamlObject. The instantiated algorithms are stored in a private member
variable list, exposed through the Module::algorithms() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Add the init() function that will be called during algorithm initialization
to provide each algorithm the list of algorithms tuning data.
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>
|
|
In order to allow dynamic instantiation of algorithms based on tuning
data files, add a mechanism to register algorithms with the IPA module.
The implementation relies on an AlgorithmFactory class and a
registration macro, similar to the pipeline handler registration
mechanism. The main difference is that the algorithm registration and
instantiation are implemented in the Module class instead of the
AlgorithmFactory class, making the factory an internal implementation
detail.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The libipa.cpp file exists for the sole purpose of documentating the ipa
namespace. As we now have a top-level module.cpp file in libipa, move
the documentation there, and drop libipa.cpp.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
libipa defines an abstract Algorithm class template that is specialized
by IPA modules. IPA modules then instantiate and manage algorithms
internally, without help from libipa. With ongoing work on tuning data
support for the RkISP1, and future similar work for the IPU3, more code
duplication for algorithms management is expected.
To address this and share code between multiple IPA modules, introduce a
new Module class template that will define and manage top-level concepts
for the IPA module.
The Module class template needs to be specialized with the same types as
the Algorithm class. To avoid manual specialization of both classes,
store the types in the Module class, and replace the template arguments
of the Algorithm class with a single Module argument from which the
other types are retrieved.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@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>
|
|
Switch the aperture, lens_position, and flash_intensity fields in the
DeviceStatus structure to use std::optional instead of using invalid default
values.
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>
|
|
Fetch the sensor temperature value from the embedded data buffer and add it to
the DeviceStatus structure in CamHelperImx477::PopulateMetadata().
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>
|
