summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-08-27ipa: rkisp1: Add compand feature flag to ipa contextPaul Elder
Add a compand feature flag to the hardware settings section of the IPA context, so that we can act accordingly for black level subtraction, and to pave the way to skipping companding appropriately when support for it is added. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> 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-08-27ipa: rkisp1: params: Add companding blocksLaurent Pinchart
Extend the RkISP1 parameters helper with support for the new companding blocks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27pipeline: rkisp1: Use the extensible parameters formatJacopo Mondi
Now that the IPA module supports the extensible parameters format, switch to it when available. If the kernel driver doesn't support the new format, setFormat() will adjust paramFormat to the legacy format, which will be passed to the IPA module, preserving backward compatibility. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27ipa: rkisp1: Use the new ISP parameters abstractionLaurent Pinchart
Use the new ISP parameters abstraction class RkISP1Params to access the ISP parameters in the IPA algorithms. The class replaces the pointer to the rkisp1_params_cfg structure passed to the algorithms' prepare() function, and is used to access individual parameters blocks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: Add ISP parameters abstraction classLaurent Pinchart
Individual algorithms of the rkisp1 IPA module access their corresponding ISP parameters through the top-level structure rkisp1_params_cfg. This will not work anymore with the new parameters format. In order to ease the transition to the new format, abstract the ISP parameters in a new RkISP1Params class that offers the same interface regardless of the format. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27ipa: rkisp1: Pass parameters buffer size to pipeline handlerJacopo Mondi
The ISP parameters buffer currently has a fixed payload size, which is hardcoded in the pipeline handler. To prepare for support of the extensible parameters format that has a variable payload size, pass the size from the IPA module to the pipeline handler explicitly. Keep the size hardcoded to sizeof(struct rkisp1_params_cfg) for now, this will be udpated later. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27ipa: rkisp1: Pass parameters buffer format to IPA moduleLaurent Pinchart
The rkisp1 driver supports two formats for the ISP parameters buffer, the legacy fixed format and the new extensible format. In preparation of support for the new format, pass the parameters buffer format from the pipeline handler to the IPA module and store it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-27include: linux: Update headers for rkisp1 extensible parametersJacopo Mondi
Update the kernel headers with the definitions for the rkisp1 extensible parameters format. The headers have been generated from the most recent linux-media stage tree master branch, at commit a043ea54bbb9 ("Merge tag 'next-media-rkisp1-20240814' of git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux.git"). Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-08-27utils: update-kernel-headers: Support relative path to kernel git treeLaurent Pinchart
When given a relative path to the kernel git tree, update-kernel-headers.sh fails to execute the headers_install.sh script from the kernel sources. Fix it by turning the kernel directory into an absolute path. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-08-25Documentation: Fix links from API references to guidesDaniel Scally
The links on the API reference mainpage to guides within the main libcamera documentation work built locally, but not through the website. As the website's more important make them work with the website paths as a temporary solution until a better one is devised. Fixes: e93886178106 ("Documentation: Improve doxygen main page") 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-25Documentation: Fix link to introduction on mainpage.doxDaniel Scally
With the removal of guides/introduction.rst the link on the API reference landing page no longer works. Point it to the documents introduction page instead. Fixes: 860a3e30319c ("Documentation: Rework docs.rst into introduction.rst") 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-25libcamera: controls: Fix example for ExposureValueFang Hui
EV = [-2, -1, 0.5, 0, 0.5, 1, 2] should change to EV = [-2, -1, -0.5, 0, 0.5, 1, 2] Signed-off-by: Fang Hui <hui.fang@nxp.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-25libcamera: pipeline_handler: Call releaseDevice() before unlocking media devicesHans de Goede
It is better / more logical to call releaseDevice() before unlocking the devices. At the moment the only pipeline handler implementing releaseDevice() is the rpi pipeline handler which releases buffers from its releaseDevice() implementation. Releasing buffers before unlocking the media devices is ok to do and arguably it is better to release the buffers before unlocking. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-25libcamera: pipeline_handler: Fix unlocking media devices too earlyHans de Goede
PipelineHandler::acquire() only locks the media devices when the first camera is acquired. If a second camera of a pipeline is acquired only useCount_ is increased and nothing else is done. When releasing cameras PipelineHandler::release() should only unlock the media devices when the last camera is released. But the old code unlocked on every release(). Fix PipelineHandler::release() to only release the media devices when the last camera is released. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-21Documentation: Rename "Documentation" section to "Introduction"Laurent Pinchart
The introduction.rst file contains the introduction to the libcamera documentation. Rename the section from "Documentation" to "Introduction". Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-21Documentation: Drop local table of contents from introductionLaurent Pinchart
The local table of contents from the introduction page doesn't provide much navigation value as the page is short. It also stands out, as no other page has a local table of contents. Drop it, we will reintroduce local tables of contents more globally if needed later. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-21Documentation: Rename "API" section to "API Reference"Laurent Pinchart
"API" as a section name is as informative as it is long, that is to say, not very. Rename it to "API Reference" for improved clarity. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-21Documentation: Reformat documentation_contents.rstDaniel Scally
Now that documentation_contents.rst serves as a navbar for the docs pages on the website, reformat it to present the links in a more logical order. The list is split into three sections for Users, Developers and System Integrators, with a slight break between each section and a header above the links. 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: Add internal-api-html placeholderDaniel Scally
Mimicking the existing api-html placeholder, add a placeholder for the internal version of the Doxygen generated API documentation so that the website can generate hyperlinks to it properly. 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: Rework index.rstDaniel Scally
index.rst is the page that becomes index.html, but currently just has some blurb. Although this page will only be seen if viewing the docs as built from the libcamera tree it'd be better if it were more of an introductory page. Include the content of docs.rst to improve it. As we're no longer including the content from README.rst the labels that enabled that can be dropped. With this change whether viewing the documentation as built in the libcamera tree or on the Docs page of the website, the landing content will be the same. The CSS for the documentation's theme currently hides the toctree from the generated body in html, as it's already displayed on every page via the theme's CSS. This change reorders the page such that the CSS that hides the toctree no longer works - update the CSS to retain the current behaviour. 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: 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-16libcamera: controls: Improve formatting of control descriptions in YAMLLaurent Pinchart
The control descriptions from YAML files are extracted to generate Doxygen documentation blocks for the controls, which are then compiled to HTML. The extraction script uses the first line of the description as the Doxygen \brief, and preserves blank lines to keep paragraphs. The control descriptions in the YAML files have however not all been written with this in mind. Many description elements are not formatted as block string scalars, in the first place, so blank lines are lost when parsing YAML. Furthermore, they often start with a long initial paragraph, making the \brief description very long. Improve the documentation formatting by marking all multiline descriptions as block string scalars, and try to provide a short one-line first paragraph to be used as a \brief. While at it, reflow the documentation to the 80 columns limit. The draft controls are left as-is, as they should evolve to non-draft controls eventually (and ideally sooner than later). 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-16py: gen-py-controls: Convert to jinja2 templatesLaurent Pinchart
Jinja2 templates help separate the logic related to the template from the generation of the data. The python code becomes much clearer as a result. As an added bonus, we can use a single template file for both controls and properties. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Acked-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16py: gen-py-controls: Use Control classLaurent Pinchart
Replace manual extraction of data from YAML with the Control helper class. This centralizes YAML parsing and avoids manual mistakes. In order to import the controls module, add the utils/codegen/ directory to the PYTHONPATH through the Python build environment. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16utils: codegen: gen-controls.py: Move helper classes to separate fileLaurent Pinchart
The ControlEnum and Control helper classes defined in gen-controls.py are useful for other generator scripts. Move them to a separate file to make it possible to share them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-16utils: codegen: gen-controls.py: Convert to jinja2 templatesLaurent Pinchart
Jinja2 templates help separate the logic related to the template from the generation of the data. The python code becomes much clearer as a result. As an added bonus, we can use a single template file for both controls and properties. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16utils: codegen: gen-header.sh: Generate libcamera.h based on meson.buildLaurent Pinchart
The libcamera.h header is a top-level library header that contains every other libcamera header. It is currently generated by listing the files in include/libcamera/ and dropping the .in suffix from template files. This assumes a 1:1 mapping between generated header file names and the name of their templates. Drop that assumption and base the libcamera.h generation on the libcamera public headers listed in meson.build. This makes the libcamera.h header generation more future-proof. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-16meson: utils: Provide environment for Python scriptsLaurent Pinchart
Python scripts run as part of the build process need to take a few actions specific to the environment in which they operate. One of those is disabling the Python bytecode cache, to avoid writing .pyc files to the source tree. This is done manually in the IPC generate.py and parser.py scripts. The current implementation is not ideal because it hardcodes in the scripts information related to the environment in which they operate. As those scripts are part of libcamera this is more of a theoretical issue than a practical one. A second issue is that future Python scripts will need to duplicate similar mechanisms, resulting in a higher maintenance burden. Address the issue with a different approach, by creating a meson environment for the Python scripts, and passing it to the custom_target() functions. The environment only disables the bytecode cache for now. The diffstat shows an increase in code size. This is expected to be offset by usage of the environment for more Python scripts, as well as support of more variables in the environment. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15meson: Move all code generation scripts to utils/codegen/Laurent Pinchart
We have multiple code generation scripts in utils/, mixed with other miscellaneous utilities, as well as a larger code base based on mojom in utils/ipc/. To make code sharing easier between the generator scripts, without creating a mess in the utils/ directory, move all the code generation code to utils/codegen/. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15libcamera: Drop remaining file names from header comment blocksLaurent Pinchart
Commit 829acb3ab0b1 ("libcamera: Drop file name from header comment blocks in templates") dropped file names from header comment blocks in templates, but forgot the control and property .cpp templates. Fix it. Fixes: 829acb3ab0b1 ("libcamera: Drop file name from header comment blocks in templates") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15meson: Fix mismatch in controls and properties generated file namesLaurent Pinchart
The header for controls and properties are generated from the control_ids.h.in and property_ids.h.in templates respectively, and the generated files are named control_ids.h and property_ids.h. For sources, the templates are named control_ids.cpp.in and property_ids.cpp.in, but the output files are named controls_ids.cpp and properties_ids.cpp. This discrepancy causes confusion. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-15meson: Store controls and properties YAML files in variablesLaurent Pinchart
When generating control headers, the YAML files to be used are determined dynamically based on the selected pipeline handlers. As part of this process, the build system populates an array of meson File objects used as an input for the control headers generation custom target, as well as an array of file names (as strings). The file names array is later used to generate the control source files for the libcamera core, as well as the source code for controls support in the Python bindings. Both of the source code generators manually turn the array of file names into File objects. This duplicates code and reduces readability. A third similar implementation has also been proposed to generate control support sources in the GStreamer element, making the issue worse. To simplify this, store File objects instead of file names in the controls_files array. As the meson configuration summary doesn't support File objects, create a separate controls_files_names to store the file names for that sole purpose. The exact same process occurs for properties, address them the same way. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-14utils: tuning: Change Tuner.add() to accept a list of modulesStefan Klug
Change the first parameter of Tuner.add() to accept either a list of modules or a single module. This allows more compact code and is in sync with Tuner.set_output_order(). Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-14utils: tuning: rkisp1: Clean up tuner constructionStefan Klug
The instances of the static modules need to be passed to tuner.set_output_order() instead of the class. This is the reason for the intermediate variables. To keep the code tidy, apply the same pattern to the other modules. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-08-14libcamera: camera: Hide Camera::create() from the public APILaurent Pinchart
The Camera::create() function is internal. Hide it from the public API documentation. 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: 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-12py: cam: Convert to PyQt6Tomi Valkeinen
Qt5 is now end of life. The libcamera 'qcam' application has removed support for Qt5, and updated to Qt6. Update the python 'cam' application accordingly to Qt6. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-12libcamera: simple: Fix a typo in a doc stringMilan Zamazal
Rectify incorrect phrase in the sentence -- s/their share/they share/. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-12ipa: libipa: Add missing CameraSensorHelper fn label in docsMilan Zamazal
The constructor reference was missing, causing the constructor documentation to appear in blackLevel() documentation. Signed-off-by: Milan Zamazal <mzamazal@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-08-12utils: checkstyle.py: Add __repr__ method to Commit classLaurent Pinchart
When debugging issues with the Commit class, a __repr__ method proved to be useful to quickly print all the parsed information about a commit. To avoid reimplementing the method over and over again in the future, add it to the class, even if it is not actually used. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-12utils: checkstyle.py: Skip title and trailers checkers for pre-commitLaurent Pinchart
When running checkstyle.py in a pre-commit hook, there is either no commit message at all (when committing staged changes as a new commit), or the commit message comes from a previous commit being amended. In either case, there's no new commit message yet, and thus nothing to validate for the title and trailers checkers. The trailers checker, in particular, will always flag an error, making all commits fail. To fix that, just skip the two checkers during pre-commit. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-12utils: checkstyle.py: Rework commit message parsingLaurent Pinchart
When parsing commit messages, the Commit class tries to optimize the process by invoking git-show once only, extracting both the commit author, title and modified files in one go. As a result, the derived Amendment class needs to implement the commit parsing separately, as the modified files need to be extracted differently for amendments (and the commit ID also needs to be retrieved differently). Furthermore, because of the list of named files, extracting the trailers needs to invoke git-show separately. Improve the situation by reworking the commit message parsing in three steps. In the first step, use git-show to extract the commit ID, author, title and body. In the second step, invoke git-interpret-trailers to extract the trailers from the body that was previously extracted. The third and final step extracts the list of modified files, using different methods for regular commits and amendments. This allows sharing code for the first two steps between the Commit and Amendment classes, making the code simpler. The Commit class still invokes git three times, while the Amendment class runs it three times instead of four, improving performance slightly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>