summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
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>
2024-01-17include: linux: Update kernel headers to version v6.7Laurent Pinchart
Update kernel headers to v6.7 using utils/update-kernel-headers.sh and re-instating libcamera local modifications. The V4L2_SUBDEV_CAP_MPLEXED flag has been renamed to V4L2_SUBDEV_CAP_STREAMS in the upstream streams API. Adapt the code base accordingly. The flag's numerical value hasn't changed, there is no ABI breakage introduced by the API update. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-01-09build: controls: Add Raspberry Pi vendor specific controlsNaushir Patuck
Add a new control_ids_rpi.yaml file to hold the Raspberry Pi specific vendor controls. Define a control StatsOutputEnable to allow the ISP hardware statistics to be output through metadata via the Bcm2835StatsOutput control. The implementation of these controls will follow in a subsequent patch. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-30libcamera: controls: Use vendor tags for draft controls and propertiesNaushir Patuck
Label draft controls and properties through the "draft" vendor tag and deprecate the existing "draft: true" mechanism. This uses the new vendor tags mechanism to place draft controls in the same libcamera::controls::draft namespace and provide a defined control id range for these controls. This requires moving all draft controls from control_ids.yaml to control_ids_draft.yaml. One breaking change in this commit is that draft control ids also move to the libcamera::controls::draft namespace from the existing libcamera::controls namespace. This is desirable to avoid API breakages when adding new libcamera controls. So, for example, the use of controls::NOISE_REDUCTION_MODE will need to be replaced with controls::draft::NOISE_REDUCTION_MODE. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-29libcamera: control: Add vendor control id range reservationNaushir Patuck
Add a new control_ranges.yaml file that is used to reserve control id ranges/offsets for libcamera and vendor specific controls. This file is used by the gen-controls.py script to generate control id values for each control. Draft controls now have a separate range from core libcamera controls, breaking the existing numbering behaviour. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2023-11-29build: controls: Rework how controls and properties are generatedNaushir Patuck
Add support for using separate YAML files for controls and properties generation. The mapping of vendor/pipeline handler to control file is done through the controls_map variable in include/libcamera/meson.build. This simplifies management of vendor control definitions and avoids possible merge conflicts when changing the control_ids.yaml file for core and draft controls. With this change, libcamera and draft controls and properties files are designated the 'libcamera' vendor tag. In this change, we also rename control_ids.yaml -> control_ids_core.yaml and property_ids.yaml -> property_ids_core.yaml to designate these as core libcamera controls. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-29controls: Update argument handling for controls generation scriptsNaushir Patuck
The template file to the gen-controls.py and gen-py-controls.py is now passed in through the '-t' or '--template' command line argument instead of being a positional argument. This will allow multiple input files to be provided to the scripts in a future commit. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-29controls: Add vendor control/property support to generation scriptsNaushir Patuck
Add support for vendor-specific controls and properties to libcamera. The controls/properties are defined by a "vendor" tag in the YAML control description file, for example: vendor: rpi controls: - MyExampleControl: type: string description: | Test for libcamera vendor-specific controls. This will now generate a control id in the libcamera::controls::rpi namespace, ensuring no id conflict between different vendors, core or draft libcamera controls. Similarly, a ControlIdMap control is generated in the libcamera::controls::rpi namespace. A #define LIBCAMERA_HAS_RPI_VENDOR_CONTROLS is also generated to allow applications to conditionally compile code if the specific vendor controls are present. For the python bindings, the control is available with libcamera.controls.rpi.MyExampleControl. The above controls example applies similarly to properties. Existing libcamera controls defined in control_ids.yaml are given the "libcamera" vendor tag. A new --mode flag is added to gen-controls.py to specify the mode of operation, either 'controls' or 'properties' to allow the code generator to correctly set the #define string. As a drive-by, sort and redefine the output command line argument in gen-controls.py and gen-py-controls.py to ('--output', '-o') for consistency. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-10-23libcamera: transform: Make the transformFromOrientation() function staticLaurent Pinchart
Now that the transformFromOrientation() function isn't used outside of transform.cpp, make it static to remove it from the public API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2023-10-23libcamera: transform: Fold transformToOrientation() in its only callerLaurent Pinchart
The transformToOrientation() function is called from Orientation operator*(const Orientation &o, const Transform &t); only. Fold the code in the caller and drop the transformToOrientation() function to drop what can be considered as an ill-defined operation from the API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2023-10-23libcamera: camera_sensor: Cache mounting orientation instead of transformLaurent Pinchart
The cached rotationTransform_ value is used in computeTransform() only, to compute the mounting orientation. Cache the mounting orientation instead, removing the need for the intermediate conversion of the rotation to a transform. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2023-10-23libcamera: Use CameraConfiguration::orientationJacopo Mondi
Replace the usage of CameraConfiguration::transform with the newly introduced CameraConfiguration::orientation. Rework and rename the CameraSensor::validateTransform(transform) to CameraSensor::computeTransform(orientation), that given the desired image orientation computes the Transform that pipeline handlers should apply to the sensor to obtain it. Port all pipeline handlers to use the newly introduced function. This commit breaks existing applications as it removes the public CameraConfiguration::transform in favour of CameraConfiguration::orientation. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-10-23libcamera: transform: Add operations with OrientationJacopo Mondi
Add two operations that allows to combine Transform with Orientation. - Transform operator/(const Orientation &o1, const Orientation &o2) allows to easily get back the Transform that needs to be applied to Orientation2 to get Orientation1 - Orientation operator*(const Orientation &o, const Transform &t) allows to apply a Transform to an Orientation and obtain the combination of the two These two operations allow applications to use Transforms to manipulate the Orientation inside the CameraConfiguration, if they wish. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-10-23libcamera: transform: Add functions to convert OrientationJacopo Mondi
Add two helper functions to the transform.cpp file that allows to convert to and from an Orientation. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-10-23libcamera: camera: Introduce OrientationJacopo Mondi
Introduce the Orientation enumeration which describes the possible 2D transformations that can be applied to an image using two basic plane transformations. Add to the CameraConfiguration class a new member 'orientation' which is used to specify the image orientation in the memory buffers delivered to applications. The enumeration values follow the ones defined by the EXIF specification at revision 2.32, Tag 274 'orientation'. The newly introduced field is meant to replace CameraConfiguration::transform which is not removed yet not to break compilation. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>