The original updateControls() has the assumption that ctrls and
v4l2Ctrls lists are in the same order. It is dependent on the
caller implementation though. This changes updateControls()
implementation so that it works without the assumption.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
CameraSensorInfo structure is designed to pass in camera sensor related
information from pipeline-handler to IPA. Since the pipeline-handler
and IPA are connected via mojom IPC IPA interface, the interface
itself provides a more suitable placement of CameraSensorInfo,
instead of camera_sensor.h (which is a libcamera internal header
ultimately, at this point).
As CameraSensorInfo is already defined in core.mojom, it is just
a matter of removing [skipHeader] tag to allow code-generation
of CameraSensorInfo.
Finally, update header paths to include CameraSensorInfo definition
from IPA interfaces instead of "libcamera/internal/camera_sensor.h".
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.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>
Moving the core.mojom documentation to its corresponding .cpp file
(core_ipa_interface.cpp). This will allow Doxygen to generate the
documentation for IPABuffer, IPASettings and IPAStream structures.
Since the .mojom files are placed in include/ directory, the .cpp file
will live in $sourcedir/src/libcamera/ipa/ - which can also contain
documentation for other mojom generated IPA interfaces in subsequent
commit.
Also hide the constructors in generated IPA interface from doxygen,
via #ifndef __DOXYGEN__. These constructors provide no major value in
documenting them, instead will spew out doxygen warnings during the
build.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@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>
The asynchronous signal delivery mechanism can't be used by application,
as it requires libcamera to be aware of the application event loop,
which has been dropped a long time ago. Drop the corresponding
documentation paragraph.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
V4L2ControlId and V4L2ControlInfo are just convenience classes to
create ControlId and ControlInfo from v4l2_query_ext_control.
Therefore, there is no need of being a class. It is used only
from V4L2Device. This removes the classes and put the equivalent
functions of creating ControlId and ControlInfo in
v4l2_device.cpp.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
IPU3CameraData stores requests that have been failed due to a
buffer shortage. The requests should be retried once enough
buffers are available. This sets the retry function as signal to
CIO2Device and IPU3Frame, and invokes it from
CIO2Device::tryReturnBuffer() and IPU3Frame::remove().
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
PipelineHandlerIPU3 returns -ENOBUFS and -ENOMEM on queueing a
request when there are not sufficient buffers for the request.
Since the request will be successful if it is queued later when
enough buffers are available. The requests failed due to a buffer
shortage should be stored and retried later in the FIFO order.
This introduces the queue in IPU3CameraData to do that.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The LOG() macro uses the global Logger and LogCategory objects
internally. This can result in crashes or other undefined behaviour when
logging from destructors of global objects, as the Logger and/or the
LogCategory instances may have been destroyed.
This isn't ideal and should eventually be fixed. For the time being,
document the restriction, and add a todo list item to fix the problem.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Update the revision of the ImgU Python configuration tool the
libcamera implementation is based on to commit 243d134
("Fix some bug for some resolutions").
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org
The IF rectangle height is iteratively computed by first subtracting
the scaling factor to the estimated height, then in a successive loop
by adding the same scaling factor until the maximum IF size is not
reached.
As the computed IF height is not cached in any variable, the second
loop over-writes the result of the first one, even if the BDS alignment
condition is not satisfied.
Fix this by caching the result of the two iterations, and use the one
that produced any result, with a preference for the one produced by the
second loop, as implemented in the reference python script.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
As reported in https://bugs.libcamera.org/show_bug.cgi?id=32
allowing resolutions < IF_CROP_MAX leads to a not manageable number
configurations to be tested, slowing down the ImgU pipe configuration
to a point which is not acceptable for production devices.
Filter all resolutions < IF_CROP_MAX to maintain the run-time complexity
acceptable and remove the safety check that was meant to avoid overflows
when computing the IF rectangle sizes.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=32
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Range-based for loops are handy and widely preferred in C++, but are
limited in their ability to replace for loops that require access to a
loop counter. The enumerate() function solves this problem by wrapping
the iterable in an adapter that, when used as a range-expression, will
provide iterators whose value_type is a pair of index and value
reference.
The iterable must support std::begin() and std::end(). This includes all
containers provided by the standard C++ library, as well as C-style
arrays.
A typical usage pattern would use structured binding to store the index
and value in two separate variables:
std::vector<int> values = ...;
for (auto [index, value] : utils::enumerate(values)) {
...
}
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
With the recent change to merge existing Request metadata with the
ControlList provided by the IPA in commit fcfb1dc02a ("libcamera:
raspberry: Report sensor timestamp"), we can now write the
controls::ScalerCrop value at the start of the pipeline instead of at
the end.
This change simplifies the logic slightly, and allows us to write all
metadata items to the Request in one place.
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: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Write the controls::SensorTimestamp value in the Request metadata when
the request is popped from the queue ready to run the pipeline. This
ensures that the timestamp is written to the correct Request item,
which may not be at the top of the queue when the Unicam buffer dequeue
occurs.
Fixes: fcfb1dc02a ("libcamera: raspberry: Report sensor timestamp")
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: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The controller algorithms currently run on every frame provided to the
IPA by the pipeline handler. This may be undesirable for very fast fps
operating modes where it could significantly increase the computation
cycles (per unit time) without providing any significant changes to the
IQ parameters. The added latencies could also cause dropped frames.
Pass the FrameBuffer timestamp to the IPA through the controls. This
timestamp will be used to rate-limit the controller algorithms to run
with a minimum inter-frame time given by a compile time constant,
currently set to 16.66ms. On startup, we don't rate-limit the algorithms
until after the number of frames required for convergence.
Signed-off-by: Naushir Patuck <naush@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>
The minimum and maximum vblanking can change when a new format is
applied to the sensor subdevice, so be sure to retrieve up-to-date
values.
The V4L2Device acquires the new updateControlInfo() method to perform
this function, and which the CameraSensor calls automatically if its
setFormat method is used to update the sensor.
However, not all pipeline handlers invoke the setFormat method
directly, so the new method must be made publicly available for
pipeline handlers to call if they need to.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
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>
Register static properties in the CameraSensor class by inspecting the
camera sensor properties database.
Static properties are overridden by properties retrieved from
the kernel interface at run-time if any overlap between the two
sets occurs.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Introduce a database of camera sensor properties, which contains
information on the camera sensor which are not possible, or desirable,
to retrieve from the device at run time.
The camera sensor database is accessed through a static function and
is indexed using the camera sensor model as reported by
properties::Model.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The ControlList merge operation is protected with an ASSERT to guarantee
that the two lists are compatible.
Unfortunately this assertion fails when we run IPAs in an isolated case
as while the lists are compatible, the isolated IPA has a unique
instance of the id map. This breaks the pointer comparison, and the
assertion fails with a false positive.
Remove the assertion, leaving only a todo in it's place as this breaks
active users of the library.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=31
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Report the sensor's timestamp in the Request metadata by using the
Unicam::Image buffer timestamp as an initial approximation.
The buffer's timestamp is recorded at DMA-transfer time, and it does not
theoretically matches the 'start of exposure' definition, but when used
to compare two consecutive frames it gives an acceptable estimation of
the sensor frame period duration.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
When a Request is completed upon receiving the IPA produced metadata,
the metadata associated with the Request are over-written, deleting
the information set at output buffer completion, such as the
SensorTimestamp.
This commit applies to the RaspberryPi pipeline handler the same change
applied to IPU3 in commit 2ee3dd57e2fc ("libcamera: ipu3: Merge IPA
metadata controls").
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
I got fooled by the documentation of setRequest() implying that the
function is meant to be called by pipeline handlers only, which it is
used in the Request class at Request::addBuffer() and Request::reuse()
time.
Rework the documentation to report that.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the sensor's timestamp in the Request metadata using the
completed buffer timestamp.
The buffer's timestamp reports the video capture buffer processing time,
and it does not theoretically matches the 'start of exposure'
definition.
VIMC being a testing platform and the test driver completes the buffers
for each media entity connected in the pipeline one after the other, the
current solution is acceptable for the pipeline.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the sensor's timestamp in the Request metadata using the
completed buffer timestamp.
The buffer's timestamp is recorded at DMA-transfer time, and it does not
theoretically matches the 'start of exposure' definition. Record this with
a \todo entry.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the sensor's timestamp in the Request metadata using the
completed buffer timestamp.
The buffer's timestamp is recorded at DMA-transfer time, and it does not
theoretically matches the 'start of exposure' definition. Record this with
a \todo entry.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
When a Request is completed upon receiving the IPA produced metadata,
the metadata associated with the Request are over-written, deleting
the information set at output buffer completion, such as the
SensorTimestamp.
This commit applies to the RkISP1 pipeline handler the same change
applied to IPU3 in commit 2ee3dd57e2fc ("libcamera: ipu3: Merge IPA
metadata controls").
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the sensor's timestamp in the Request metadata using the
completed buffer timestamp.
The UVC driver reports timestamps of SOE event through metadata, for
which there is no support in the current pipeline implementation.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
When a Request is completed upon receiving the IPA produced metadata,
they should be merged with the metadata set by the pipeline handler
before reporting them to applications.
Use ControlList::merge() to collect the IPA produced controls to the
request's metadata.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Report the sensor's timestamp in the Request metadata by using the
CIO2 buffer timestamp as an initial approximation.
The buffer's timestamp is recorded at DMA-transfer time, and it does not
theoretically matches the 'start of exposure' definition, but when used
to compare two consecutive frames it gives an acceptable estimation of
the sensor frame period duration.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Add a new ControlList::merge() function to merge two control lists by
copying in the values in the list passed as parameters.
This can be used by pipeline handlers to merge metadata they populate
with metadata received from an IPA.
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[reimplement the function by not using std::unordered_map::merge()]
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Add a check, that makes sure that the given FrameBuffer is associated
to a RkISP1FrameInfo instance. The current code tries to access the
frame info without checking if it actually exists.
Fixes: 0eb65e14e ("libcamera: pipeline: rkisp1: Attach to an IPA")
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The original code uses Variable-Length-Array, which is not officially
supported in C++. This replaces the array with std::vector.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
When the CIO2 returns a cancelled buffer, we will not queue buffers
to the IMGU.
These buffers should be explicitly marked as cancelled to ensure
the application knows there is no valid metadata or frame data
provided in the buffer.
Provide a cancel() method on the FrameBuffer to allow explicitly
cancelling a buffer.
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
