summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2024-09-02libcamera: includes: Formatting improvementsMilan Zamazal
The LSP autoformatter doesn't like some of the current formatting, let's make it happier. Note that not all of its suggestions were accepted because readability is preferred and adjusting .clang-format may not be easy or possible. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: includes: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: includes: Add missing includesMilan Zamazal
Let's add direct includes for classes currently included indirectly, through other header files. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-02libcamera: ipa: Remove unused includesMilan Zamazal
The includes that are not used can be removed. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-30libcamera: camera: Use invokeMethod() for pipe_->acquire() and pipe_->release()Hans de Goede
The uvcvideo driver needs to open / close its /dev/video# node from pipe_->acquireDevices() / pipe_->releaseDevices(). V4L2VideoDevice::open() creates an EventNotifier and this notifier needs to be created from the CameraManager thread. Use invokeMethod() for pipe_->acquire() and pipe_->release() so that the EventNotifiers are created from the CameraManager thread context. Running pipe_->acquire() and pipe_->release() from the CameraManager thread context serializes all calls to them. Drop PipelineHandler::lock_ this now is no longer necessary and update the "\context" part of the documentation for acquire[Device]() and release[Device]() to match. Note the delayed opening of /dev/video# is a special case because the kernel uvcvideo driver powers on the USB device as soon as /dev/video# is opened. This behavior should *not* be copied by other pipeline handlers. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-08-30pipeline_handler: Add acquireDevice() function to mirror releaseDevice()Hans de Goede
libcamera always keeps all /dev/video# and /dev/v4l2_subdev# nodes for a pipeline open after enumerating the camera. This is a problem for the uvcvideo pipeline handler. Keeping /dev/video# open stops the UVC USB device from being able to enter runtime-suspend causing significant unnecessary power-usage. Add a stub acquireDevice() function to the PipelineHandler class which pipeline handlers can override. The uvcvideo pipeline handler will use this to delay opening /dev/video# until the device is acquired. This is a special case because the kernel uvcvideo driver powers on the USB device as soon as /dev/video# is opened. This behavior should *not* be copied by other pipeline handlers. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@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-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-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-12libcamera: Fix header groupingLaurent Pinchart
The libcamera coding style groups the C and C++ standard library headers in a single group. Fix the few offenders in the source tree. While at it, add a missing blank line between header groups in a separate location. 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-12libcamera: Add missing <stdint.h> include to internal/yaml_parser.hSergei Trofimovich
Without the change the build fails on upcoming `gcc-15` as: In file included from ../src/libcamera/yaml_parser.cpp:8: ../include/libcamera/internal/yaml_parser.h:183:41: error: 'uint8_t' was not declared in this scope 183 | std::is_same_v<uint8_t, T> || | ^~~~~~~ Signed-off-by: Sergei Trofimovich <slyich@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-12libcamera: Add missing <stdint.h> include to base/file.hSergei Trofimovich
Without the change the build fails on upcoming `gcc-15` as: In file included from ../src/libcamera/base/file.cpp:8: ../include/libcamera/base/file.h:62:33: error: 'uint8_t' was not declared in this scope 62 | ssize_t read(const Span<uint8_t> &data); | ^~~~~~~ Signed-off-by: Sergei Trofimovich <slyich@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-08-07libcamera: ipa_manager: Remove singleton requirementLaurent Pinchart
The IPAManager class implements a singleton pattern due to the need of accessing the instance in a static member function. The function now takes a pointer to a PipelineHandler, which we can use to access the CameraManager, and from there, the IPAManager. Add accessors to the internal API to expose the CameraManager from the PipelineHandler, and the IPAManager from the CameraManager. This requires allocating the IPAManager dynamically to avoid a loop in includes. Use those accessors to replace the IPAManager singleton. Update the IPA interface unit test to instantiate a CameraManager instead of an IPAManager and ProcessManager, to reflect the new way that the IPAManager is accessed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-07libcamera: Consolidate tracepoint header in libcamera_internal_headersLaurent Pinchart
The libcamera_tracepoint_header variable stores the tracepoints.h header custom target, for the sole purpose of being listed as a source of the libcamera shared library, through the libcamera_internal_sources variable. Add the tracepoints.h header to libcamera_internal_headers instead of libcamera_internal_sources, and list libcamera_internal_headers as a source of the shared library, alongside libcamera_internal_sources. This makes libcamera_internal_sources contain sources only, improving clarity of the build system variables. 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-07libcamera: Add missing headers to libcamera_internal_headersLaurent Pinchart
The ipa_data_serializer.h and ipc_pipe.h headers are missing from libcamera_internal_headers. Add them. 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-07libcamera: Consolidate all IPA headers in libcamera_ipa_headersLaurent Pinchart
The IPA headers are listed in two different meson variables, one for generated headers, and one for the other headers. There's no real reason for this split, consolidate all of them in the libcamera_ipa_headers variable. While at it, don't add the IPA headers to the libcamera_internal_sources variable, but list libcamera_ipa_headers in the sources for the shared library. This moves the libcamera_internal_sources variable towards holding source files, not header files, to improve clarity of the build system. 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-07libcamera: Add version.h to public headersLaurent Pinchart
The generated version.h header is part of the public headers, but is missing from the libcamera_public_headers variable. Add it. 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-01libcamera: ipa_proxy: Report a missing configuration as a warningMilan Zamazal
When the configuration file for an IPA module is missing, it is reported as an error in the log, for example: ERROR IPAProxy ipa_proxy.cpp:149 Configuration file 'imx219.yaml' not found for IPA module 'simple' This is misleading because several pipelines use uncalibrated.yaml in such a case and can continue working. And in case of software ISP, there is currently no other configuration file so the error is always reported. On the other hand, in some other cases the presence of the configuration file is required and it is an error if it is missing. Let's introduce a new optional argument to IPAProxy::configurationFile that specifies a fallback file if the requested file is not found. If the primary requested file is not found and a non-empty fallback file is specified then a warning is logged and the fallback file is looked up. If neither the fallback file can be found then only then an error is logged and the method returns an empty string. This change has also the benefit of putting the common fallback file ("uncalibrated.yaml") pattern to a single place. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-01libcamera: ipa_proxy: Unify configurationFile argument nameMilan Zamazal
The argument name is different in the declaration and the definition. Let's use the same one in both, namely `name'. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-08-01libcamera: base: Add MemFd helper classLaurent Pinchart
libcamera creates memfds in two locations already, duplicating some code. Move the code to a new MemFd helper class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Milan Zamazal <mzamazal@redhat.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2024-07-04libcamera: base: utils: Implement hex() for 8-bit and 16-bit valuesLaurent Pinchart
The utils::hex() function is implemented for 32-bit and 64-bit integers, but not for 8-bit and 16-bit. This causes a link error (possibly at runtime for IPA modules due to lazy linking) when trying to print 8-bit or 16-bit integers. Implement additional specializations to fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-07-03libcamera: converter: Replace usage of stream index by Stream pointerUmang Jain
The converter interface uses the unsigned int output stream index to map to the output frame buffers. This is cumbersome to implement new converters because one has to keep around additional book keeping to track the streams with their correct indexes. The v4l2_converter_m2m and simple pipeline handler are adapted to use the new interface. This work roped in software ISP as well, which also seems to use indexes (although it doesn't implement converter interface) because of a common conversionQueue_ queue used for converter_ and swIsp_. The logPrefix is no longer able to generate an index from a stream, and is updated to be more expressive by reporting the stream configuration instead, for example, reporting "1920x1080-MJPEG" in place of "stream0". Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> # sm8250 RB5
2024-07-03converter: converter_v4l2_m2m: Rename private Stream classUmang Jain
Rename the private Stream class from V4L2M2MConverter::Stream to V4L2M2MConverter::V4L2M2MStream. This is done to improve readability of the code when we drop the handling of stream by indexes in a subsequent patch. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2024-06-25ipa: ipa_interface: Declare ipaCreate() in libcamera namespaceLaurent Pinchart
The ipaCreate() function is the entry point to IPA modules. It is declared in ipa_interface.h, and defined by each module. As the function is defined with extern "C" linkage, the namespace in which it is contained is not very relevant from a caller's point of view. For the IPA module implementer, however, defining the function in the libcamera namespace avoids adding an explicit libcamera:: prefix to the symbols used by the function. This is why all IPA modules define their ipaCreate() entry point in the libcamera namespace. The ipa_interface.h file, however, declares the function in the global namespace. This doesn't cause any issue at runtime, but will cause a missing declaration warning when we enable them. To prepare for that, move the function declaration to the libcamera namespace. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-25libcamera: base: log: Declare log categories when defining themLaurent Pinchart
libcamera will enable -Wmissing-declarations to catch mismatches between function declarations and definitions. There is one offender in log.h: when a category is defined with LOG_DEFINE_CATEGORY(), it generates a function with no declaration. Fix it by declaring the function using LOG_DECLARE_CATEGORY() as the first step of the category definition. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-24libcamera: yaml_parser: Add support for float typesLaurent Pinchart
The YamlObject::get<T>() function template has a specialization for double but not for float. When used in an IPA module, the issue is caught at module load time only, when dynamic links are resolved, causing errors such as Failed to open IPA module shared object: /usr/lib/libcamera/ipa_rkisp1.so: undefined symbol: _ZNK9libcamera10YamlObject6GetterIfE3getERK_ Fix it by adding a float specialization. The alternative would be to use double only in IPA modules, but the lack of enforcement at compile time makes this dangerous. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-06-16libcamera: yaml_parser: Delegate YamlObject::get() to helper structureLaurent Pinchart
The YamlObject::get() function is a function template that gets fully specialized for various types. This works fine for non-template types, but specializing it for template types (e.g. a std::vector<U>) would require partial template specialization, which C++ allows for classes and variables but not functions. To work around this problem, delegate the implementation to a new YamlObject::Getter structure template, which will support partial specialization. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-16libcamera: yaml_parser: Drop std::enable_if_t guards for get() functionLaurent Pinchart
The YamlObject::get() function template is implemented for a set of basic types through template specializations. The function declaration uses std::enable_if_t<> guards to signal incorrect usage at compilation time. This however prevents the API to be extended with additional specializations in other compilation units. To prepare for new specializations of the function for the ipa::Vector and ipa::Pwl classes types, implemented in their respective compilation units, drop the std::enable_it_t<> guards. Incorrect usage will still be reported as link errors. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-13libcamera: yaml_parser: Make default value templated in `get()`Barnabás Pőcze
This way the construction of the default value of type `T` can be delayed until it is really needed, which is useful, for example when `T == std::string` and the default value comes from a string literal, as the default value string would always be constructed otherwise, even if not needed. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-06-04libcamera: DmaBufAllocator: Support allocating from /dev/udmabufHans de Goede
The dma-buf allocator currently allocates from CMA and system heaps. Extend the dma-buf allocator to support allocating dma-buffers by creating memfd-s and turning those into dma-buffers using /dev/udmabuf. The buffers allocated through memfd/udmabuf are not suitable for zero-copy buffer sharing with other devices. Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Lenovo-x13s Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-04libcamera: Rename DmaHeap class to DmaBufAllocatorHans de Goede
Users of the DmaHeap class really just want some way to allocate dma-buffers from userspace. This can also be done by using /dev/udmabuf instead of using /dev/dma_heap/*. Rename DmaHeap class to DmaBufAllocator in preparation of adding /dev/udmabuf support. And update the DmaHeap class docs to match including replacing references to "dma-heap type" with "dma-buf provider". This is a pure automated rename on the code ('s/DmaHeap/DmaBufAllocator/') + file renames + doc updates. There are no functional changes. The DmaBufAllocator objects in vc4.cpp and software_isp.cpp are left named dmaHeap_ to keep the changes to those 2 files to a minimum. Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Lenovo-x13s Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-03libcamera: v4l2_subdevice: Update to the new kernel routing APILaurent Pinchart
The subdev embedded data support series includes a change to the VIDIOC_SUBDEV_G_ROUTING and VIDIOC_SUBDEV_S_ROUTING ioctls that impacts the userspace API. Update to the new API, while preserving backward compatibility to ease the transition. Document the backward compatibility to only be supported for two kernel releases. As the routing API isn't enabled in any upstream kernel yet, users of the API need kernel patches, and are expected to be able to upgrade quickly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-06-03include: linux: Update kernel headers to version v6.10-rc1Hans de Goede
Updated kernel headers to v6.10-rc1 using utils/update-kernel-headers.sh and re-instating libcamera local modifications. This includes adding include/linux/udmabuf.h which was not part of libcamera's include/linux headers before. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-06-02libcamera: software_isp: Remove DebayerParams::kGain10Milan Zamazal
The constant is used in a single place internally and doesn't belong to DebayerParams anymore. Let's use 256 directly. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-06-02libcamera: software_isp: Move color mappings out of debayeringMilan Zamazal
Constructing the color mapping tables is related to stats rather than debayering, where they are applied. Let's move the corresponding code to stats processing. The same applies to the auxiliary gamma table. As the gamma value is currently fixed and used in a single place, with the temporary exception mentioned below, there is no need to share it anywhere anymore. It's necessary to initialize SoftwareIsp::debayerParams_ to default values. These initial values are used for the first two frames, before they are changed based on determined stats. To avoid sharing the gamma value constant in artificial ways, we use 0.5 directly in the initialization. This all is not a particularly elegant thing to do, such a code belongs conceptually to the similar code in stats processing, but doing better is left for larger refactoring. This is a preliminary step towards building this functionality on top of libipa/algorithm.h, which should follow. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-05-16libcamera: formats: Add PiSP specific image and config buffer formatsNaushir Patuck
Add the Raspberry Pi 5 PiSP specific compressed Bayer format types 1/2: - V4L2_PIX_FMT_PISP_COMP1_xxx - V4L2_PIX_FMT_PISP_COMP2_xxx Add the Raspberry Pi 5 PiSP Frontend and Backend config formats: - V4L2_META_FMT_RPI_FE_CFG - V4L2_META_FMT_RPI_BE_CFG Add the Raspberry Pi 5 PiSP Frontend statistics format: - V4L2_META_FMT_RPI_FE_STATS Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-16include: linux: Add PiSP specific image and config buffer formatsNaushir Patuck
Add the Raspberry Pi 5 PiSP specific compressed Bayer format types 1/2: - V4L2_PIX_FMT_PISP_COMP1_xxx - V4L2_PIX_FMT_PISP_COMP2_xxx Add the Raspberry Pi 5 PiSP Frontend and Backend config formats: - V4L2_META_FMT_RPI_FE_CFG - V4L2_META_FMT_RPI_BE_CFG Add the Raspberry Pi 5 PiSP Frontend statistics format: - V4L2_META_FMT_RPI_FE_STATS The corresponding changes submitted to the linux-media mailing list can be found at: (series "media: raspberrypi: Add support for PiSP Back End") https://lore.kernel.org/linux-media/20240502110503.38412-4-jacopo.mondi@ideasonboard.com/ https://lore.kernel.org/linux-media/20240502110503.38412-5-jacopo.mondi@ideasonboard.com/ and for the DRM mailing at: (patch "[RFC] drm/fourcc: Add RPI modifiers") https://lore.kernel.org/dri-devel/20240226153854.99471-1-jacopo.mondi@ideasonboard.com/ Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-16include: linux: Add RGB48 formatsNaushir Patuck
Add support for 16-bps (48-bpp) RGB output formats in the uapi headers. These new formats are defined for the RGB and BGR ordering. The corresponding change submitted to the linux-media and DRM mailing lists can be found at: https://lore.kernel.org/linux-media/20240502110503.38412-3-jacopo.mondi@ideasonboard.com/ and https://lore.kernel.org/dri-devel/20240226132544.82817-1-jacopo.mondi@ideasonboard.com/ respectively. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: camera_manager: Add environment variable to order pipelines matchJulien Vuillaumier
To match the enumerated media devices, each registered pipeline handler is used in no specific order. It is a limitation when several pipelines can match the devices, and user has to select a specific pipeline. For this purpose, environment variable LIBCAMERA_PIPELINES_MATCH_LIST is created to give the option to define an ordered list of pipelines to match on. LIBCAMERA_PIPELINES_MATCH_LIST="<name1>[,<name2>[,<name3>...]]]" Example: LIBCAMERA_PIPELINES_MATCH_LIST="rkisp1,simple" Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: pipeline: Add a get factory by name helperJulien Vuillaumier
Add a static helper to the PipelineHandlerFactoryBase class to allow retrieving a pipeline by name. Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-14libcamera: pipeline: Rename pipelines to a shorter nameJulien Vuillaumier
The PipelineHandlerFactoryBase class has a name that is propagated to the PipelineHandler instance it creates. In present implementation, this name comes from the REGISTER_PIPELINE_HANDLER registration macro. It corresponds to the stringified name of the PipelineHandler derived class. Therefore, PipelineHandler factories and instances names can be quite long such as "PipelineHandlerRkISP1". A libcamera user may have to explicitly refer to a PipelineHandler name for configuration purpose: one usage of the name can be to define a pipeline handlers match list and their priorities. It is desired, for user convenience, to use a short name to designate a pipeline handler. Reusing the short pipeline names already defined in the meson option files is an existing and consistent way of naming pipelines. This change adds an explicit name parameter to the REGISTER_PIPELINE_HANDLER registration macro. That parameter is used to define the name of a pipeline handler factory, instead of the current pipeline handler class name. Each pipeline registration is updated accordingly. The short name assigned corresponds to the pipeline directory name in the source tree. It is consistent with pipelines names used in meson. Changing the pipeline name has an impact on the IPA modules: each module defines a IPAModuleInfo structure. This structure has a pipelineName member defining the pipeline handler name it shall match with. Therefore, each internal IPA module definition has to be changed to have its IPAModuleInfo pipelineName name updated with the short pipeline handler name. In addition to this pipelineName member, the IPAModuleInfo structure also has a name member, associated to the IPA module name. Having renamed the pipelines to a short name, the pipeline name and the IPA module names of the IPAModuleInfo structure are the same: for in-tree IPA, they correspond to the respective pipeline and IPA subdirectories in the source tree. However the IPA name could be different, for instance with a close source IPA implementation built out-of-tree. Thus, it makes sense to keep the IPA name in that structure, as the 2 definitions may not always be redundant. Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> [Kieran: Adjust for clang-format style fix, reformat commitmsg] Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-05-09libcamera: Drop remaining file name from header comment blocksLaurent Pinchart
Source files in libcamera start by a comment block header, which includes the file name and a one-line description of the file contents. While the latter is useful to get a quick overview of the file contents at a glance, the former is mostly a source of inconvenience. The name in the comments can easily get out of sync with the file name when files are renamed, and copy & paste during development have often lead to incorrect names being used to start with. Readers of the source code are expected to know which file they're looking it. Drop the file name from the header comment blocks in all remaining locations that were not caught by the automated script as they are out of sync with the file name. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-05-09libcamera: Drop file name from header comment blocks in templatesLaurent Pinchart
Source files in libcamera start by a comment block header, which includes the file name and a one-line description of the file contents. While the latter is useful to get a quick overview of the file contents at a glance, the former is mostly a source of inconvenience. The name in the comments can easily get out of sync with the file name when files are renamed, and copy & paste during development have often lead to incorrect names being used to start with. Readers of the source code are expected to know which file they're looking it. Drop the file name from the header comment blocks in template files and templates embedded in generator scripts. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-05-08libcamera: Drop file name from header comment blocksLaurent Pinchart
Source files in libcamera start by a comment block header, which includes the file name and a one-line description of the file contents. While the latter is useful to get a quick overview of the file contents at a glance, the former is mostly a source of inconvenience. The name in the comments can easily get out of sync with the file name when files are renamed, and copy & paste during development have often lead to incorrect names being used to start with. Readers of the source code are expected to know which file they're looking it. Drop the file name from the header comment block. The change was generated with the following script: ---------------------------------------- dirs="include/libcamera src test utils" declare -rA patterns=( ['c']=' \* ' ['cpp']=' \* ' ['h']=' \* ' ['py']='# ' ['sh']='# ' ) for ext in ${!patterns[@]} ; do files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done) pattern=${patterns[${ext}]} for file in $files ; do name=$(basename ${file}) sed -i "s/^\(${pattern}\)${name} - /\1/" "$file" done done ---------------------------------------- This misses several files that are out of sync with the comment block header. Those will be addressed separately and manually. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>