The libcamera internal headers are located in src/libcamera/include/.
The directory is added to the compiler headers search path with a meson
include_directories() directive, and internal headers are included with
(e.g. for the internal semaphore.h header)
#include "semaphore.h"
All was well, until libcxx decided to implement the C++20
synchronization library. The __threading_support header gained a
#include <semaphore.h>
to include the pthread's semaphore support. As include_directories()
adds src/libcamera/include/ to the compiler search path with -I, the
internal semaphore.h is included instead of the pthread version.
Needless to say, the compiler isn't happy.
Three options have been considered to fix this issue:
- Use -iquote instead of -I. The -iquote option instructs gcc to only
consider the header search path for headers included with the ""
version. Meson unfortunately doesn't support this option.
- Rename the internal semaphore.h header. This was deemed to be the
beginning of a long whack-a-mole game, where namespace clashes with
system libraries would appear over time (possibly dependent on
particular system configurations) and would need to be constantly
fixed.
- Move the internal headers to another directory to create a unique
namespace through path components. This causes lots of churn in all
the existing source files through the all project.
The first option would be best, but isn't available to us due to missing
support in meson. Even if -iquote support was added, we would need to
fix the problem before a new version of meson containing the required
support would be released.
The third option is thus the only practical solution available. Bite the
bullet, and do it, moving headers to include/libcamera/internal/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
The StaggeredCtrl class, part of the Raspberry Pi pipeline handler, is
part of libcamera. Move it to the libcamera namespace to simplify usage
of libcamera APIs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
The StaggeredCtrl class has large functions, move them to a .cpp file
instead of inlining them all to reduce the binary size.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
In an attempt to clarify the license terms of all files in the libcamera
project, the build system files deserve particular attention. While they
describe how the binaries are created, they are not themselves
transformed into any part of binary distributions of the software, and
thus don't influence the copyright on the binary packages. They are
however subject to copyright, and thus influence the distribution terms
of the source packages.
Most of the meson.build files would not meet the threshold of
originality criteria required for copyright protection. Some of the more
complex meson.build files may be eligible for copyright protection. To
avoid any ambiguity and uncertainty, state our intent to not assert
copyrights on the build system files by putting them in the public
domain with the CC0-1.0 license.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Acked-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Show Liu <show.liu@linaro.org>
The proxy worker is licensed under the GPL. It is compiled as a binary
separate from libcamera.so, and it is our understanding and intent that
the GPL license doesn't propagate to libcamera.so. However, as the
worker is executed by libcamera.so, the GPL license may cause concerns
in this context, regardless of whether the concerns are valid or not.
This uncertainty could be addressed by a combination of a legal review
and an explicit intent clarification from the copyright holders. A
simpler option is to relicense the code under the LGPL.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
The simple pipeline handler rejects devices that have multiple capture
video nodes. There's no real reason to do so, a more dynamic approach is
possible as the pipeline handler already locates the video device by
walking the media graph.
Rework the match sequence by skipping any check on the video nodes, and
create the V4L2VideoDevice for the media entity at the end of the
pipeline when initializing the camera data. The V4L2VideoDevice
instances are managed by the pipeline handler itself, to avoid creating
separate instances in the camera data if multiple sensors are routed to
the same video device.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add support for an optional format converter, supported by the
SimpleConverter class. If a converter is available for the pipeline, it
will be used to expose additional pixel formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
This new pipeline handler aims at supporting any simple device without
requiring any device-specific code. Simple devices are currently defined
as a graph made of one or multiple camera sensors and a single video
node, with each sensor connected to the video node through a linear
pipeline.
The simple pipeline handler will automatically parse the media graph,
enumerate sensors, build supported stream configurations, and configure
the pipeline, without any device-specific knowledge. It doesn't support
configuration of any processing in the pipeline at the moment, but may
be extended to support simple processing such as format conversion or
scaling in the future.
The only device-specific information in the pipeline handler is the list
of supported drivers, required for device matching. We may be able to
remove this in the future by matching with the simple pipeline handler
as a last resort option, after all other pipeline handlers have been
tried.
Signed-off-by: Martijn Braam <martijn@brixit.nl>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Andrey Konovalov <andrey.konovalov@linaro.org>
The CameraSensor class assumes that camera sensors support the exact
same list of sizes of all media bus codes. While allowing a simpler API,
this assumption is incorrect and is blocking usage of some camera
sensors.
Relaxing the constraint is possible without changes to the CameraSensor
API syntax, but requires changing its semantics. The sizes() function
now returns the list of all sizes for all media bus codes, and the
getFormat() function now searches in all supported media bus codes. The
former is likely not the most useful option for pipeline handlers, but
the sizes() function is currently unused. Designing a better API will
require inspecting current and expected future use cases in pipeline
handlers to determine proper heuristics.
While at it, fix a small typo in an unrelated comment.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
While most camera sensors are exposed to userspace as a single subdev,
this is not always the case. A notable exception is the smiapp driver,
which exposes two or three subdevs. The subdev at the output of the
camera sensor will thus have more than one pad. Prepare for this by
removing the single-pad restriction, and locating the source pad
dynamically.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The CameraSensor::logPrefix() function accesses the entity from the
subdev. Remove the level of indirection as we stored a pointer to the
entity internally.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Since the Linux kernel commit:
69e39d40587b ("media: vimc: Implement get/set selection in sink")
the crop rectangle on the VIMC scaler sink pad needs to be
reset to match the requested format to avoid hitting a pipeline format
misconfiguration when the applied format is larger than the one
set in a previous capture session.
As the V4L2 specification is not clear on what the correct behaviour
is, if the crop rectangle should be reset automatically or not on a
set_fmt operation, momentary fix the pipeline handler to please the
driver and manually reset the crop rectangle.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Store the MediaDevice for the VIMC instance in the VimcCameraData class.
This will be used to check the media device version at runtime.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add a MediaDevice::version() function to expose the media device API
version number. This can be useful to support driver API changes in
pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Expose the image stride which may be retrieved after a video device
has been configured. It may only be retrieved at that point as the
assignment of video devices takes place at this point.
In the future video devices should be assigned at configuration
validation time and the stride value retrieved at that point.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add three additional fields to PixelFormatInfo to report the number of
bits per pixel, the colour encoding, and the data packing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add the 8-, 10- and 12-but Bayer formats, in both unpacked and
MIPI-packed variants, to the format tables in PixelFormatInfo and
V4L2PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To prepare for storing more information about pixel formats in
PixelFormatInfo, move the class to formats.cpp and document it. The
pixel formats database is moved to the same file, and a new static
function is added to PixelFormatInfo to retrieve a PixelFormatInfo for a
PixelFormat.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Replace the two big manual switch...case with maps. This should not just
improve efficiency when we will have a larger number of formats, but
also paves the way to storing more format information to create
additional helpers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Call realpath() to strip out any levels of indirection required in
referencing the root build directory.
This simplifies the debug output when reporting and parsing paths.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The comments describe functionality before libcameraBuildPath() was
adapted from libcameraPath() to return the root of the build, and
described having to take a relative path.
This is no longer the case, and the comment is inaccurate. Fix it.
Fixes: 1b8ac8473c ("libcamera: utils: Adapt libcameraPath to match use cases")
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Make the IPAModule class inherit from Loggable to log the IPA module
name in all messages.
Before:
[14:19:55.743795676] [20250] ERROR IPAModule ipa_module.cpp:279 IPA module is not an ELF file
After:
[14:20:22.343795887] [20270] ERROR IPAModule ipa_module.cpp:279 ipa_vimc.so: IPA module is not an ELF file
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The black levels will be used when saving RAW data in DNG containers.
Four values are reported, one for each channel, in the order R, Gr, Gb
and B. The values are reported as being out of a 16-bit pixel range
(a fully saturated pixel would be 65535), so may need subsequent
re-scaling, depending on use.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add support for camera sensor information in the libcamera IPA protocol.
Define a new 'struct ipa_sensor_info' structure in the IPA context and
use it to perform translation between the C and the C++ API.
Update the IPAInterface::configure() operation to accept a new
CameraSensorInfo parameter and port all users of that function to
the new interface.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Define a map of static information associated with a media bus code.
Start by reporting the bits-per-pixel for each media bus code defined by
the V4L2 kernel API, to later expand it when necessary.
Add to the V4L2SubdeviceFormat class a method to return the bits per
pixel, retrieved by inspecting the static map of format information.
While at it, remove a rogue map inclusion from header file.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Expose V4L2Videodevice::setSelection() method and drop
V4L2Videodevice::setCrop() and V4L2Videodevice::setComopse() as wrapping
each target with a single function does not provide any benefit.
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>
Expose V4L2Subdevice::setSelection() method and drop
V4L2Subdevice::setCrop() and V4L2Subdevice::setComopse() as wrapping
each target with a single function does not provide any benefit.
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>
Use the sensor model to create the camera name. The resulting name
should still be "VIMC Sensor B", but prepares for support of Sensor A.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a new model() function to the CameraSensor class to report the
camera sensor model.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The V4L2Device::getControls() function takes a ControlList that needs to
be pre-populated with dummy entries for the controls that need to be
read. This is a cumbersome API, especially when reading a single
control. Make it nicer by passing the list of V4L2 controls as a vector
of control IDs, and returning a ControlList.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Add a new IPASettings class to pass IPA initialization settings through
the IPAInterface::init() method. The settings currently only contain the
name of a configuration file, and are expected to be extended later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
In order to provide pipeline handlers with IPA-related helpers on top of
IPAInterface, return the IPAProxy instance from IPAManager::createIPA().
No change is required in the pipeline handlers as the IPAInterface that
was previously returned is implemented by an IPAProxy instance already.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
IPA modules may require configuration files, which may be stored in
different locations in the file system. To standardize file locations
between all IPAs and pipeline handlers, provide a helper function to
locate a configuration file by searching in the following directories:
- All directories specified in the LIBCAMERA_IPA_CONFIG_PATH environment
variable ; or
- In the source tree if libcamera is not installed ; otherwise
- In standard system locations (etc and share directories).
When stored in the source tree, configuration files shall be located in
a 'data' subdirectory of their respective IPA directory.
More locations, or extensions to the mechanism, may be implemented
later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The message printed when loading a proxy worker from the build directory
is missing a space. Add it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Similarly to libcameraBuildPath(), there's a need to locate resources
within the source tree when running libcamera without installing it.
Support this use case with a new utils::libcameraSourcePath() function.
The implementation uses a symlink from the build root to the source root
in order to avoid hardcoding the path to the source root in the
libcamera.so binary.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The IPAModuleInfo::name field is currently a free-formed string that has
little use. Tighten its usage rules to make it suitable for building
file system paths to IPA-specific resources by matching the directory
name of the IPA module.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
