summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
6 daysinclude: linux: Add Mali-C55 Stats and Params V4L2 formatDaniel Scally
Add the new format describing the Mali C55's Statistics and Parameters to videodev2. These come from the v8 of the C55 kernel driver series [1]. Once the kernel driver is merged we can replace these temporary manual additions with updates to the scripts that merge in the kernel headers. [1] https://lore.kernel.org/linux-media/20241106100534.768400-1-dan.scally@ideasonboard.com/ Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Acked-by: Nayden Kanchev <nayden.kanchev@arm.com> Co-developed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
6 daysinclude: linux: Add mali-c55-config.hDaniel Scally
Add the header file describing the Mali C55's 3A statistics and parameters structures so that they can be used by the new IPA module. The header has been taken from the v6 of the patchset for the Mali C55 ISP driver submitted to linux-media, found at the link below: https://lore.kernel.org/linux-media/20240709132906.3198927-1-dan.scally@ideasonboard.com/ Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Acked-by: Nayden Kanchev <nayden.kanchev@arm.com> Co-developed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
6 dayslibcamera: rpi: Draw sensor delays from CameraSensorPropertiesDaniel Scally
Now that we have camera sensor control application delay values in the CameraSensorProperties class, remove the duplicated definitions in the RPi IPA's CameraSensorHelpers and update the pipeline handler to use the values from CameraSensorProperties. Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
7 dayslibcamera: camera_sensor: Add parameter to limit returned sensor sizeStefan Klug
The getFormat function takes the aspect ratio and the area of the requested size into account when choosing the best sensor size. In case the sensor is connected to an rkisp1 the maximum supported frame size of the ISP is another constraining factor for the selection of the best format. Add a maxSize parameter to support such a constraint. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
7 dayslibcamera: camera: Add a const version of the pipe() functionStefan Klug
Allow access to the pipeline handler on a const instance of Camera::Private. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
7 dayslibcamera: converter: Add functions to adjust configJacopo Mondi
Add to the Converter interface two functions used by pipeline handlers to validate and adjust the converter input and output configurations by specifying the desired alignment for the adjustment. Add the adjustInputSize() and adjustOutputSize() functions that allows to adjust the converter input/output sizes with the desired alignment. Add a validateOutput() function meant to be used by the pipeline handler implementations of validate(). The function adjusts a StreamConfiguration to a valid configuration produced by the Converter. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com>
7 dayslibcamera: converter: Add function to check if a stream was configuredStefan Klug
Add a isConfigured() function to be able to check if a given stream was configured in the converter. This is useful in pipelines to either query device or stream specific crop bounds depending on whether the stream is configured or not. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
7 dayslibcamera: converter: Add function to query crop boundsStefan Klug
The inputCropBounds_ member of the V4L2M2MConverter::Stream class is only initialized after a V4L2M2MConverter::configure() call, when the streams are initialized. However, the converter has crop limits that do not depend on the configured Streams, and which are currently not accessible from the class interface. Add a new inputCropBounds() function to the V4L2M2MConverter class that allows to retrieve the converter crop limits before any stream is configured. This is particularly useful for pipelines to initialize controls and properties and to implement validation before the Camera gets configured. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
7 dayslibcamera: converter_v4l2_m2m: Add missing override specifierStefan Klug
In preparation for adding new functions and overrides to the V4L2M2MDevice class, add an override specifier to all overridden functions in the class. This prevents -Winconsistent-missing-override warnings. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
7 dayslibcamera: geometry: Add Rectangle::transformedBetween()Stefan Klug
Handling cropping and scaling within a complicated pipeline involves transformations of rectangles between different coordinate systems. For example the full input of the dewarper (0,0)/1920x1080 might correspond to the rectangle (0, 243)/2592x1458 in sensor coordinates (of a 2592x1944 sensor). Add a function that allows the transformation of a rectangle defined in one reference frame (dewarper) into the coordinates of a second reference frame (sensor). Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
12 dayslibcamera: stream: Add operator<<(StreamConfiguration)Jacopo Mondi
The StreamConfiguration class only implements toString() but doesn't offer an overload of operator<<() which is more convenient to use. Add an overload for operator<<(StreamConfiguration) and re-implement StreamConfiguration::toString() on top of it. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-12-06libcamera: software_isp: Add contrast controlMilan Zamazal
This patch introduces support for applying runtime controls to software ISP. It enables the contrast control as the first control that can be used. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-12-05libcamera: utils: StringSplitter: Add `operator==`Barnabás Pőcze
If `cpp_debugstl` is enabled in the build configuration, then libstdc++ will try to use `==` on operators in certain cases to carry out extra checks. This leads to build failures because `StringSplitter::iterator` has no `operator==`. Implement `operator==`, and express `operator!=` in terms of it. 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>
2024-12-05libcamera: utils: StringSplitter: Inline some trivial methodsBarnabás Pőcze
Inline some of the more trivial methods so that they can be inlined by the compiler. 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>
2024-12-04include: media-bus-formats: Add Mali-C55 mbus codesJacopo Mondi
Add media bus codes introduced by the Mali C55 ISP support to describe the 20-bit input formats supported by the ISP. This manual addition is a temporary measure until the kernel driver changes are merged, from which point this will be managed through the usual merge of the upstream kernel headers. Add the following formats - MEDIA_BUS_FMT_RGB202020_1X60 for processed input formats https://lore.kernel.org/linux-media/20241106100534.768400-2-dan.scally@ideasonboard.com/ - MEDIA_BUS_FMT_SBGGR20_1X20 MEDIA_BUS_FMT_SGBRG20_1X20 MEDIA_BUS_FMT_SGRBG20_1X20 MEDIA_BUS_FMT_SRGGB20_1X20 for the RAW bayer input format https://lore.kernel.org/linux-media/20241106100534.768400-3-dan.scally@ideasonboard.com/ Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-12-03libcamera: internal: Add Matrix class to buildStefan Klug
Add the new Matrix class to the build. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-12-03libcamera: internal: matrix: Replace vector with array in constructorStefan Klug
The Matrix constructor that takes a std::vector is meant and only used to initialize a Matrix from an initializer list. Using a std::vector is problematic for two reasons. First, it requires constructing a vector, copying the data from the initializer list, which is an expensive operation. Then, the vector size can't be verified at compile time, making the constructor unsafe. The first issue could be solved by replacing the vector with a std::initializer_list or a Span. The second issue would require checking the initializer list size with a static assertion, or restricting usage of the constructor to fixed-extent spans. Unfortunately, even if the size of initializer lists is always known at compile time, the std::initializer_list::size() function is a compile-time constant only for constant initializer lists. Using a span would work better, but construction of a fixed extent span from an initializer list must be explicit, making the API cumbersome. We can solve all those issues by passing an std::array to the constructor. Construction of an array from an initializer list can be implicit and doesn't involve a copy, and the array size is a template parameter and therefore guaranteed to be a compile-time constant. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-12-03libcamera: internal: Move Matrix class into libcamera namespaceStefan Klug
The Matrix class no longer lives inside lipipa. Move it into the libcamera namespace to account for that. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-12-03libcamera: Copy Matrix class from libipa to libcameraStefan Klug
In preparation to moving the matrix implementation from libipa to libcamera copy the corresponding files to the new location. The files are copied without modification to make upcoming integration changes easier to see. The new files are not included in the build and therefore have no negative side effects on the build. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-28libcamera: add method to set thread affinityHan-Lin Chen
Add method to set thread affinity to Thread class. Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-28libcamera: Extend u16 control typeYudhistira Erlandinata
V4L2 Controls support a wide variety of types not yet supported by the ControlValue type system. Extend the libcamera ControlValue types to support an explicit 16 bit unsigned integer type, and map that to the corresponding V4L2_CTRL_TYPE_U16 type within the v4l2_device support class. It's used on some camera metadata that is of length 16-bits, for example JPEG metadata headers. Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> 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-11-28libcamera: Extend u32 control typeYudhistira Erlandinata
V4L2 Controls support a wide variety of types not yet supported by the ControlValue type system. Extend the libcamera ControlValue types to support an explicit 32 bit unsigned integer type, and map that to the corresponding V4L2_CTRL_TYPE_U32 type within the v4l2_device support class. Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> 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-11-28DmaBufAllocator: Add Dma Buffer synchronization function & helper classHarvey Yang
To synchronize CPU access with mmap and hardware access on DMA buffers, using `DMA_BUF_IOCTL_SYNC` is required. This patch adds a function and a helper class to allow users to sync buffers more easily. Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-27libcamera: camera_sensor_properties: Add sensor control delaysDaniel Scally
Add properties covering the sensor control application delays to both the static CameraSensorProperties definitions. The values used are taken from Raspberry Pi's CamHelper class definitions. Where no more specific values are known the delay struct is defined as empty and defaults supplied through the getter function. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
2024-11-26libcamera: Rename "shutter speed" to "exposure time"Laurent Pinchart
The terms "shutter" and "shutter speed" are used through libcamera to mean "exposure time". This is confusing, both due to "speed" being used as "time" while it should be the inverse (i.e. a maximum speed should correspond to the minimum time), and due to "shutter speed" and "exposure time" being used in different places with the same meaning. To improve clarity of the code base and the documentation, use "exposure time" consistently to replace "shutter speed". This rename highlighted another vocabulary issue in libcamera. The ExposureModeHelper::splitExposure() function used to document that it splits "exposure time into shutter time and gain". It has been reworded to "split exposure into exposure time and gain". That is not entirely satisfactory, as "exposure" has a defined meaning in photography (see https://en.wikipedia.org/wiki/Exposure_(photography)) that is not expressed as a duration. This issue if left to be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-20libcamera: add DmaBufAllocator::exportBuffers()Harvey Yang
Add a helper function exportBuffers in DmaBufAllocator to make it easier to use. It'll be used in Virtual Pipeline Handler and SoftwareIsp. Signed-off-by: Harvey Yang <chenghaoyang@chromium.org> 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-11-13libcamera: yaml_parser: Use std::from_chars()Laurent Pinchart
std::from_chars(), introduced in C++17, is a fast, locale-independent string-to-arithmetic conversion function. The C++ standard library provides overloads for all integer types, making it a prime candidate to replace the manual handling of integer sizes in the YamlParser string to integer conversion. Compared to std::strtol(), std::from_chars() doesn't recognize the '0x' prefix or '+' prefix, and doesn't ignore leading white space. As the YamlParser doesn't require those features, std::from_chars() can be used safely, reducing the amount of code. C++17 also requires the standard C++ library to provide overloads for floating-point types, but libc++ does not implement those. The float and bool implementations of YamlParser::Getter::get() are therefore kept as-is. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-13libcamera: Add a DebugMetadata helperStefan Klug
Debug metadata often occurs in places where the metadata control list is not available e.g. in queueRequest() or processStatsBuffer() or even in a class far away from the metadata handling code. It is therefore difficult to add debug metadata without adding lots of boilerplate code. This can be mitigated by recording the metadata and forwarding it to the metadata control list when it becomes available. To solve the issue of code that is far away from the metadata context, add a chaining mechanism to allow loose coupling at runtime. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-13libcamera: Add debug control spaceStefan Klug
Add a new 'debug' controls namespace for the upcoming implementation of debug metadata. While at it, sort the entries alphabetically. Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-11libcamera: Rationalize IPA and handlers namesJacopo Mondi
The names used by the IPA interface and the names used for buffer completions handlers in libcamera clash in the use of the term "buffer". For example video device buffer completion handler is called "bufferReady" and the IPA event to ask the IPA to compute parameters are called "fillParamsBuffers". This makes it hard to recognize which function handles video device completion signals and which ones handle the IPA interface events. Rationalize the naming scheme in the IPA interface function and events and the signal handlers in the pipelines, according to the following table. Remove the name "buffer" from the IPA interface events and events handler and reserve it for the buffer completion handlers. Rename the IPA interface events and function to use the 'params' and 'stats' names as well. IPA Interface: - fillParamsBuffer -> computeParams [FUNCTION] - processStatsBuffer -> processStats [FUNCTION] - paramFilled -> paramsComputed [EVENT] Pipeline handler: - bufferReady -> videoBufferReady [BUFFER HANDLER] - paramReady -> paramBufferReady [BUFFER HANDLER] - statReady -> statBufferReady [BUFFER HANDLER] - paramFilled -> paramsComputed [IPA EVENT HANDLER] Cosmetic change only, no functional changes intended. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-11-08libcamera: pipeline_handler: Provide cancelRequestMilan Zamazal
Let's extract the two occurrences of canceling a request to a common helper. This is especially useful for the followup patch, which needs to cancel a request from outside. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-11-05libcamera: camera_sensor: Sort factories by priorityLaurent Pinchart
In order to support a default implementation for camera sensors when no better implementation matches, libcamera needs to try "specialized" implementations first and pick the default last. Make this possible by adding a priority value for factories. Newly registered factories are inserted in the factories list sorted by descending priority, and the default factory uses a negative priority to be inserted as the last element. This mechanism may be a bit overkill in the sense that there is no expected use cases for priorities other than trying the default last, but the implementation is simple and easy to understand. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-05libcamera: camera_sensor: Create abstract base classLaurent Pinchart
With a camera sensor factory in place, the next step is to create an abstract base class that all camera sensors implement, providing a uniform API to pipeline handler. Turn all public functions of the CameraSensor class into pure virtual functions, and move the implementation to the CameraSensorLegacy class. Part of the code is likely worth keeping as common helpers in a base class. However, to follow the principle of not designing helpers with a single user, this commit moves the whole implementation. Common helpers will be introduced later, along with other CameraSensor subclasses. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
2024-11-05libcamera: camera_sensor: Introduce CameraSensorFactoryJacopo Mondi
Introduce a factory to create CameraSensor derived classes instances by inspecting the sensor media entity name and provide a convenience macro to register specialized sensor handlers. Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-24libcamera: converter: Add interface to support cropping capabilityUmang Jain
If the converter has cropping capability on its input, the interface should support it by providing appropriate virtual functions. Provide Feature::InputCrop in Feature enumeration for the same. Provide virtual setInputCrop() and inputCropBounds() interfaces so that the converter can implement its own cropping functionality. The V4L2M2MConverter implements these interfaces of the Converter interface. Not all V4L2M2M converters will have cropping ability on its input, hence it needs to be discovered at construction time. If the capability to crop is identified successfully, the cropping bounds are determined during configure() time. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
2024-10-24libcamera: converter: Add interface for feature flagsUmang Jain
This patch intends to extend the converter interface to have feature flags, which enables each converter to expose the set of features it supports. 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> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-10-21libcamera: controls: Add vendor information to ControlIdPaul Elder
Add vendor/namespace information to ControlId, so that the vendor can be queried from it. This is expected to be used by applications either simply to display the vendor or for it to be used for grouping in a UI. Signed-off-by: Paul Elder <paul.elder@ideasonboard.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-10-18libcamera: tracepoints: Fix copyright year for reproducible buildsBernhard M. Wiedemann
The tracepoints.h file is generated from the tracepoints.h.in template by the gen-tp-header.py script. The template contains a {{year}} placeholder for the copyright year, which the script fills with the current year. This breaks reproducible builds with at least the openSUSE debugsource package. As the gen-tp-header.py script doesn't add any copyrightable contents to the tracepoints.h file, fix this by replacing the {{year}} placeholder with the year of the last copyright-worthy change to tracepoints.h.in. Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-10-18libcamera: controls: Add missing size to control_type<Point>Stefan Klug
The size member is missing in control_type<Point>. This did not do any harm because the only control using the Point type was an array control. As soon as a control-id with a non-array Point control gets defined, the compile fails with: error: size is not a member of libcamera::details::control_type<libcamera::Point> Fixes: 200d535ca85f ("libcamera: controls: Add ControlTypePoint") Signed-off-by: Stefan Klug <stefan.klug@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-10-03libcamera: yaml_parser: Take string keys in `std::string_view`Barnabás Pőcze
In many cases a static string literal is used as key. Thus having the argument type be `const std::string&` is suboptimal since an `std::string` object needs to be constructed before the call. C++17 introduced `std::string_view`, using which the call can be done with less overhead, as the `std::string_view` is non-owning and may be passed in registers entirely. So make `YamlObject::{contains,operator[]}` take the string keys in `std::string_view`s. Unfortunately, that is not sufficient yet, because `std::map::find()` takes an reference to `const key_type`, which would be `const std::string&` in the case of `YamlParser`. However, with a transparent comparator such as `std::less<>` `std::map::find()` is able to accept any object as the argument, and it forwards it to the comparator. So make `YamlParser::dictionary_` use `std::less<>` as the comparator to enable the use of `std::map::find()` with any type of argument. 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> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-10-01libcamera: controls: Add ControlTypePointYudhistira Erlandinata
Add a control_type<> specialization for libcamera::Point to allow storing data of that type in a ControlValue instance. The new control type will be used by controls introduced in the next patches. Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Becker Hsieh <beckerh@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-10-01libcamera: geometry: Add two-point Rectangle constructorYudhistira Erlandinata
Add a constructor to the Rectangle class that accepts two points. The constructed Rectangle spans all the space between the two given points. Signed-off-by: Yudhistira Erlandinata <yerlandinata@chromium.org> Co-developed-by: Harvey Yang <chenghaoyang@chromium.org> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org>
2024-09-30libcamera: controls: Handle enum values without a castLaurent Pinchart
When constructing a ControlValue from an enum value, an explicit cast to int32_t is needed as we use int32_t as the underlying type for all enumerated controls. This makes users of ControlValue more complex. To simplify them, specialize the control_type template for enum types, to support construction of ControlValue directly without a cast. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-30libcamera: v4l2_videodevice: Add getSelection() functionLaurent Pinchart
The V4L2VideoDevice class implements setSelection() but not getSelection(). The latter is useful for instance to query crop bounds. Implement the function. 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-09-27libcamera: software_isp: Call Algorithm::prepareMilan Zamazal
This patch adds Algorithm::prepare call for the defined algorithms. This is preparation only since there are currently no Algorithm based algorithms defined. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-27libcamera: software_isp: Call Algorithm::queueRequestMilan Zamazal
This patch adds Algorithm::queueRequest call for the defined algorithms. As there are currently no control knobs in software ISP nor the corresponding queueRequest call chain, the patch also introduces the queueRequest methods and calls from the pipeline to the IPA. This is preparation only since there are currently no Algorithm based algorithms defined and no current software ISP algorithms support control knobs. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-27libcamera: software_isp: Call Algorithm::configureMilan Zamazal
This patch adds Algorithm::configure call for the defined algorithms. This is preparation only since there are currently no Algorithm based algorithms defined. A part of this change is passing IPAConfigInfo instead of ControlInfoMap to configure() calls as this is what Algorithm::configure expects. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-27libcamera: software_isp: Track and pass frame idsMilan Zamazal
A previous preparation patch implemented passing frame ids to stats processing but without actual meaningful frame id value passed there. This patch extends that by actually providing the frame id and passing it through to the stats processor. The frame id is taken from the request sequence number, the same as in hardware pipelines. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-27libcamera: software_isp: Make stats frame and buffer awareMilan Zamazal
This patch adds frame and bufferId arguments to stats related calls. Although the parameters are currently unused, because frame ids are not tracked and used and the stats buffer is passed around directly rather than being referred by its id, they bring the internal APIs closer to their counterparts in hardware pipelines. It serves as a preparation for followup patches that will introduce: - Frame number tracking in order to switch to DelayedControls (software ISP TODO #11 + #12). - A ring buffer for stats in order to improve passing the stats (software ISP TODO #2). Frame and buffer ids are unrelated for the given purposes but since they are passed together at the same places, the change is implemented as a single patch rather than two, basically the same, patches. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-27libcamera: software_isp: Define skeletons for IPA refactoringMilan Zamazal
Software ISP image processing algorithms are currently defined in a simplified way, different from other libcamera pipelines. This is not good for several reasons: - It makes the software ISP code harder to understand due to its different structuring. - Adding more algorithms may make the code harder to understand generally. - Mass libcamera code changes may not be easily applicable to software ISP. - Algorithm sharing with other pipelines is not easily possible. This patch introduces basic software ISP IPA skeletons structured similarly to the other pipelines. The newly added files are currently not used or compiled and the general skeleton structures don't contain anything particular. It is just a preparation step for a larger refactoring and the code will be actually used and extended as needed in followup patches. Signed-off-by: Milan Zamazal <mzamazal@redhat.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>