Age | Commit message (Collapse) | Author |
|
Import the latest version of the Android headers from Chrome OS (commit
a30340e77ec8 ("camera: Uprev Android camera headers")). This brings in
the Camera HAL v3.5 support.
The headers are imported verbatim, except for the addition of the SPDX
headers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
We don't want to generate the same functional files for core.mojom as
the other mojom files, but we do want to generate the documentation cpp
files. Add core.mojom to the mojom files list after the main generation
is complete, so that the documentation generator can pick it up.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Move the documentation back to the mojom file from the cpp file. While
at it, move the documentation for IPAInterface::init() and
IPAInterface::stop() to the IPA guide.
While at it, update the todo comment in all of the mojom files
accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
[umang.jain@ideasonboard.com: Update todos]
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Use meson's files() to list the mojom files instead of the file names
directly. This is so that we can still access the files from
src/libcamera/ipa/meson.build later for building documentation cpp
files from the mojom files.
While at it, fix some redundant string manipulation in building the
mojom modules.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
We need a separate control to report the nominal frame duration, but
it's also useful to report the min/max frame duration values that will
be used. Split the FrameDurations control into FrameDuration and
FrameDurationLimits respectively to support both of these.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Pass in frame timestamps from IPU3 pipeline handler to IPU3 IPA via
IPU3Event. Frame timestamps are helpful to IPA algorithms to
convergence, by setting them via IPA stats.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.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>
|
|
The ControlInfoMap of entityControls member in IPAConfigInfo struct,
was not able to correctly match to the ControlInfoMap defined in
core.mojom. This resulted in a FATAL breakage when IPU3 IPA is meant to
run:
FATAL IPADataSerializer ipa_data_serializer.cpp:437 ControlSerializer
not provided for serialization of ControlInfoMap
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
IPAConfigInfo is a consolidated data structure passed from IPU3
pipeline-handler to IPU3 IPA. The structure can be extended with
additional parameters to accommodate the requirements of multiple
IPU3 IPA modules.
Adapt the in-tree IPU3 IPA to use IPAConfigInfo as well.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Generated IPA headers from mojom files need to be installed to
$INCLUDE_PATH in order to be available system-wide. Without this,
out-of-tree IPAs won't be able to link and build themselves.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This matches the naming convention for IPA IPC.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Acked-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>
|
|
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>
|
|
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>
|
|
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>
|
|
In most cases, file paths in meson files start with get_option().
To maintain a consistent theme, use meson's get_option('includedir')
universal option over raw 'include'. This option is defaulted to
'include' string value, hence this commit does not introduce any
functional changes.
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>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Since meson v0.49.0, join_paths() is equivalent to '/' hence,
drop and replace it with '/' short-hand in meson files.
This commit does not introduce any functional changes.
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>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
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>
|
|
Report the function which fails an assertion as well as the actual
assertion.
This now reports as:
[30:08:53.218816270] [226567] FATAL default request.cpp:150 assertion "d" failed in reuse()
rather than:
[30:11:05.271888926] [228531] FATAL default request.cpp:150 assertion "d" failed
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Put core.mojom in the libcamera namespace, as all structs that are
defined in core.mojom are meant to be in that namespace. Fix the structs
that are used in the other mojom files accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
For structs defined in core.mojom that have the skipHeader tag, if
they're only used in function parameters (in a mojom file) then a
forward-declaration is sufficient. However, if the struct is used in
another struct in a mojom file, then the forward-declaration is
insufficient, and the definition needs to be included. Do so for
CameraSensorInfo, which is the only forward-declared struct in
ipa_interface.h, and update the documentation comment.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
V4L2Device::updateControls() takes two arguments, raw array and
its size, for the v4l2_ext_control values. This replaces it with
libcamera::Span.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
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>
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>
|
|
When the camera manager calls stop on a pipeline, it is expected that
the pipeline handler guarantees all requests are returned back to the
application before the camera has stopped.
Ensure that this guarantee is met by providing an accessor on the
pipeline handler to validate that all pending requests are removed.
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The LIBCAMERA_D_PTR() and LIBCAMERA_O_PTR() macros do not require an
argument, but the version of the macro consumed by Doxygen does.
Fix this by removing the klass parameter from both macros in their
documentation version.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The LIBCAMERA_DECLARE_PRIVATE() macro, used by the library classes
that inherit from libcamera::Extensible in order to implement the
PIMPL pattern, expands to:
public: \
class Private; \
friend class Private;
The 'klass' argument is not used and it might confuse developers as
it might hint that the class that defines the pattern's implementation
can be freely named, while it is actually hardcoded to 'Private'.
Drop the argument from the macro definition.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Hanlin Chen <hanlinchen@google.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Enabling the gcc undefined behaviour sanitizer (with the meson configure
-Db_sanitize=undefined option) causes many tests to fail, with errors
such as the following (for test/object-invoke):
------------------------------------------------------------------------
../../include/libcamera/bound_method.h:198:27: runtime error: member access within address 0x55fcd7bfbd38 which does not point to an object of type 'BoundMethodBase'
0x55fcd7bfbd38: note: object has invalid vptr
fc 55 00 00 2a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31 00 00 00 00 00 00 00 4b c6 72 88
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
../../include/libcamera/bound_method.h:198:41: runtime error: member call on null pointer of type 'struct InvokedObject'
../../include/libcamera/bound_method.h:198:41: runtime error: member access within null pointer of type 'struct InvokedObject'
Segmentation fault
------------------------------------------------------------------------
or
------------------------------------------------------------------------
../../include/libcamera/bound_method.h:198:27: runtime error: member access within address 0x603000006628 which does not point to an object of type 'BoundMethodBase'
0x603000006628: note: object has invalid vptr
70 55 00 00 2a 00 00 00 be be be be 03 02 00 00 18 00 00 00 01 00 00 60 00 00 00 00 05 00 80 07
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
=================================================================
==941==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000006630 at pc 0x55704e461371 bp 0x7fff539b9040 sp 0x7fff539b9030
READ of size 8 at 0x603000006630 thread T0
#0 0x55704e461370 in libcamera::BoundMethodMember<InvokedObject, void, int>::invoke(int) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x47370)
#1 0x55704e4622ca in void libcamera::BoundMethodArgs<void, int>::invokePack<0ul>(libcamera::BoundMethodPackBase*, std::integer_sequence<unsigned long, 0ul>) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x482ca)
#2 0x55704e460a93 in libcamera::BoundMethodArgs<void, int>::invokePack(libcamera::BoundMethodPackBase*) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x46a93)
#3 0x7fdc38a5fec4 in libcamera::InvokeMessage::invoke() ../../src/libcamera/message.cpp:154
#4 0x7fdc38a62faf in libcamera::Object::message(libcamera::Message*) ../../src/libcamera/object.cpp:183
#5 0x7fdc38ad3742 in libcamera::Thread::dispatchMessages(libcamera::Message::Type) ../../src/libcamera/thread.cpp:575
#6 0x7fdc38972d8d in libcamera::EventDispatcherPoll::processEvents() ../../src/libcamera/event_dispatcher_poll.cpp:148
#7 0x55704e44bc15 in ObjectInvokeTest::run() (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x31c15)
#8 0x55704e4630ab in Test::execute() ../../test/libtest/test.cpp:28
#9 0x55704e44965b in main ../../test/object-invoke.cpp:204
#10 0x7fdc36090eba in __libc_start_main ../csu/libc-start.c:314
#11 0x55704e449359 in _start (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x2f359)
0x603000006630 is located 0 bytes to the right of 32-byte region [0x603000006610,0x603000006630)
allocated by thread T0 here:
#0 0x7fdc3ad757c7 in operator new(unsigned long) /var/tmp/portage/sys-devel/gcc-11.0.1_pre9999/work/gcc-11.0.1_pre9999/libsanitizer/asan/asan_new_delete.cpp:99
#1 0x55704e45afea in __gnu_cxx::new_allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> >::allocate(unsigned long, void const*) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x40fea)
#2 0x55704e45a45d in std::allocator_traits<std::allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> > >::allocate(std::allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> >&, unsigned long) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x4045d)
#3 0x55704e458339 in std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> > > std::__allocate_guarded<std::allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> > >(std::allocator<std::_Sp_counted_ptr_inplace<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, (__gnu_cxx::_Lock_policy)2> >&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3e339)
#4 0x55704e4574ad in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, int&>(libcamera::BoundMethodPack<void, int>*&, std::_Sp_alloc_shared_tag<std::allocator<libcamera::BoundMethodPack<void, int> > >, int&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3d4ad)
#5 0x55704e4569c7 in std::__shared_ptr<libcamera::BoundMethodPack<void, int>, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<libcamera::BoundMethodPack<void, int> >, int&>(std::_Sp_alloc_shared_tag<std::allocator<libcamera::BoundMethodPack<void, int> > >, int&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3c9c7)
#6 0x55704e455f9d in std::shared_ptr<libcamera::BoundMethodPack<void, int> >::shared_ptr<std::allocator<libcamera::BoundMethodPack<void, int> >, int&>(std::_Sp_alloc_shared_tag<std::allocator<libcamera::BoundMethodPack<void, int> > >, int&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3bf9d)
#7 0x55704e454eb5 in std::shared_ptr<libcamera::BoundMethodPack<void, int> > std::allocate_shared<libcamera::BoundMethodPack<void, int>, std::allocator<libcamera::BoundMethodPack<void, int> >, int&>(std::allocator<libcamera::BoundMethodPack<void, int> > const&, int&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3aeb5)
#8 0x55704e454220 in std::shared_ptr<libcamera::BoundMethodPack<void, int> > std::make_shared<libcamera::BoundMethodPack<void, int>, int&>(int&) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x3a220)
#9 0x55704e450e60 in libcamera::BoundMethodMember<InvokedObject, void, int>::activate(int, bool) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x36e60)
#10 0x55704e44efb2 in void libcamera::Object::invokeMethod<InvokedObject, void, int, int, (void*)0>(void (InvokedObject::*)(int), libcamera::ConnectionType, int) (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x34fb2)
#11 0x55704e44b7cc in ObjectInvokeTest::run() (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x317cc)
#12 0x55704e4630ab in Test::execute() ../../test/libtest/test.cpp:28
#13 0x55704e44965b in main ../../test/object-invoke.cpp:204
#14 0x7fdc36090eba in __libc_start_main ../csu/libc-start.c:314
SUMMARY: AddressSanitizer: heap-buffer-overflow (libcamera/build/x86-gcc-11.0.1/test/object-invoke+0x47370) in libcamera::BoundMethodMember<InvokedObject, void, int>::invoke(int)
Shadow bytes around the buggy address:
0x0c067fff8c70: 00 fa fa fa 00 00 06 fa fa fa fd fd fd fd fa fa
0x0c067fff8c80: 00 00 06 fa fa fa 00 00 03 fa fa fa 00 00 00 05
0x0c067fff8c90: fa fa 00 00 04 fa fa fa 00 00 00 00 fa fa fd fd
0x0c067fff8ca0: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
0x0c067fff8cb0: fd fd fd fd fa fa 00 00 00 00 fa fa 00 00 00 00
=>0x0c067fff8cc0: fa fa 00 00 00 00[fa]fa fd fd fd fa fa fa fa fa
0x0c067fff8cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8cf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c067fff8d10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==941==ABORTING
------------------------------------------------------------------------
The root cause isn't clear, but this change fixes the issue. It may be a
bug in gcc.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The BoundMethodMember instance created in Signal::connect() for
receivers inheriting from the Object class incorrectly sets the return
type to void instead of R. This doesn't cause any functional issue as
the return type is ignored anyway for signals, but should be fixed
nonetheless.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
std::reverse_iterator<iterator> is constructed from an instance of
iterator, and automatically subtracts 1 when dereferencing. rbegin() and
rend() should thus be constructed from end() and begin() respectively.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Replace the __FILE__ and __LINE__ values passed to the _log() function
with default parameters, taking their values from the __builtin_FILE()
and __builtin_LINE() functions. This moves handling of the file and line
from the preprocessor to the compiler, which is generally preferred as
it increases type safety.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The _log() functions, as well as the LogMessage constructor, exist in
two versions, one that takes a log category, and one that doesn't. The
latter uses the default log category. This can be simplified by passing
a LogCategory pointer to _log(), which can then be null for the default
category, and moving the retrieval of the default log category from the
LogMessage constructor to the _log() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The ProxyState is only used by the IPAProxy, so it should remain inside
that scope. This helps clarify the usage, and improves the
documentation by bringing the (future) ProxyState documentation into the
class.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The BoundMethodPack used by the void BoundMethodArgs variant incorrectly
specified the template argument as void * instead of void. This causes
no functional problem, but results in space for an unused void * return
value being reserved. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
PipelineHandler::queueRequest() is asynchronously invoked in
Camera::queueRequest(). Therefore the return value of
PipelineHandler::queueRequest() is useless. This changes the
function to a void function.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Custom event dispatchers for threads was an API meant to provide a way
to integrate libcamera in the application's event loop. This isn't used
anymore, as libcamera now creates internal threads. Drop the unused
Thread::setEventDispatcher() function, and update the documentation
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide a toString helper to assist in printing Request state
for debug and logging contexts.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide a sequence number on Requests which are added by the pipeline
handler.
Each pipeline handler keeps a requestSequence per CameraData and
increments everytime a request is queued on that camera.
The sequence number is associated with the Request and can be utilised
for assisting with debugging, and printing the queueing sequence of in
flight requests.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The FrameBuffer class is only friends with Request so that the request
can be associated with the buffers.
FrameBuffer already has a helper to setRequest(), so let's use that
directly instead.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Asynchronous tasks can only be submitted while the IPA is running.
Further more, the shutdown sequence can not be tracked with a simple
running flag. We can also be in the state 'Stopping' where we have not
yet completed all events, but we must not commence anything new.
Refactor the running_ boolean into a stateful enum to track this.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Rename ConfigInput to IPAConfig to be more consistent with the naming,
and remove ConfigInput::op, as it is never used.
Replace ConfigOutput with a ControlList type, as that is the only return
type from ipa::configure().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Separate out the in and out parameters in ipa::start() as they are not
the same. This function now takes in a ControlList and returns out a
struct StartConfig which holds a ControlList and drop frame count for
the pipeline handler to action.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the opening of the CamHelper from ipa::configure() to ipa::init().
This allows the pipeline handler to get the sensor specific parameters
in pipeline_handler::match() where the ipa is initialised.
Having the sensor parameters available earlier will allow selective
use of the embedded data node in a future change.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Pass the sensor model string to the IPA init() method through the
IPASettings structure.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There are std::unique_ptr rvalue reference arguments. They are
intended to pass the ownership to the functions. In the case,
it is right to let the argument be std::unique_ptr value and
pass by std::move().
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>
|
|
The IPU3 IPA will need the BDS configuration when the AWB/AGC algorithm
will be integrated.
In order to do that, the configure() interface needs to be modified.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Any struct that is defined in core.mojom with the skipHeader tag needs
to be present in ipa_interface.h, either forward-declared or #included.
Add a comment so that, in the future, people don't try to send patches
removing the seemingly unused forward-declaration.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
On DelayedControls::reset(), the values retrieved from the sensor device
were added to the queues with the updated flag set to true. This would
cause the helper to write out the value to the device again on the first
DelayedControls::applyControls() call. This is unnecessary, as the
controls written are identical to what is stored in the device driver.
Fix this by explicitly setting the update flag to false in
DelayedControls::reset() when adding the controls to the queue.
Additionally, use the Info() constructor when adding items to the queue
for consistency.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Fixes: 3d4b7b005911 ("libcamera: delayed_controls: Add helper for controls that apply with a delay")
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
If an exposure time change adjusts the vblanking limits, and we set both
VBLANK and EXPOSURE controls through the VIDIOC_S_EXT_CTRLS ioctl, the
latter may fail if the value is outside of the limits calculated by the
old VBLANK value. This is a limitation in V4L2 and cannot be fixed by
setting VBLANK before EXPOSURE in a single VIDIOC_S_EXT_CTRLS ioctl.
The workaround here is to have the DelayedControls object mark the
VBLANK control as "priority write", which then write VBLANK separately
from (and ahead of) any other controls. This way, the sensor driver will
update the EXPOSURE control with new limits before the new values is
presented, and will thus be seen as valid.
To support this, a new struct DelayedControls::ControlParams is used in
the constructor to provide the control delay value as well as the
priority write flag.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Fix up trivial comments, merge conflicts]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|