summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2023-01-30libcamera: camera_sensor: Validate TransformJacopo Mondi
The two pipeline handlers that currently support Transform (IPU3 and RaspberryPi) implement it by operating H/V flips on the image sensor. Centralize the code that validates a Transform request against the sensor rotation capabilities in the CameraSensor class. The implementation in the IPU3 pipeline handler was copied from the RaspberryPi implementation, and is now centralized in CameraSensor to make it easier for other platforms. The CameraSensor::validateTransform() implementation comes directly from the RaspberryPi pipeline handler, no functional changes intended. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
2023-01-30libcamera: camera_sensor: Verify flips supportJacopo Mondi
During the camera sensor driver validation, verify if the sensor supports horizontal and vertical flips and store a flag as CameraSensor::supportFlips_ class member. The flag will be later inspected when applying flips. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
2023-01-10base: utils: Add and use strtod() helperLaurent Pinchart
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>
2022-12-14libcamera: pipeline: simple: converter: Use generic converter interfaceXavier Roumegue
Move the simple converter implementation to a generic V4L2 M2M class derived from the converter interface. This latter could be used by other pipeline implementations and as base class for customized V4L2 M2M converters. Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-12-14libcamera: Declare generic converter interfaceXavier Roumegue
Declare a converter Abstract Base Class intended to provide generic interfaces to hardware offering size and format conversion services on streams. This is mainly based on the public interfaces of the current converter class implementation found in the simple pipeline handler. The main change is the introduction of loadConfiguration() function which can be used by the concrete implementation to load hardware specific runtime parameters defined by the application. Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-29pipeline: ipa: raspberrypi: Use IPA cookiesNaushir Patuck
Pass an IPA cookie from the pipeline handler to the IPA and eventually back to the pipeline handler through the setDelayedControls signal. This cookie is used to index the RPiController::Metadata object to be used for the frame. The IPA cookie is then returned from DelayedControls when the frame with the applied controls has been returned from the sensor, and eventually passed back to the IPA from the signalIspPrepare signal. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Tested-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-11-28libcamera: v4l2_device: Workaround faulty control menusKieran Bingham
Some UVC cameras have been identified that can provide V4L2 menu controls without any menu items. This leads to a segfault where we try to construct a ControlInfo(Span<>,default) with an empty span. Convert the v4l2ControlInfo and v4l2MenuControlInfo helper functions to return std::optional<ControlInfo> to be able to account in the caller if the control is valid, and only add acceptable controls to the supported control list. Menu controls without a list of menu items are no longer added as a valid control and a warning is logged. This also fixes a potential crash that would have occured in the unlikely event that a ctrl.minimum was set to less than 0. Bug: https://bugs.libcamera.org/show_bug.cgi?id=167 Reported-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-25libcamera: stream: Turn StreamRole into scoped enumerationLaurent Pinchart
The StreamRole enum has enumerators such as 'Raw' that are too generic to be in the global libcamera namespace. Turn it into a scoped enum to avoid namespace clashes, and update users accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-11-25libcamera: stream: Add operator<<() to print StreamRole as a stringLaurent Pinchart
libcamera prints stream role values in log messages. To be more user-friendly, add a specialization of operator<<() to print the role name as a string instead of a numerical value. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-11-24libcamera: tracing: fix header generation when built as subprojectBarnabás Pőcze
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>
2022-11-23ipa: rkisp1: add FrameDurationLimits controlNicholas Roth
Currently, the Android HAL does not work on rkisp1-based devices because required FrameDurationLimits metadata is missing from the IPA implementation. This change sets FrameDurationLimits for rkisp1 based on the existing ipu3 implementation, using the sensor's reported range of vertical blanking intervals with the minimum reported horizontal blanking interval. Signed-off-by: Nicholas Roth <nicholas@rothemail.net> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-11-23ipa: rkisp1: Use IPAConfig in IPA::configure()Jacopo Mondi
The RkISP1 implementation of IPA::configure() still uses the legacy interface where sensor controls (and eventually lens controls) are passed from the pipeline handler to the IPA in a map. Since the introduction of mojom-based IPA interface definition, it is possible to define custom data types and use them in the interface definition between the pipeline handler and the IPA. Align the RkISP1 IPA::configure() implementation with the one in the IPU3 IPA module by using a custom data type instead of relying on a map to pass controls to the IPA. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-11-23pipeline: raspberrypi: Remove enum BuffferMask from the mojom interfaceNaushir Patuck
The BufferMask enum provides a way of identifying which stream a frame buffer belongs to. This enum is defined in the raspberrypi.mojom interface file. However, the IPA does not need these enum definitions to mmap buffers that it uses. Move this enum out of the raspberrypi.mojom interface file and put it into the RPi namespace visible only to the pipeline handler. This removes the need to include the auto-generated IPA interface header in the RPi::Stream definition. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-11-14libcamera: Add a PipelineHandler::releaseDevice methodDavid Plowman
This notifies pipeline handlers when a camera is released, in case they want to free any resources or memory buffers. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-11libcamera: base: semaphore: Apply clang thread safety annotationHirokazu Honda
This annotates member functions and variables of Semaphore by clang thread safety annotations. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-11-09libcamera: pipeline_handler: Return unique_ptr from generateConfiguration()Laurent Pinchart
The PipelineHandler::generateConfiguration() function allocates a CameraConfiguration instance and returns it. The ownership of the instance is transferred to the caller. This is a perfect match for a std::unique_ptr<>, which the Camera::generateConfiguration() function already returns. Update PipelineHandler::generateConfiguration() to match it. This fixes a memory leak in one of the error return paths in the IPU3 pipeline handler. While at it, update the Camera::generateConfiguration() function documentation to drop the sentence that describes the ownership transfer, as that is implied by usage of std::unique_ptr<>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-20libcamera: base: log: Fix LogCategory creation issuesTomi Valkeinen
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>
2022-10-20libcamera: base: log: Fix use of freed nameTomi Valkeinen
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>
2022-10-19ipc: ipa_data_serializer: Use cend() in deserializersPaul Elder
The overloaded deserializers functions that called the main deserializer function using iterators used cbegin() but end() instead of cend(). Make all of these use cend() instead. 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>
2022-10-18utils: ipc: Allow the skipHeader attribute on enumsPaul Elder
Currently, enums that are passed between pipeline handlers and their IPA must be defined in a mojom file. However, there is a use case for enum/flags to be defined in a C++ header, such that the enum can be used in a component other than the pipeline handler and its IPA. To support this, add support for the skipHeader attribute for enums. Like structs, it is only allowed in core.mojom. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18ipa: vimc: Add Flags to parametersPaul Elder
For the purpose of testing serializing/deserializing Flags in function parameters, add an enum class TestFlags and Flags<TestFlags> to some function parameters, both for input and output and Signals. While at it, update the ipa_interface_test. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18ipa: vimc: Add IPAOperationCode to init() parameter listPaul Elder
For the purpose of testing serializing/deserializing enums in function parameters, add IPAOperationCode to the parameter list of init(). Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18utils: ipc: Add support for FlagsPaul Elder
Add Flags<E> as a supported type in the IPA interface. It is used in mojom with the [flags] attribute. Any field or parameter type E that is prefixed with the [flags] attribute will direct the code generator to generate the type name "Flags<E>" and appropriate serialization/deserialization code for Flags<E> instead of for E. It is usable and has been tested in struct members, function input and output parameters, and Signal parameters. This does not add support for returning Flags as direct return values. Additionally, the [scopedEnum] attribute can be used on enum definitions, which will instruct the code generator to convert it to an enum class instead of a raw enum. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-18libcamera: ipa_data_serializer: Add serializer for FlagsPaul Elder
Implement an IPADataSerializer for Flags. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-18pipeline: ipa: raspberrypi: Add HBLANK control to DelayedControlsNaushir Patuck
Update CamHelper::getDelays() to return the sensor HBLANK delay. The HBLANK delay is set to the same value as VBLANK delay for all sensors in the Raspberry Pi IPA. Return the HBLANK gain delay from the IPA to the pipeline handler, and initialise DelayedControls to handle V4L2_CID_HBLANK with this delay value. As a drive-by, check that the V4L2_CID_HBLANK control is available when calling IPARPi::configure(). Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18camera_sensor: Add minimum and maximum line length to IPACameraSensorInfoNaushir Patuck
Add fields for minimum and maximum line length (in units of pixels) to the IPACameraSensorInfo structure. This replaces the existing lineLength field. Update the ipu3, raspberrypi and rkisp1 IPAs to use IPACameraSensorInfo::minLineLength instead of IPACameraSensorInfo::lineLength, as logically we will always want to use the fastest sensor readout by default. Since the IPAs now use minLineLength for their calculations, set the starting value of the V4L2_CID_HBLANK control to its minimum in CameraSensor::init(). Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-10libcamera: framebuffer: Move remaining private data to Private classLaurent Pinchart
Private members of the FrameBuffer class are split between FrameBuffer and FrameBuffer::Private. There was no real justification for this split, and keeping some members private in the FrameBuffer class causes multiple issues: - Future modifications of the FrameBuffer class without breaking the ABI may be more difficult. - Mutable access to members that should not be modified by applications require a friend statement, or going through the Private class. Move all remaining private members to the Private class to address the first issue, and add a Private::metadata() function to address the second problem. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10libcamera: base: utils: Drop defoptLaurent Pinchart
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>
2022-10-07libcamera: controls: Construct Span with size for array controlsLaurent Pinchart
The ControlList::set() function overload used for array controls constructs a Span from an initializer list. It doesn't specify the Span size explicitly, which results in a dynamic extent Span being constructed. That causes a compilation failure for fixed-size array controls, as they are defined as Control<T> with T being a fixed-extent Span, and conversion from a dynamic-extent to fixed-extent Span when calling ControlValue::set() can't be implicit. Fix this by constructing the Span using the size of the control, which resolves to a fixed-extent and dynamic-extent Span for fixed-size and dynamic-size array controls respectively. The ControlList::set() function that takes an initializer list can then be used for fixed-size array controls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07libcamera: pipeline_handler: Implement factories through class templatesLaurent Pinchart
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits from the PipelineHandlerFactory class, and implements a constructor and a createInstance() function. Replace the code generation through macro with the C++ equivalent, a class template, as done in libipa with the Algorithm and CameraSensorHelper factories. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Return unique_ptr from createInstanceLaurent Pinchart
Avoid naked pointer with memory allocation by returning a unique_ptr from PipelineHandlerFactory::createInstance(), in order to increase memory allocation safety. This allows iterating over factories in the CameraManager and unit tests using const pointers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Make registerType() privateLaurent Pinchart
The PipelineHandlerFactory::registerType() function is called by the PipelineHandlerFactory class only. Make it private. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Make factory create() function constLaurent Pinchart
The PipelineHandlerFactory::create() function has no need to modify the factory instance. Make it const, as well as the createInstance() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: camera_manager: Rename parameter to get()Laurent Pinchart
The CameraManager::get() function takes a string containing the ID of the requested camera. This is correctly documented and implemented in the .cpp file, but the header file names the parameter 'name' instead of 'id'. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-30android: Add missing SPDX headers to Android headersLaurent Pinchart
Most headers imported from Android have an SPDX tag (added manually in commit 190bebef0840), but four headers that have been imported more recently are missing license identifiers. Fix them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-12libcamera: controls: initialise control info to ControlTypeNone by defaultChristian Rauch
The default ControlInfo constructor allows partially initialising the min/max/def values. Uninitialised values are assigned to 0 by default. This implicit initialisation makes it impossible to distinguish between an uninitialised and an explicitly 0-initialised ControlValue. Default construct the ControlValue in the ControlInfo default contructor to explicitly represent uninitialised values by the ControlTypeNone type. Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-12libcamera: control_serializer: store/load all ControlValue typesChristian Rauch
The min/max/def ControlValue of a ControlInfo can take arbitrary types that are different from each other and different from the ControlId type. The serialiser serialises these ControlValue separately by their type but does not store the type. The deserialiser assumes that ControlValue types match the ControlId type. If this is not the case, deserialisation will try to deserialise values of the wrong type. Fix this by serialising each of the min/max/def ControlValue's ControlType and storing it just before the serialised ControlValue. Fixes: https://bugs.libcamera.org/show_bug.cgi?id=137 Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> Tested-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-08libcamera: v4l2_subdevice: Silence warning for unknown metadata formatsLaurent Pinchart
Commit e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on pixel format") has introduced a warning when trying to convert a color space from V4L2 to libcamera if the media bus code is unknown. This was meant to catch unknown image formats, but turned out to be also triggered for metadata formats. Color spaces are not applicable to metadata formats, there should thus be no warning. Fix it by skipping the color space translation and returning std::nullopt directly if the kernel reports V4L2_COLORSPACE_DEFAULT. This doesn't introduce any change in behaviour other than getting rid of the warning, as the V4L2Device::toColorSpace() function returns std::nullopt already in that case. Fixes: e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on pixel format") Reported-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
2022-09-01libcamera: color_space: Move color space adjustment to ColorSpace classUmang Jain
The CameraConfiguration::validateColorSpaces() function performs color space validation on a camera configuration, by validating the color space of each stream individually, and optionally ensuring that all streams share the same color space. The individual validation is very basic, limited to ensuring that raw formats use a raw color space. Color spaces are more constrained than that: - The Y'CbCr encoding and quantization range for RGB formats must be YcbcrEncoding::None and Range::Full respectively. - The Y'CbCr encoding for YUV formats must not be YcbcrEncoding::None. Instead of open-coding these constraints in the validateColorSpaces() function, create a new ColorSpace::adjust() function to centralize color space validation and adjustment, and use it in validateColorSpaces(). Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 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>
2022-09-01libcamera: v4l2_videodevice: Improve toColorSpace() readabilityUmang Jain
Wrap V4L2Device::toColorspace() inside a private static member function in V4L2VideoDevice class. It improves readability in setting the colorspace for V4L2DeviceFormat. No functional changes intended. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-01libcamera: v4l2_device: Adjust colorspace based on pixel formatUmang Jain
V4L2 has no "none" YCbCr encoding, and thus reports an encoding for all formats, including RGB and raw formats. This causes the libcamera ColorSpace to report incorrect encodings for non-YUV formats. Fix it by overriding the encoding reported by the kernel to YCbCrEncoding::None for non-YUV pixel formats and media bus formats. Similarly, override the quantization range of non-YUV formats to full range, as limited range isn't used for RGB and raw formats. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-31libcamera: request: Rename Private::reuse() to Private::reset()Umang Jain
The Request::Private::reuse() is different from Request::reuse(). It resets the members of Request::Private to default values hence, rename it to a more appropriate Request::Private::reset(). Update the usage and documentation accordingly. 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>
2022-08-31libcamera: base: signal: Disable connect() for functor if args mismatchLaurent Pinchart
If a pointer-to-member is passed to the Signal::connect() function with arguments that don't match the Signal type, the pointer-to-member version of connect() will not match during template argument resolution, but the functor version will. This results in a compilation error in the BoundMethodFunctor class, due to the pointer-to-member not being a functor and thus not being callable directly. The error messages are quite cryptic. With the following error applied, diff --git a/test/signal.cpp b/test/signal.cpp index 5c6b304dac0b..6dd11ac45313 100644 --- a/test/signal.cpp +++ b/test/signal.cpp @@ -107,6 +107,7 @@ protected: /* Test signal emission and reception. */ called_ = false; signalVoid_.connect(this, &SignalTest::slotVoid); + signalVoid_.connect(this, &SignalTest::slotInteger1); signalVoid_.emit(); if (!called_) { gcc outputs ../../include/libcamera/base/bound_method.h: In instantiation of ‘R libcamera::BoundMethodFunctor<T, R, Func, Args>::activate(Args ..., bool) [with T = SignalTest; R = void; Func = void (SignalTest::*)(int); Args = {}]’: ../../include/libcamera/base/bound_method.h:143:4: required from here ../../include/libcamera/base/bound_method.h:146:37: error: must use ‘.*’ or ‘->*’ to call pointer-to-member function in ‘((libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>*)this)->libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::func_ (...)’, e.g. ‘(... ->* ((libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTes t::*)(int)>*)this)->libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::func_) (...)’ 146 | return func_(args...); | ~~~~~^~~~~~~~~ and clang isn't much better: ../../include/libcamera/base/bound_method.h:146:11: error: called object type 'void (SignalTest::*)(int)' is not a function or function pointer return func_(args...); ^~~~~ ../../include/libcamera/base/bound_method.h:137:2: note: in instantiation of member function 'libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::activate' requested here BoundMethodFunctor(T *obj, Object *object, Func func, ^ ../../include/libcamera/base/signal.h:80:27: note: in instantiation of member function 'libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::BoundMethodFunctor' requested here SignalBase::connect(new BoundMethodFunctor<T, void, Func, Args...>(obj, nullptr, func)); ^ ../../test/signal.cpp:110:15: note: in instantiation of function template specialization 'libcamera::Signal<>::connect<SignalTest, void (SignalTest::*)(int), nullptr>' requested here signalVoid_.connect(this, &SignalTest::slotInteger1); ^ Improve error reporting by disabling the functor version of connect() when the Func argument isn't invocable with the Signal arguments. gcc will then complain with ../../test/signal.cpp:110:36: error: no matching function for call to ‘libcamera::Signal<>::connect(SignalTest*, void (SignalTest::*)(int))’ 110 | signalVoid_.connect(this, &SignalTest::slotInteger1); | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and clang with ../../test/signal.cpp:110:15: error: no matching member function for call to 'connect' signalVoid_.connect(this, &SignalTest::slotInteger1); ~~~~~~~~~~~~^~~~~~~ which are more readable. This change requires usage of std::is_invocable<>, which is only available starting in C++17. This is fine for usage of the Signal class within libcamera, as the project is compiled with C++17, but we try to keep the public API compatible C++14. Condition the additional checks based on the C++ version. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-08-26libcamera: color_space: Add fromString() functionLaurent Pinchart
Add a ColorSpace:fromString() function to parse a string into a color space. The string can either contain the name of a well-known color space, or four color space components separate by a '/' character. 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>
2022-08-26utils: Satisfy LegacyInputIterator with StringSplitter::iteratorLaurent Pinchart
The StringSplitter::iterator is used with the utils::split() function to iterate over components of a split string. Add the necessary member types expected by std::iterator_trait in order to satisfy the LegacyInputIterator requirement and make the iterator usable in constructors for various containers. 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>
2022-08-25libcamera: color_space: Rename Jpeg to SyccLaurent Pinchart
The JPEG color space is badly name, as the JPEG specification (ITU-T T.81) doesn't define any particular color space: The interchange format does not specify a complete coded image representation. Application-dependent information, e.g. colour space, is outside the scope of this Specification. The JFIF specification (ITU-T T.871) is clearer as it requires ITU-R BT.601 YCbCr encoding and a full quantization range: The interpretations of Y, CB, and CR are derived from the E'Y, E'Cb, and E'Cr signals defined in the 625-line specification of Rec. ITU-R BT.601, but these signals are normalized so as to permit the usage of the full range of 256 levels of the 8-bit binary encoding of the Y component. It however doesn't specify color primaries or a transfer function explicitly. It only mentions the latter when describing the conversion from YCbCr to RGB: The inverse relationship for computing full scale 8-bit per colour channel gamma pre-corrected RGB values (following Rec. ITU-R BT.601 gamma pre-correction and colour primary specifications) from YCbCr colours (with 256 levels per component) can be computed as follows: [...] Given that ITU-R BT.601-5 (1995) didn't specify color primaries or a transfer function, and that the later ITU-R BT.601-7 (2011) version specifies color primaries for the 625-line variant that do not match sRGB, the JPEG color space in libcamera is badly named. This is confirmed by ITU-T T.871: As this Recommendation | International Standard is based on the prior informally-circulated JFIF version 1.02 specification that was produced in 1992, which referenced Rec. ITU-R BT.601 (formerly CCIR 601), it references that specification for definition of the E'Y, E'Cb, and E'Cr signals that correspond to the YCBCR values specified herein. However, since the development of the prior JFIF version 1.02 specification, additional industry specifications have been developed, Rec. ITU-R BT.601 has been updated, and common industry practice has emerged which often follows the sYCC specification in IEC 61966-2-1/Amd.1. The difference between the use of the colour interpretation specification in this Recommendation | International Standard and that of the sYCC specification may be considered negligible in practice. Rename the color space to sYCC, as its definition matches the sYCC standard, and indicate that it is typically used to encode JPEG images. 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>
2022-08-21libcamera: yaml_parser: Enable YamlObject::get() for int8_t and uint8_tLaurent Pinchart
The YamlObject::get() function template is implemented for 16-bit and 32-bit integers. Add an 8-bit specialization that will be used in the rkisp1 IPA module, and extend the unit tests accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-16libcamera: base: Make message.h and mutex.h privateLaurent Pinchart
The message.h and mutex.h headers are not used in the libcamera public API. Make them private to avoid there usage in applications, and to prevent having to maintain them with a stable ABI. As mutex.h is used by libcamerasrc, the GStreamer element must switch from the libcamera_public to the libcamera_private dependency. 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>
2022-08-10libcamera: Allow concurrent use of cameras from same pipeline handlerLaurent Pinchart
libcamera implements a pipeline handler locking mechanism based on advisory locks on media devices, to prevent concurrent access to cameras from the same pipeline handler from different processes (this only works between multiple libcamera instances, as other processes won't use advisory locks on media devices). A side effect of the implementation prevents multiple cameras created by the same pipeline handler from being used concurrently. Fix this by turning the PipelineHandler lock() and unlock() functions into acquire() and release(), with a use count to replace the boolean lock flag. The Camera class is updated accordingly. As a consequence of this change, the IPU3 pipeline handler will fail to operate properly when the cameras it exposes are operated concurrently. The android.hardware.camera2.cts.MultiViewTest#testDualCameraPreview test fails as a result. This should be fixed in the IPU3 pipeline handler to implement mutual exclusion between cameras. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: David Plowman <david.plowman@raspberrypi.com>
2022-08-10libcamera: formats: Fix warning for unknown V4L2 pixfmtJacopo Mondi
Commit f25ad4a2b16b ("libcamera: formats: Reimplement V4L2 PixelFormatInfo::info()") changed the PixelFormatInfo::info(const V4L2PixelFormat &format) function overload to: return info(format.toPixelFormat()); As part of the series that contains such commit, the PixelFormatInfo for the pixel format applied to a video device is now retrieved at V4L2VideoDevice::open() time. Some video devices register formats not available to applications, for example metadata formats or, in the case of ISP devices, formats to describe the ISP statistics and parameters. This causes the format.toPixelFormat() call to output a WARN message, which spams the log and unnecessarily alerts the users. Augment V4L2PixelFormat::toPixelFormat() with an optional argument to suppress warnings in the case a V4L2 pixel format is not known, to restore the behaviour preceding commit f25ad4a2b16b and returns an invalid PixelFormatInfo without outputting any unnecessary warning message. Fixes: f25ad4a2b16b ("libcamera: formats: Reimplement V4L2 PixelFormatInfo::info()") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>