summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2024-07-03libcamera: converter: Replace usage of stream index by Stream pointerUmang Jain
The converter interface uses the unsigned int output stream index to map to the output frame buffers. This is cumbersome to implement new converters because one has to keep around additional book keeping to track the streams with their correct indexes. The v4l2_converter_m2m and simple pipeline handler are adapted to use the new interface. This work roped in software ISP as well, which also seems to use indexes (although it doesn't implement converter interface) because of a common conversionQueue_ queue used for converter_ and swIsp_. The logPrefix is no longer able to generate an index from a stream, and is updated to be more expressive by reporting the stream configuration instead, for example, reporting "1920x1080-MJPEG" in place of "stream0". Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> # sm8250 RB5
2024-07-03converter: converter_v4l2_m2m: Rename private Stream classUmang Jain
Rename the private Stream class from V4L2M2MConverter::Stream to V4L2M2MConverter::V4L2M2MStream. This is done to improve readability of the code when we drop the handling of stream by indexes in a subsequent patch. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-06-25ipa: ipa_interface: Declare ipaCreate() in libcamera namespaceLaurent Pinchart
The ipaCreate() function is the entry point to IPA modules. It is declared in ipa_interface.h, and defined by each module. As the function is defined with extern "C" linkage, the namespace in which it is contained is not very relevant from a caller's point of view. For the IPA module implementer, however, defining the function in the libcamera namespace avoids adding an explicit libcamera:: prefix to the symbols used by the function. This is why all IPA modules define their ipaCreate() entry point in the libcamera namespace. The ipa_interface.h file, however, declares the function in the global namespace. This doesn't cause any issue at runtime, but will cause a missing declaration warning when we enable them. To prepare for that, move the function declaration to the libcamera namespace. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-25libcamera: base: log: Declare log categories when defining themLaurent Pinchart
libcamera will enable -Wmissing-declarations to catch mismatches between function declarations and definitions. There is one offender in log.h: when a category is defined with LOG_DEFINE_CATEGORY(), it generates a function with no declaration. Fix it by declaring the function using LOG_DECLARE_CATEGORY() as the first step of the category definition. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-24libcamera: yaml_parser: Add support for float typesLaurent Pinchart
The YamlObject::get<T>() function template has a specialization for double but not for float. When used in an IPA module, the issue is caught at module load time only, when dynamic links are resolved, causing errors such as Failed to open IPA module shared object: /usr/lib/libcamera/ipa_rkisp1.so: undefined symbol: _ZNK9libcamera10YamlObject6GetterIfE3getERK_ Fix it by adding a float specialization. The alternative would be to use double only in IPA modules, but the lack of enforcement at compile time makes this dangerous. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-06-16libcamera: yaml_parser: Delegate YamlObject::get() to helper structureLaurent Pinchart
The YamlObject::get() function is a function template that gets fully specialized for various types. This works fine for non-template types, but specializing it for template types (e.g. a std::vector<U>) would require partial template specialization, which C++ allows for classes and variables but not functions. To work around this problem, delegate the implementation to a new YamlObject::Getter structure template, which will support partial specialization. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-16libcamera: yaml_parser: Drop std::enable_if_t guards for get() functionLaurent Pinchart
The YamlObject::get() function template is implemented for a set of basic types through template specializations. The function declaration uses std::enable_if_t<> guards to signal incorrect usage at compilation time. This however prevents the API to be extended with additional specializations in other compilation units. To prepare for new specializations of the function for the ipa::Vector and ipa::Pwl classes types, implemented in their respective compilation units, drop the std::enable_it_t<> guards. Incorrect usage will still be reported as link errors. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-13libcamera: yaml_parser: Make default value templated in `get()`Barnabás Pőcze
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>
2024-06-04libcamera: DmaBufAllocator: Support allocating from /dev/udmabufHans de Goede
The dma-buf allocator currently allocates from CMA and system heaps. Extend the dma-buf allocator to support allocating dma-buffers by creating memfd-s and turning those into dma-buffers using /dev/udmabuf. The buffers allocated through memfd/udmabuf are not suitable for zero-copy buffer sharing with other devices. Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Lenovo-x13s Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-04libcamera: Rename DmaHeap class to DmaBufAllocatorHans de Goede
Users of the DmaHeap class really just want some way to allocate dma-buffers from userspace. This can also be done by using /dev/udmabuf instead of using /dev/dma_heap/*. Rename DmaHeap class to DmaBufAllocator in preparation of adding /dev/udmabuf support. And update the DmaHeap class docs to match including replacing references to "dma-heap type" with "dma-buf provider". This is a pure automated rename on the code ('s/DmaHeap/DmaBufAllocator/') + file renames + doc updates. There are no functional changes. The DmaBufAllocator objects in vc4.cpp and software_isp.cpp are left named dmaHeap_ to keep the changes to those 2 files to a minimum. Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Lenovo-x13s Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-03libcamera: v4l2_subdevice: Update to the new kernel routing APILaurent Pinchart
The subdev embedded data support series includes a change to the VIDIOC_SUBDEV_G_ROUTING and VIDIOC_SUBDEV_S_ROUTING ioctls that impacts the userspace API. Update to the new API, while preserving backward compatibility to ease the transition. Document the backward compatibility to only be supported for two kernel releases. As the routing API isn't enabled in any upstream kernel yet, users of the API need kernel patches, and are expected to be able to upgrade quickly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-03include: linux: Update kernel headers to version v6.10-rc1Hans de Goede
Updated kernel headers to v6.10-rc1 using utils/update-kernel-headers.sh and re-instating libcamera local modifications. This includes adding include/linux/udmabuf.h which was not part of libcamera's include/linux headers before. Signed-off-by: Hans de Goede <hdegoede@redhat.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>
2024-06-02libcamera: software_isp: Remove DebayerParams::kGain10Milan Zamazal
The constant is used in a single place internally and doesn't belong to DebayerParams anymore. Let's use 256 directly. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-06-02libcamera: software_isp: Move color mappings out of debayeringMilan Zamazal
Constructing the color mapping tables is related to stats rather than debayering, where they are applied. Let's move the corresponding code to stats processing. The same applies to the auxiliary gamma table. As the gamma value is currently fixed and used in a single place, with the temporary exception mentioned below, there is no need to share it anywhere anymore. It's necessary to initialize SoftwareIsp::debayerParams_ to default values. These initial values are used for the first two frames, before they are changed based on determined stats. To avoid sharing the gamma value constant in artificial ways, we use 0.5 directly in the initialization. This all is not a particularly elegant thing to do, such a code belongs conceptually to the similar code in stats processing, but doing better is left for larger refactoring. This is a preliminary step towards building this functionality on top of libipa/algorithm.h, which should follow. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-05-16libcamera: formats: Add PiSP specific image and config buffer formatsNaushir Patuck
Add the Raspberry Pi 5 PiSP specific compressed Bayer format types 1/2: - V4L2_PIX_FMT_PISP_COMP1_xxx - V4L2_PIX_FMT_PISP_COMP2_xxx Add the Raspberry Pi 5 PiSP Frontend and Backend config formats: - V4L2_META_FMT_RPI_FE_CFG - V4L2_META_FMT_RPI_BE_CFG Add the Raspberry Pi 5 PiSP Frontend statistics format: - V4L2_META_FMT_RPI_FE_STATS Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-16include: linux: Add PiSP specific image and config buffer formatsNaushir Patuck
Add the Raspberry Pi 5 PiSP specific compressed Bayer format types 1/2: - V4L2_PIX_FMT_PISP_COMP1_xxx - V4L2_PIX_FMT_PISP_COMP2_xxx Add the Raspberry Pi 5 PiSP Frontend and Backend config formats: - V4L2_META_FMT_RPI_FE_CFG - V4L2_META_FMT_RPI_BE_CFG Add the Raspberry Pi 5 PiSP Frontend statistics format: - V4L2_META_FMT_RPI_FE_STATS The corresponding changes submitted to the linux-media mailing list can be found at: (series "media: raspberrypi: Add support for PiSP Back End") https://lore.kernel.org/linux-media/20240502110503.38412-4-jacopo.mondi@ideasonboard.com/ https://lore.kernel.org/linux-media/20240502110503.38412-5-jacopo.mondi@ideasonboard.com/ and for the DRM mailing at: (patch "[RFC] drm/fourcc: Add RPI modifiers") https://lore.kernel.org/dri-devel/20240226153854.99471-1-jacopo.mondi@ideasonboard.com/ Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-16include: linux: Add RGB48 formatsNaushir Patuck
Add support for 16-bps (48-bpp) RGB output formats in the uapi headers. These new formats are defined for the RGB and BGR ordering. The corresponding change submitted to the linux-media and DRM mailing lists can be found at: https://lore.kernel.org/linux-media/20240502110503.38412-3-jacopo.mondi@ideasonboard.com/ and https://lore.kernel.org/dri-devel/20240226132544.82817-1-jacopo.mondi@ideasonboard.com/ respectively. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: camera_manager: Add environment variable to order pipelines matchJulien Vuillaumier
To match the enumerated media devices, each registered pipeline handler is used in no specific order. It is a limitation when several pipelines can match the devices, and user has to select a specific pipeline. For this purpose, environment variable LIBCAMERA_PIPELINES_MATCH_LIST is created to give the option to define an ordered list of pipelines to match on. LIBCAMERA_PIPELINES_MATCH_LIST="<name1>[,<name2>[,<name3>...]]]" Example: LIBCAMERA_PIPELINES_MATCH_LIST="rkisp1,simple" Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: pipeline: Add a get factory by name helperJulien Vuillaumier
Add a static helper to the PipelineHandlerFactoryBase class to allow retrieving a pipeline by name. Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: pipeline: Rename pipelines to a shorter nameJulien Vuillaumier
The PipelineHandlerFactoryBase class has a name that is propagated to the PipelineHandler instance it creates. In present implementation, this name comes from the REGISTER_PIPELINE_HANDLER registration macro. It corresponds to the stringified name of the PipelineHandler derived class. Therefore, PipelineHandler factories and instances names can be quite long such as "PipelineHandlerRkISP1". A libcamera user may have to explicitly refer to a PipelineHandler name for configuration purpose: one usage of the name can be to define a pipeline handlers match list and their priorities. It is desired, for user convenience, to use a short name to designate a pipeline handler. Reusing the short pipeline names already defined in the meson option files is an existing and consistent way of naming pipelines. This change adds an explicit name parameter to the REGISTER_PIPELINE_HANDLER registration macro. That parameter is used to define the name of a pipeline handler factory, instead of the current pipeline handler class name. Each pipeline registration is updated accordingly. The short name assigned corresponds to the pipeline directory name in the source tree. It is consistent with pipelines names used in meson. Changing the pipeline name has an impact on the IPA modules: each module defines a IPAModuleInfo structure. This structure has a pipelineName member defining the pipeline handler name it shall match with. Therefore, each internal IPA module definition has to be changed to have its IPAModuleInfo pipelineName name updated with the short pipeline handler name. In addition to this pipelineName member, the IPAModuleInfo structure also has a name member, associated to the IPA module name. Having renamed the pipelines to a short name, the pipeline name and the IPA module names of the IPAModuleInfo structure are the same: for in-tree IPA, they correspond to the respective pipeline and IPA subdirectories in the source tree. However the IPA name could be different, for instance with a close source IPA implementation built out-of-tree. Thus, it makes sense to keep the IPA name in that structure, as the 2 definitions may not always be redundant. Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> [Kieran: Adjust for clang-format style fix, reformat commitmsg] Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-09libcamera: Drop remaining file name from header comment blocksLaurent Pinchart
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>
2024-05-09libcamera: Drop file name from header comment blocks in templatesLaurent Pinchart
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 template files and templates embedded in generator scripts. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-05-08libcamera: Drop file name from header comment blocksLaurent Pinchart
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>
2024-05-08libcamera: controls: Generate enum value-name mapsDaniel Scally
Generate maps for each control enum which associate strings that represent the enum values with the values themselves. This change will allow us to refer to enumerated control values using the string. For example if we want to pass variables to an algorithm for use when a control has a particular value we can embed within tuning files a dictionary that uses the control values as keys. Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-20libcamera: Fix output spelling errorUmang Jain
There are two places where "output" is spelled as "ouput". Fix it. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: software_isp: Apply black level compensationMilan Zamazal
Black may not be represented as 0 pixel value for given hardware, it may be higher. If this is not compensated then various problems may occur such as low contrast or suboptimal exposure. The black pixel value can be either retrieved from a tuning file for the given hardware, or automatically on the fly. The former is the right and correct method, while the latter can be used when a tuning file is not available for the given hardware. Since there is currently no support for tuning files in software ISP, the automatic, hardware independent way, is always used. Support for tuning files should be added in future but it will require more work than this patch. The patch looks at the image histogram and assumes that black starts when pixel values start occurring on the left. A certain amount of the darkest pixels is ignored; it doesn't matter whether they represent various kinds of noise or are real, they are better to omit in any case to make the image looking better. It also doesn't matter whether the darkest pixels occur around the supposed black level or are spread between 0 and the black level, the difference is not important. An arbitrary threshold of 2% darkest pixels is applied; there is no magic about that value. The patch assumes that the black values for different colors are the same and doesn't attempt any other non-primitive enhancements. It cannot completely replace tuning files and simplicity, while providing visible benefit, is its goal. Anything more sophisticated is left for future patches. A possible cheap enhancement, if needed, could be setting exposure + gain to minimum values temporarily, before setting the black level. In theory, the black level should be fixed but it may not be reached in all images. For this reason, the patch updates black level only if the observed value is lower than the current one; it should be never increased. The purpose of the patch is to compensate for hardware properties. General image contrast enhancements are out of scope of this patch. Stats are still gathered as an uncorrected histogram, to avoid any confusion and to represent the raw image data. Exposure must be determined after the black level correction -- it has no influence on the sub-black area and must be correct after applying the black level correction. The granularity of the histogram is increased from 16 to 64 to provide a better precision (there is no theory behind either of those numbers). Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: Introduce SoftwareIspAndrey Konovalov
Doxygen documentation by Dennis Bonke. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Co-developed-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: ipa: Add Soft IPAAndrey Konovalov
Define the Soft IPA main and event interfaces, add the Soft IPA implementation. The current src/ipa/meson.build assumes the IPA name to match the pipeline name. For this reason "-Dipas=simple" is used for the Soft IPA module. Auto exposure/gain and AWB implementation by Dennis, Toon and Martti. Auto exposure/gain targets a Mean Sample Value of 2.5 following the MSV calculation algorithm from: https://www.araa.asn.au/acra/acra2007/papers/paper84final.pdf Use CameraSensorHelper to convert the analogue gain code read from the camera sensor into real analogue gain value. In the future this makes it possible to use faster AE/AGC algorithm. Right now the CameraSensorHelper lets us use the full range of analogue gain values. If there is no CameraSensorHelper for the camera sensor in use, a warning log message is printed. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Co-developed-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Dennis Bonke <admin@dennisbonke.com> Co-developed-by: Marttico <g.martti@gmail.com> Signed-off-by: Marttico <g.martti@gmail.com> Co-developed-by: Toon Langendam <t.langendam@gmail.com> Signed-off-by: Toon Langendam <t.langendam@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: software_isp: Add Debayer base classHans de Goede
Add a base class for debayer implementations. This is intended to be suitable for both GPU (or otherwise) accelerated debayer implementations as well as CPU based debayering. Doxygen documentation by Dennis Bonke. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Co-developed-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Dennis Bonke <admin@dennisbonke.com> Co-developed-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: software_isp: Add SwStatsCpu classHans de Goede
Add a CPU based SwStats implementation for SoftwareISP / SoftIPA use. This implementation offers a configure function + functions to gather statistics on a line by line basis. This allows CPU based software debayering to call into interleave debayering and statistics gathering on a line by line basis while the input data is still hot in the cache. This implementation also allows specifying a window over which to gather statistics instead of processing the whole frame. Doxygen documentation by Dennis Bonke. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Co-developed-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Co-developed-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz> Co-developed-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Dennis Bonke <admin@dennisbonke.com> Co-developed-by: Marttico <g.martti@gmail.com> Signed-off-by: Marttico <g.martti@gmail.com> Co-developed-by: Toon Langendam <t.langendam@gmail.com> Signed-off-by: Toon Langendam <t.langendam@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: shared_mem_object: Reorganize the code and document the ↵Andrei Konovalov
SharedMemObject class The SharedMemObject class template contains a fair amount of inline code that does not depend on the template types T. To avoid duplicating it in every template specialization, split that code to a separate base SharedMem class. We don't define copy semantics for the classes (we don't need one at the moment) and we make them non-copyable since the default copy constructor would lead to use-after-unmap. Doxygen documentation by Dennis Bonke and Andrei Konovalov. Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Co-developed-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Dennis Bonke <admin@dennisbonke.com> Signed-off-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: shared_mem_object: Rename SIZE constant to `size'Milan Zamazal
The SharedMemObject has been imported directly into the libcamera internal components. Adapt the SIZE constant of the class to match the libcamera coding style. Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: internal: Move SharedMemObject class to a common directoryAndrey Konovalov
Move SharedMemObject class out of RPi namespace and put it into include/libcamera/internal so that everyone could use it. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: dma_heaps: extend DmaHeap class to support system heapAndrey Konovalov
Add an argument to the constructor to specify dma heaps type(s) to use. Can be DmaHeapFlag::Cma and/or DmaHeapFlag::System. By default DmaHeapFlag::Cma is used. If both DmaHeapFlag::Cma and DmaHeapFlag::System are set, CMA heap is tried first. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-16libcamera: internal: Move dma_heaps.[h, cpp] to common directoriesAndrey Konovalov
DmaHeap class is useful outside the RPi pipeline handler too. Move dma_heaps.h and dma_heaps.cpp to common directories. Update the build files and RPi vc4 pipeline handler accordingly. Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s Tested-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: camera_sensor: Expose the Bayer orderLaurent Pinchart
Pipeline handlers may need to know the Bayer order produced by the sensor when a Transform is applied (horizontal or vertical flip). This is currently implemented manually in the Raspberry Pi pipeline handler. Move the implementation to the CameraSensor class to make it usable in other pipeline handlers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-03-15libcamera: camera_sensor: Reorder functionsLaurent Pinchart
The CameraSensor class has grown a lot since its creation, with many functions added for different types of purposes. They are not grouped by categories in the class definition, generating confusion when reading the header file. Improve readability by sorting functions by category: - Getters for static data (model, entity, focus lens, ...) - Format and sensor configuration accessors - Properties and controls (including test pattern mode) Update the .cpp file accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-03-15libcamera: camera_sensor: Drop updateControlInfo() functionLaurent Pinchart
The CameraSensor::updateControlInfo() function is a wrapper around the same function of the V4L2Subdevice class. It was meant to be called by pipeline handlers that modify the sensor configuration directly, bypassing the CameraSensor::setFormat() function. This never happened, and the function is called once only, internally to the CameraSensor class. No external users are foreseen, drop the function and call V4L2Subdevice::updateControlInfo() directly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Add V4L2Subdevice::Route structureLaurent Pinchart
The V4L2Subdevice class deals with streams in two places: - In routing tables, streams as expressed as a pad number and a stream number in a v4l2_subdev_route instance. - In the format and selection get and set functions, streams as expressed using the Stream structure, which binds the pad number and stream number. Expressing streams in different ways requires pipeline handlers and other helpers to convert between the two representations. This isn't much of an issue yet as libcamera has little stream-aware code, but it is expected to increasingly become a burden. To simplify the API, introduce a V4L2Subdevice::Route structure that mimicks the kernel v4l2_subdev_route structure but represents streams as V4L2Subdevice::Stream instances. This will improve seamless integration of routes, formats and selection rectangles. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Replace Routing::toString() with operator<<()Laurent Pinchart
The main (and only at the moment) use case for the Routing::toString() function is to print a representation of the routing table in a log message. The function is implemented using an std::stringstream, and the returned std::string is then inserted into an std::ostream. This is inefficient. Replace the function with a specialization of the operator<<() and use it in the caller. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Add stream support to get/set functionsLaurent Pinchart
Extend the V4L2Subdevice API with stream support for the functions that get and set formats and selection rectangles. Add a Stream structure to identify a subdev pad and stream, and use it to extend the V4L2Subdevice functions that get and set formats and selection rectangles with stream support. To preserve the existing pad-based API, implement overloaded functions that wrap the new stream-based API. This allows callers that are not stream-aware to use a simpler pad-based API, instead of having to explicitly set the stream number to 0 in all API calls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Rename V4L2SubdeviceFormat::mbus_code to codeLaurent Pinchart
The V4L2SubdeviceFormat::mbus_code member doesn't follow the libcamera coding style as it should use camelCase. Fix it by renaming it to just 'code', to shorten lines in addition to fixing the coding style. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Drop V4L2SubdeviceFormat::bitsPerPixel()Laurent Pinchart
The V4L2SubdeviceFormat::bitsPerPixel() function is just a wrapper around a MediaBusFormatInfo lookup. It made sense when the MediaBusFormatInfo class was not exposed outside of the compilation unit, but is now redundant. Drop it and use MediaBusFormatInfo in the only caller. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Extend MediaBusFormatInfo with metadata formatsLaurent Pinchart
Not all media bus formats describe image formats. Extend the MediaBusFormatInfo class with a type member to indicate if the format corresponds to image data or metadata, and add the (only) metatdata format supported by the kernel to the known mediaBusFormatInfo. The kernel doesn't (yet) have any metadata format specific to sensor embedded data. This is being addressed in the V4L2 API. In preparation for embedded data support, already introduce the EmbeddedData type here. Corresponding formats will be added when available. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-15libcamera: v4l2_subdevice: Expose media bus format info as internal APILaurent Pinchart
The V4L2SubdeviceFormatInfo structure, internal to the v4l2_subdevice.cpp compilation unit, contains information about media bus formats that will be useful in other parts of libcamera. To prepare for this, expose the structure in the v4l2_subdevice.h header and turn it into a class with a similar design as PixelFormatInfo. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-03-12libcamera: controls: Add policy parameter to ControlList::merge()Stefan Klug
This is useful in many cases although not included in the stl. Note: This is an ABI incompatible change. Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-02-27libcamera: utils: Add to_underlying() helper functionLaurent Pinchart
C++23 has a std::to_underlying() helper function that converts an enumeration value to its underlying type. Add a compatible implementation to the libcamera::utils namespace. 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> Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
2024-02-23include: linux: Add RKISP1_V_IMX8MP versionPaul Elder
Patches have been posted to the linux-media@vger.kernel.org mailing list to add i.MX8MP support to the rkisp1 driver ([1]). As no changes are expected to the userspace API in future versions of the series, add the RKISP1_V_IMX8MP version manually to the rkisp1-config.h header already. Once the patches get merged in the kernel, the changes will trickle down to libcamera with the next kernel headers update. [1] https://lore.kernel.org/linux-media/20240216095458.2919694-1-paul.elder@ideasonboard.com/ Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-01-25libcamera: object: Add and use thread-bound assertionLaurent Pinchart
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>
2024-01-25libcamera: signal: Replace object.h inclusion with forward declatationLaurent Pinchart
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>