A LIBCAMERA_LOG_LEVELS value of "RkISP1:0" also applies to RkISP1Ccm and
RkISP1Awb. This behavior is unexpected as it automatically enables all
algorithm log categories when the intent is only to increase the log
level of the upper category. Fix that replacing the manual matching code
with fnmatch. This has the side effect that more wildcards ("?" and
"[...]") are supported which is acceptable but won't be advertised.
Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Previously we call Thread::setThreadAffinityInternal in
Thread::startThread. The purpose was to avoid the main workload being
run on incorrect CPUs. This leads to a race condition of setting
`Thread::thread_` in `Thread::start()` and accessing
`Thread::setThreadAffinityInternal` though.
This patch moves the call after the construction of std::thread to avoid
the race condition. The downside is that the first tasks, if any, upon
starting a thread might be run on incorrect CPUs.
Fixes: 4d9db06d66 ("libcamera: add method to set thread affinity")
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Move the section of the Thread support page dealing with thread safety
to a dedicated .dox file at Documentation/. This is done to support the
splitting of the Documentation into a public and internal version. With
a separate page, references can be made to thread safety without having
to include the Thread class in the doxygen run. Some sections of the new
page are still specific to internal implementations and so are hidden
with the \internal flag and an internal section which is conditionally
included. For now, hardcode it to be included in the Doxyfile.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
uClibc doesn't provide memfd_create(), which led libcamera to open-code
the call using syscall(). Sprinkling the code with #ifdef's isn't the
most readable option, so improve it by providing a local implementation
of memfd_create(), and call the function unconditionally from
MemFd::create(). This makes the main code path more readable.
Suggested-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Milan Zamazal <mzamazal@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment blocks in all
remaining locations that were not caught by the automated script as they
are out of sync with the file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
When the C library doesn't provide local object support, the
utils::strtod() function simply calls strtod() from the C library. The
current implementation does so incorrectly, and calls utils::strtod()
instead, resulting in infinite recursion. Fix it with a proper namespace
qualifier.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Several functions in libcamera classes are marked as thread-bound,
restricting the contexts in which those functions can be called. There
is no infrastructure to enforce these restrictions, causing difficult to
debug race conditions when they are not met by callers.
As a first step to solve this, add an assertThreadBound() protected
function to the Object class to test if the calling thread context is
valid, and use it in member functions of Object subclasses marked as
thread-bound. This replaces manual tests in a few locations.
The thread-bound member functions of classes that do not inherit from
Object are not checked, and neither are the functions of classes marked
as thread-bound at the class level. These issue should be addressed in
the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Object instances are meant to be deleted from the thread they are bound
to, and this requirement is documented. There are however exceptions to
the rule, as threads may be stopped and restarted, with objects bound to
them not being deleted and recreated for every stop/restart cycle. Bound
objects may therefore need to be deleted after the thread has stopped,
making it impossible to use Object::deleteLater().
Document the lifetime requirements more precisely, and enforce them with
an assertion.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Objects can be scheduled for deletion with Object::deleteLater(), which
queues a deferred deletion to the thread's event loop. As the
deleteLater() function is meant to be called from a different thread,
this may race with thread termination, and deferred deletions queued
just before calling Thread::exit() may not be processed by the event
loop. Make sure they get processed when finishing the thread, before
stopping.
This eliminates the race condition that occurs when calling
Object::deleteLater() followed by Thread::exit() from the same thread.
Calling deleteLater() from neither the thread the object is bound to or
the thread calling Thread::exit() is still inherently racy.
The change fixes a failure in the object-delete unit test.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
The signal.h header doesn't need to include object.h. Replace it with a
forward declaration, and instead include object.h in source files that
require it. It can speed up compilation a little bit, but more
importantly avoids unintended dependencies from the Signal class to the
Object class to be added later as the compiler will catch them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
The Object::message() function is documented as thread-bound without
using the correct \threadbound reference. Fix it to ensure it gets
included in the thread safety context list.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Files opened internally in libcamera without the O_CLOEXEC file will
remain open upon a call to one of the exec(3) functions. As exec()
doesn't destroy local or global objects, this can lead to various side
effects. Avoid this by opening file descriptors with O_CLOEXEC for all
internal files.
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>
Not all C libraries include support for locale objects (locale_t) and
the strto*_l() family of functions. A notable example is uClibc that can
be compiled with a hardcoded "C" locale. Compilation then fails as the
newlocale(), freelocale() and strtod_l() functions are not defined.
Fix the compilation breakage by checking for the availability of the
locale_t type, and fall back to strtod() when the type isn't available.
This may not lead to the correct result if support for locale objects
isn't available and the locale isn't hardcoded to "C", but that is such
a corner case that we will likely never encounter it.
Fixes: e8ae254970 ("libcamera: yaml_parser: Use C locale")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
The strtod() function is locale-dependent, and thus ill-suited to parse
numbers coming from, for instance, YAML files. The YamlObject class uses
strtod_l() to fix that issue, but that function is not available with
all libc implementations. Correctly handling this problem is becoming
out of scope for the YamlObject class.
As a first step, add a strtod() helper function in the utils namespace
that copies the implementation from YamlObject, and use it in
YamlObject. The core issue will then be fixed in utils::strtod().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Each declaration of a LogCategory will create a new LogCategory, and
will be stored in an unordered_set Logger::categories_. This means that
when a plugin .so is unloaded and loaded, as happens when destructing
and creating a CamereManager, we'll get duplicate categories.
The Logger::registerCategory docs say "Log categories must have unique
names. If a category with the same name already exists this function
performs no operation.". The code does not comply with this.
We solve the issue with two changes:
Change the unordered_set to a vector for simplicity, as there's no need
for an unordered_set.
Instead of using the LogCategory constructor to create new categories in
_LOG_CATEGORY() macro, use a factory method. The factory method will
return either an existing LogCategory if one exists with the given name,
or a newly created one.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.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>
LogCategory just stores the char * that was given to it in the
constructor, i.e. it refers to memory "outside" LogCategory. If the
LogCategory is defined in a .so that is unloaded, then it leads to the
LogCategory pointing to freed memory, causing a crash.
Fix this by taking a copy of the name by using a std::string instead of
just storing the pointer.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.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>
The libcamera project is not yet ready to declare ABI nor API stability,
but it will benefit the community to be able to provide more regular
release cycles to determine 'versioned' points of history.
Ideally, these releases will be made at any ABI breakage, but can be
made at arbitary time based points along the way.
To support releases which may not be ABI stable, declare the soversion
of both the libcamera and libcamera-base library to be dependant upon
both the major minor and patch component of the project version.
As part of this, introduce a new 'Versions' summary section to highlight
the different version components that may become apparent within any
given build.
Bumping versions may leave dangling libcamera.so.* symlinks in build
directories. This will confuse Doxygen which will print during its
directory scanning phase a warning that the symlink can't be read. As we
don't need Doxygen to follow symlinks, disable it with EXCLUDE_SYMLINKS.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0,
likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera
requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS
support until mid-2024.
As no workaround has been found to fix compilation on gcc 8.3.0 while
still retaining the functionality of utils::defopt, remove it from the
libcamera base library. This change could be reverted once support for
gcc-8 will be dropped.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Commit 036d26d667 ("test: threads: Test thread cleanup upon abnormal
termination") added calls to functions provided by the pthread library
in the threads test, but didn't add the corresponding dependency. This
caused a link breakage on some platforms:
/usr/bin/ld: test/threads.p/threads.cpp.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.4'
/usr/bin/ld: /lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Fix it by adding the missing dependency.
Fixes: 036d26d667 ("test: threads: Test thread cleanup upon abnormal termination")
Reported-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Usage of find_library() to find dependencies that libcamera needs to
compile against can lead to the library being found even if the
corresponding headers are not installed. This will then result in a
compilation failure. Switch to dependency() for libdw, libunwind and
lttng-ust to fix this, all three libraries come with a pkgconfig file
that is usually installed by the distribution package that contains the
library headers.
Reported-by: Christian Rauch <Rauch.Christian@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The 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>
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>
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 the log file specified through LIBCAMERA_LOG_FILE can't be opened,
logging is currently completely disabled. This doesn't match the
documented behaviour that tells std::cerr is used instead. Fix it to
match the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
While std::cerr and stderr both target the same file by default, this
may be overridden by applications. Update the documentation to use
std::cerr instead of stderr to be accurate.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
gcc 10 and 11 produce an error when compiling libcamera in release mode:
In file included from ../../src/libcamera/base/object.cpp:13:
../../include/libcamera/base/message.h: In member function ‘void libcamera::Object::notifyThreadMove()’:
../../include/libcamera/base/message.h:58:47: error: array subscript ‘const libcamera::InvokeMessage[0]’ is partly outside array bounds of ‘libcamera::Message [1]’ [-Werror=array-bounds]
58 | Semaphore *semaphore() const { return semaphore_; }
| ^~~~~~~~~~
../../src/libcamera/base/object.cpp:280:17: note: while referencing ‘msg’
280 | Message msg(Message::ThreadMoveMessage);
| ^~~
This seems to be a false positive, given that msg->type() can never be
equal to Message::InvokeMessage in Object::message() when called from
Object::notifyThreadMove(), as the message is created there with the
Message::ThreadMoveMessage type. The problem as been reported in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105400, but the error
nonetheless needs to be fixed without waiting for a new gcc release, and
a dynamic_cast does the job with a small additional runtime cost that
shouldn't be a big issue, given that moving objects between threads is a
rare operation.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=125
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Duration class is missing the equivalent to the
std::chrono::duration constructor that takes a number of ticks expressed
as a scalar. Fix it, which allows initializing a Duration instance to 0
or 0.0.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The start(unsigned int msec) overload is error-prone, as the argument
unit can easily be mistaken in callers. Drop it and update all callers
to use the start(std::chrono::milliseconds) overload instead.
The callers now need to use std::chrono_literals. The using statement
could be added to timer.h for convenience, but "using" is discouraged in
header files to avoid namespace pollution. Update the callers instead,
and while at it, sort the "using" statements alphabetically in tests.
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>
Objects are not expected to be connected to the same signal more than
once. Doing so likely indicates a bug in the code, and can be
highlighted in debug builds with an assert that performs a lookup on the
signals_ list.
While it is possible to allow the implementation to let objects connect
to a specific signal multiple times, there are no expected use cases for
this in libcamera and this behaviour is restricted to favour defensive
programming by raising an error when this occurs.
Remove the support in the test framework which uses multiple Signal
connections on the same object, and update the test to use a second
Signal.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The Timer debug output does not report to which timer a condition refers
to. Fix that by printing the Timer address.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The abs_diff() function computes the absolute difference of two
elements. This may seem trivial at first, but can lead to unexpected
results when operating on unsigned operands. A common implementation
of the absolute difference of two unsigned int (used through the
libcamera code base) is
std::abs(static_cast<int>(a - b))
but doesn't return the expected result when either a or b is larger than
UINT_MAX / 2 due to overflows. The abs_diff() function offers a safe
alternative.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
The SharedFD::dup() implementation calls the C library dup() function on
the fd. When the SharedFD instance is invalid, this produces an invalid
fd, which is the correct behaviour, but logs an error message.
Fix it by returning an invalid UniqueFD directly when the SharedFD is
invalid. This also saves a system call, which is always nice to do.
Fixes: fcf98514cb ("libcamera: base: file_descriptor: Return UniqueFD from dup()")
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>
Add == and != comparison operators between two SharedFD instances, and
use them to replace manuel get() calls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
For consistency with UniqueFD, rename the fd() function to get().
Renaming UniqueFD::get() to fd() would have been another option, but was
rejected to keep as close as possible to the std::shared_ptr<> and
std::unique_ptr<> APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
