This commit moves the check that determines whether the mode argument of
`open*()` exists into a separate function.
With that, the check is fixed because previously it failed to account
for the fact that `O_TMPFILE` is not a power of two.
Furthermore, add `assert()`s in the fortified variants that ensure that
no mode is required by the specified flags.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.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>
To avoid confusion, have `__open64_2()` and `__openat64_2()` delegate to
`open64()` and `openat64()`, respectively, instead of `open()` and
`openat()`.
This does not change the behaviour because
`V4L2CompatManager::instance()->openat()` calls `openat64()` internally,
and that adds the `O_LARGEFILE` flag unconditionally.
Fixes: 1023107b64 ("v4l2: v4l2_compat: Intercept open64, openat64, and mmap64")
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
This way the construction of the default value of type `T`
can be delayed until it is really needed, which is useful,
for example when `T == std::string` and the default value comes
from a string literal, as the default value string would always
be constructed otherwise, even if not needed.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.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>
GCC 14 thinks `rects` is a "possibly dangling reference to a temporary":
/libcamera/src/android/camera_capabilities.cpp: In member function ‘int CameraCapabilities::initializeStaticMetadata()’:
/libcamera/src/android/camera_capabilities.cpp:1084:46: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
1084 | const Span<const Rectangle>& rects =
| ^~~~~
/libcamera/src/android/camera_capabilities.cpp:1085:83: note: the temporary was destroyed at the end of the full expression ‘(& properties)->libcamera::ControlList::get<libcamera::Span<const libcamera::Rectangle> >(libcamera::properties::PixelArrayActiveAreas).std::optional<libcamera::Span<const libcamera::Rectangle> >::value_or<libcamera::Span<const libcamera::Rectangle> >(libcamera::Span<const libcamera::Rectangle>())’
1085 | properties.get(properties::PixelArrayActiveAreas).value_or(Span<const Rectangle>{});
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
The return value of `value_or()` is indeed a temporary, but binding it
to a reference extends its lifetime. Avoid the warning by not using a
reference; this does not make much difference since `value_or()` does
not return a reference.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.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 camera name is copied in gst_libcamera_src_open() as we can't hold
the lock protecting the name while calling GST_ELEMENT_ERROR(). The
GST_ELEMENT_ERROR() macro sends a message on the bus, taking more locks
and possibly causing issues.
However, the current code makes the copy, but does not actually use it.
So fix that.
Fixes: 58feb69f85 ("gst: libcamerasrc: Implement selection and acquisition")
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The vector in question is destroyed when the item in the `buffers_` map
is destroyed as a result of the `erase()` call. A vector's destructor
already does all the things that `clear()` does,
so calling it earlier is not needed.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Now that `Camera::generateConfiguration()` takes a `libcamera::Span`
of `StreamRole`, remove the `StreamRoles` type, which was an alias
to `std::vector<libcamera::StreamRole>`.
The removal has two reasons:
- it is no longer strictly necessary,
- its presence may suggest that that is the preferred (or correct)
way to build/pass a list of `StreamRole`.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Fix small checkstyle report on roles initialiser]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Change the parameter type of `generateConfiguration()` from `const std::vector&`
to `libcamera::Span`. A span is almost always preferable to a const vector ref
because it does not force dynamic allocation when none are needed, and it allows
any contiguous container to be used.
A new overload is added that accepts an initializer list so that
cam->generateConfiguration({ ... })
keeps working.
There is no API break since a span can be constructed from a vector
and the initializer list overload takes care of the initializer lists,
but this change causes an ABI break.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[Kieran: Apply checkstyle fixups]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In `udevNotify()`, constructing an std::string from the device's
associated action is unnecessary as it is only compared against static
strings, and for that purpose an std::string_view works just as well,
while being cheaper to construct.
In the same vein, an std::string_view can be used to store the device's
devnode initially, and the string construction can be deferred until it
is needed.
Furthermore, previously `udev_device_get_devnode()` was called twice.
The extra call is now removed.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Previously, after `addV4L2Device()` had seen all dependecies, it would
remove the `MediaDeviceDeps` object from the `pending_` list, which
would result in it being destroyed. However, there would still be
(dangling) pointers to this object in `devMap_` that were added in
`addUdevDevice()` (line 103). So remove the entry with the given devnum
when it is removed from the corresponding `MediaDeviceDeps` object.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Instead of having bool return type and an out parameter, use
std::optional<libcamera::StreamRole> to return from
StreamKeyValueParser::parseRole().
Meanwhile at it, re-word an existing comment to make it lucid.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Currently, doxygen is run by ninja in the top-level build directory,
therefore the "Documentation" folder is always created there. However,
when libcamera is built as a subproject, it should not touch the
top-level build directory because it can cause conflicts and because
the documentation won't be created where meson thinks it will be, so
the "doxygen" target will always be dirty and installation will fail.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Building libcamera as a subproject is failing when tracepoints are
enabled due to incorrectly managing the relative paths between the
source and build directory while generating tracepoint headers.
The previously used
path = output.replace('include/', '', 1)
logic is not sufficient to correctly determine the proper path when
libcamera is built as a subproject, and does not correctly handle the
relative paths, causing path to be processed as:
'subprojects/libcamera/include/libcamera/internal/tracepoints.h'.replace('include/', '', 1)
which evaluates to
'subprojects/libcamera/libcamera/internal/tracepoints.h'
so the tracepoints.h header file will try to include:
#define TRACEPOINT_INCLUDE "subprojects/libcamera/libcamera/internal/tracepoints.h"
which will fail.
Fix it by using Python's pathlib to calculate the relative path of the
output file with respect to the "include" directory of libcamera.
This has been tested with Pipewire. For non-subproject builds it should
generate the exact same path that was previously generated.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
[Kieran: Commit message expanded/reworded]
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
