summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)Author
2024-08-21Documentation: Rework docs.rst into introduction.rstDaniel Scally
docs.rst is the landing page for the documentation from the libcamera website, but isn't particularly introductory. Move much of the content from guides/introduction.rst to docs.rst, which will serve as the new introductory page. Remove guides/introduction.rst. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Remove libcamera architecture from introduction.rstDaniel Scally
The libcamera Architecture section of the introduction is largely a duplicate of the section broken out from docs.rst. Remove it from the introduction.rst file and consolidate anything that wasn't duplicated into libcamera_architecture.rst and feature_requirements.rst. Take the opportunity to also expand the list of Platform Support which is now a bit out of date. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Breakout docs.rstDaniel Scally
In preparation for including more of the Documentation for libcamera on the website, break out the libcamera Architecture and Feature Requirements sections of docs.rst file into separate files for each section. Add all of the new files to documentation-contents.rst so they're included on the website too. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Synchronise camera stack detailsDaniel Scally
There are two near-duplicate instances of the camera stack details in the Documentation, in docs.rst and guides/introduction.rst. Remove them from guides/introduction.rst, with the exception of the explanations of the V4L2 Compatibility Layer and the Android HAL which are moved to the Camera Stack section in docs.rst. The Docs page already had its own separate version of those details but they are distinct and seemingly out of date - remove them. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Alphabetise the Documentation toctreeDaniel Scally
With the exception of the initial group of four links, alphabetise the pages in the Documentation toctree so adding new ones can be done in a defined order. Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Add documentation-contents.rstDaniel Scally
Add a new .rst file referencing the documentation contents. This file is then included in each documentation page so that we can enhance the Documentation pages on the libcamera website using it. As we do not want the appearance of the libcamera in-tree Documentation to change just yet, disable the new class using the sphinx theme's CSS. To facilitate easier distinguishing between "normal" and documentation pages on the website we want to add a "documentation" class to the content of all such pages. Since this new file will be included on each documentation page it is convenient to add the new directive here - do so. As the website uses different CSS to libcamera, move the contents on docs.rst a little so that the directive at the end of the contents block applies correctly. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-14Documentation: Improve doxygen main pageDaniel Scally
The "Main Page" of the doxygen generated API reference is currently totally empty. Expand it with some introductory text along with links to the developer's guide, application developer's guide and the pipeline and IPA module writer's guides. Provide an easy link to switch between the reduced public reference pages and the more complete internal ones. Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-14Documentation: Split public/private documentationDaniel Scally
The API reference pages generated by Doxygen are comprehensive, but therefore quite overwhelming for application developers who will likely never need to use the majority of the library's objects. To reduce the complexity of the documentation, split it into two runs of doxygen. The first run of doxygen is for the public API. We pass a specific list of source files to parse, which is built from the arrays of public headers and sources in meson build files. This ensures that we only generate the documentation for code from those files. A custom Python script is needed to add the list of input files to Doxyfile, as several of the objects included in the header and source array are custom_tgt objects, which can't be handled as strings to populate a variable in the configuration data. The headers defining the Extensible and Object classes (class.h and object.h respectively), as well as the corresponding source files, are excluded from the public API documentation despite being referenced in the meson public headers and sources arrays. This is due to the fact that public API classes inherit from Extensible and Object, making the Extensible and Object classes part of the public ABI. Those two base classes are however implementation details and must not be accessed directly by application code. The second run of doxygen is for the internal API. This contains documentation for all of the library's objects as it currently does. This set will now be output into build/Documentation/internal-api-html. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-14Documentation: Split doxygen_input in public and internal inputsLaurent Pinchart
To prepare for splitting the API documentation in public and internal documents, split the doxygen_input list in the public and internal counterparts. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-14Documentation: Add Thread safety pageDaniel Scally
Move the section of the Thread support page dealing with thread safety to a dedicated .dox file at Documentation/. This is done to support the splitting of the Documentation into a public and internal version. With a separate page, references can be made to thread safety without having to include the Thread class in the doxygen run. Some sections of the new page are still specific to internal implementations and so are hidden with the \internal flag and an internal section which is conditionally included. For now, hardcode it to be included in the Doxyfile. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-07libcamera: Split public and internal source arraysDaniel Scally
Meson array variables hold lists of libcamera's source files. To help facilitate the splitting of Doxygen generated documentation into distinct public and internal versions, split those arrays to separate public and internal variables. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Co-developed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Mark internal parts of public classes with \internalLaurent Pinchart
The libcamera public API exposes classes that have parts considered internal. They inherit the Extensible class, and their internal parts are split into a Private class. Those classes are defined in public API headers, and their Private counterparts are defined in internal headers sharing a common file name (in a different directory). Both headers are documented in the same source file. For instance, include/libcamera/camera.h contains the public API of the Camera class, and include/libcamera/internal/camera.h its internal counterpart. Both are documented in src/libcamera/camera.cpp. As the internal headers are not part of the public API, they need to be hidden from the future public API builds. To prepare for doing so, mark them with the \internal Doxygen directive. Hardcode the Doxygen INTERNAL_DOCS option to YES to include the internal API. This will be changed later for the public API documentation build. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-05libcamera: Remove spaces at end of linesLaurent Pinchart
Spaces at end of lines have cropped up in a few places in libcamera. Remove them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-01Document additional environmental variablesPablo Pita
* LIBCAMERA_IPA_PROXY_PATH: path to access a proxy IPA * LIBCAMERA_RPI_TUNING_FILE: used to pass tuning configuration data for the raspberry pi Signed-off-by: Pablo Pita <pablo.pita@gmail.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-21treewide: Query list of cameras just onceBarnabás Pőcze
This is more efficient since only a single vector will be constructed, and furthermore, it prevents the TOCTOU issue that might arise when the list of cameras changes between the two queries. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.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: 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-14Documentation: Add option to treat Doxygen warnings as errorsLaurent Pinchart
A new Doxygen warning introduced in a recent commit went unnoticed, both in manual tests and in CI. Unlike C/C++ warnings that are treated as errors, we don't fail the build with Doxygen warnings. This is due to the fact that the libcamera documentation compiles cleanly only with quite recent versions of Doxygen. Enabling the WARN_AS_ERROR Doxygen option unconditionally could bother many users. To improve the situation, add a meson option to treat Doxygen warnings as errors. The option is disabled by default, preserving the current behaviour, and will be enabled in CI builds. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-04-17Documentation: coding-style: Clean up header guard styleKieran Bingham
Header guards were replaced by pragma once calls with commits 0a64cf8b7645 ("libcamera: Convert to pragma once") through to 796210ecea82 ("v4l2: Convert to pragma once") Update the coding style to reflect the updated header guard style. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-04-16libcamera: Add "Software ISP benchmarking" documentationHans de Goede
Add a "Software ISP benchmarking" documentation section which describes the performance/power consumption measurements used during the Software ISP's development. Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> 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-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-03-05guides: pipeline-handler: Fix controlInfo_ initializationJacopo Mondi
Since commit b48db3c489d3 ("libcamera: controls: Create ControlInfoMap with ControlIdMap"), instances of the ControlInfoMap class need to be created with an instance of an unordered_map of ControlId to ControlInfo and with a ControlIdMap instance. The pipeline handler developer guide was never updated to reflect the change. Fix it. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-01-22Documentation: Update Qt documentation links to Qt 6Neal Gompa
The documentation is effectively the same, but we should be pointing to the actively supported and used Qt version. Signed-off-by: Neal Gompa <neal@gompa.dev> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-01-09Documentation: camera-sensor-model: Support Sphinx < 2.0Laurent Pinchart
The language argument to the code-block directive was mandatory in Sphinx before 2.0. Fix the few instances where no language is specified to support older versions of Sphinx. 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> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-12-07meson: Tag all installed filesLaurent Pinchart
Meson uses tags to sort installed files in categories, and makes it possible to install a subset of the files using the '--tags' argument to 'meson install'. This is typically used by distributions to split the runtime, development and documentation files into separate packages. By default, meson tries to guess the correct tag for installed files, but can't always do so properly. Mark the install targets that meson can't guess with the correct install_tag. As the feature has been introduced in meson 0.60, bump the minimum meson version. The latest LTS release of all major distributions that libcamera currently targets ship a recent enough meson version. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2023-11-30documentation: Document vendor specific controls and properties handlingNaushir Patuck
Add some documentation to the pipeline handler file describing how to implement and handle vendor specific controls and properties with a small example. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@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-28Documentation: Fix list indentationLaurent Pinchart
reStructuredText requires list items to be indented. Fix the few offenders in the documentation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-25Documentation: contributing: Integrate the code of conductLaurent Pinchart
Now that libcamera has an official code of conduct, mention it in the 'contributing' document with a clear indication that all community members are expected to follow the code of conduct. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-25Documentation: code-of-conduct: Add contact informationLaurent Pinchart
Replace the boilerplate "[INSERT EMAIL ADDRESS]" contact information with conduct@libcamera.org, and indicate that the people behind that e-mail address can also be contacted directly if needed. The direct contact information aims at offering more confidence to reporters than an anonymous mail alias in case they wish to report an issue with one of the core project members. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-25Documentation: code-of-conduct: Add license informationLaurent Pinchart
The Contributor Covenant is covered by the CC-BY-4.0 license. Indicate this in the file. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-25Documentation: code-of-conduct: Convert to reStructuredTextLaurent Pinchart
All documentation in libcamera is in reStructuredText format. Convert the code of conduct from Markdown. No change in the contents is intended. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-11-25Documentation: Add code of conductLaurent Pinchart
Communities have standards regarding behaviours they consider acceptable or not acceptable, and expect community members to follow those standards. libcamera is no different, even if it has never clearly expressed those standards in a formal code of conduct document. Like software licenses, codes of conduct can be written in a myriad of ways. And like software licenses, using a widely adopted code of conduct instead of writing our own can help bringing clarity. One such standard code of conduct is the Contributor Covenant, stewarded by the Organization for Ethical Source. The Contributor Covenant has been adopted by the freedesktop.org organization, which hosts a large number of projects historically related to graphics, and more recently to multimedia in general. freedesktop.org offers services such as git hosting with CI, which libcamera could benefit from. There is therefore a clear incentive to choose the same code of conduct as freedesktop.org, and no known drawback. As a first step towards this, and to keep the libcamera code of conduct history clear in git, copy the original Contributor Covenant v1.4 from https://github.com/EthicalSource/contributor_covenant/. "v1.4" is ambiguous as the document initially published as v1.4 has received small (but sometimes significant) modifications over time. The version imported here ([1]) is the most recent "v1.4", from tags/2.1 (commit 8a3be1350b07 "Merge pull request #979 from JustArchi/patch-2"). [1] https://github.com/EthicalSource/contributor_covenant/blob/2.1/content/version/1/4/code-of-conduct.md Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-10-23Documentation: Add figures to document OrientationJacopo Mondi
Add figures in Documentation/rotation/ to document the plane transformations defined by the Orientation enumeration. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-09-27Documentation: Introduce Camera Sensor ModelJacopo Mondi
Introduce a documentation page about the 'camera sensor model' implemented by libcamera. The camera sensor model serves to provide to applications a reference description of the processing steps that take place in a camera sensor in order to precisely control the sensor configuration through the forthcoming SensorConfiguration class. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.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>
2023-07-31Documentation: theme: Fix compilation with Sphinx >= 7.0.0Laurent Pinchart
Sphinx 7.0.0 has dropped support for the deprecated 'style' variable (https://github.com/sphinx-doc/sphinx/pull/11381). This breaks compilation of the documentation: /usr/bin/sphinx-build -D release=v0.1.0+16-eed6a079 -q -W -b html Documentation Documentation/html Theme error: An error happened in rendering the page api-html/index. Reason: UndefinedError("'style' is undefined") The recommended replacement is 'styles[-1]'. However, this resolves to '_static/css/theme.css', which is part of the 'css_styles' variable, and results in the stylesheet being included twice. To avoid that and fix the compilation error, simply drop the first reference. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-07-07meson: Fix space around colon issuesLaurent Pinchart
The meson style, which libcamera follows, recommends a space before colons in function parameters. Fix the style violations through the project. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2023-07-05Documentation: Add predefined macros from config.h to DoxyfileLaurent Pinchart
libcamera creates a config.h file with predefined macros, and instructs the compiler to include it implicitly with the -include argument. Doxygen has no support for implicit inclusion of headers, but has a PREDEFINED configuration option for its preprocessor that lists predefined macros. Populate it with the values from the config_h configuration data object that is used for generate the config.h file, to ensure that documentation matches the configuration options libcamera has been built with. Bump the minimum meson version to 0.57 to use cfg_data.keys(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-07-04libcamera: camera: Take span of StreamRole instead of vectorBarnabás Pőcze
Change the parameter type of `generateConfiguration()` from `const std::vector&` to `libcamera::Span`. A span is almost always preferable to a const vector ref because it does not force dynamic allocation when none are needed, and it allows any contiguous container to be used. A new overload is added that accepts an initializer list so that cam->generateConfiguration({ ... }) keeps working. There is no API break since a span can be constructed from a vector and the initializer list overload takes care of the initializer lists, but this change causes an ABI break. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [Kieran: Apply checkstyle fixups] Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-05-04pipeline: ipa: raspberrypi: Refactor and move the Raspberry Pi codeNaushir Patuck
Split the Raspberry Pi pipeline handler and IPA source code into common and VC4/BCM2835 specific file structures. For the pipeline handler, the common code files now live in src/libcamera/pipeline/rpi/common/ and the VC4-specific files in src/libcamera/pipeline/rpi/vc4/. For the IPA, the common code files now live in src/ipa/rpi/{cam_helper,controller}/ and the vc4 specific files in src/ipa/rpi/vc4/. With this change, the camera tuning files are now installed under share/libcamera/ipa/rpi/vc4/. To build the pipeline and IPA, the meson configuration options have now changed from "raspberrypi" to "rpi/vc4": meson setup build -Dipas=rpi/vc4 -Dpipelines=rpi/vc4 Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-05-04meson: ipa: Add mapping for pipeline handler to mojom interface fileNaushir Patuck
Allow an arbitrary mapping between the pipeline handler and IPA mojom interface file in the build system. This removes the 1:1 mapping of pipeline handler name to mojom filename, and allows more flexibility to pipeline developers. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-04-28Documentation: guides: pipeline-handler: Fix spelling errorBarnabás Pőcze
Both {Camera,PipelineHandler}::generateConfiguration() take a list of `StreamRole` objects, and not a list of `StreamRoles` objects. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-03-06Documentation: guides: pipeline-handler: Fix spelling errorAdvait Dhamorikar
The pipeline handler writers guide incorrectly references the VividCameradata::init() impelementation with a spelling error. Fix spelling of "impelementation" in the pipeline handler development guide. Signed-off-by: Advait Dhamorikar <advaitdhamorikar@gmail.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>
2023-02-12Documentation: Small typo fixPavel Machek
Out should really be output. Signed-off-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2023-01-31pipeline: raspberrypi: Read config parameters from a fileNaushir Patuck
Add the ability to read the platform configuration parameters from a config file provided by the user through the LIBCAMERA_RPI_CONFIG_FILE environment variable. Use the PipelineHandler::configurationFile() helper to determine the full path of the file. Provide an example configuration file named example.yaml. Currently two parameters are available through the json file: "min_unicam_buffers" The minimum number of internal Unicam buffers to allocate. "min_total_unicam_buffers" The minimum number of internal + external Unicam buffers that must be allocated. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2023-01-30documentation: sensor_drivers: Document H/V flipJacopo Mondi
Briefly document the optional requirement support for H/V flip controls. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
2023-01-05Documentation: Specify Doxygen OUTPUT_DIRECTORY explicitlyBarnabás Pőcze
Currently, doxygen is run by ninja in the top-level build directory, therefore the "Documentation" folder is always created there. However, when libcamera is built as a subproject, it should not touch the top-level build directory because it can cause conflicts and because the documentation won't be created where meson thinks it will be, so the "doxygen" target will always be dirty and installation will fail. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-12-12Documentation: contributing: Add commit message guidelinesLaurent Pinchart
All developers, whether junior or experienced, can benefit from improving their commit message writing skills. Add a paragraph to the contribution documentation to explain this, with a link to a good guide. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-11-23libcamera: Move IPA sensor controls validation to CameraSensorJacopo Mondi
The CameraSensor class validates that the sensor driver in use supports the controls required for IPA modules to work correctly. For in-tree IPA modules, whose pipeline handlers already use CameraSensor there's no need to validate such controls again. Remove controls validation from the IPU3 and RkISP1 IPA modules and rely on CameraSensor doing that at initialization time. The list of mandatory controls is expanded to add V4L2_CID_ANALOGUE_GAIN without which IPA modules cannot function. The new requirement only applies to RAW sensors, platforms like UVC and Simple are not impacted by this change. While at it, expand the sensor driver requirements documentation to include V4L2_ANALOGUE_GAIN in the list of mandatory controls a sensor driver has to support. 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-10-13meson: Shared Object version handlingKieran Bingham
The libcamera project is not yet ready to declare ABI nor API stability, but it will benefit the community to be able to provide more regular release cycles to determine 'versioned' points of history. Ideally, these releases will be made at any ABI breakage, but can be made at arbitary time based points along the way. To support releases which may not be ABI stable, declare the soversion of both the libcamera and libcamera-base library to be dependant upon both the major minor and patch component of the project version. As part of this, introduce a new 'Versions' summary section to highlight the different version components that may become apparent within any given build. Bumping versions may leave dangling libcamera.so.* symlinks in build directories. This will confuse Doxygen which will print during its directory scanning phase a warning that the symlink can't be read. As we don't need Doxygen to follow symlinks, disable it with EXCLUDE_SYMLINKS. Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>