summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
5 dayslibcamera: 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>
5 dayslibcamera: 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>
5 dayslibcamera: 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>
5 daysDmaBufAllocator: 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>
6 dayslibcamera: 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>
7 dayslibcamera: 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>
13 dayslibcamera: 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>
2024-09-25libcamera: controls: Add array information to ControlIdPaul Elder
Add to ControlId information on whether or not it is an array control, and the size of the control if it is an array control. Signed-off-by: Paul Elder <paul.elder@ideasonboard.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-09-25libcamera: controls: Add enum names and values map to ControlIdPaul Elder
Add to ControlId information about the names and values of enum, in the event that the ControlId is an enum type. This allows applications to query the ControlId for the names of the enum values, so that they can be displayed on a UI, for example. Without this, it was necessary to use macros of NameOfControlNameValueMap, which is difficult to use and is very inflexible. There already exists a map from name -> value in generated code. Reuse this and pass it to the ControlId constructor, which in turn generates the reverse map. The reverse map is then exposed to applications. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2024-09-23libcamera: yaml-parser: Differentiate between empty and empty stringStefan Klug
When accessing a nonexistent key on a dict the YamlObject returns an empty element. This element can happily be cast to a string which is unexpected. For example the following statement: yamlDict["nonexistent"].get<string>("default") is expected to return "default" but actually returns "". Fix this by introducing an empty type to distinguish between an empty YamlObject and a YamlObject of type value containing an empty string. For completeness add an isEmpty() function and an explicit cast to bool to be able to test for that type. Extend the tests accordingly. 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-09-12libcamera: media_object: Add MediaLink string representationsKieran Bingham
Various parts of libcamera print the representation of a MediaLink by inline joining the parts to make a string representation. This repeated use case can be supported with a common helper to print the MediaLink in a common manner using the existing toString() and operator<< overload style to make it easier to report on MediaLink types. This implementation will report in the following style: 'imx283 1-001a'[0] -> 'video-mux'[0] Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-12libcamera: media_object: Add MediaPad string representationsKieran Bingham
Facilitate easy representations of a MediaPad object by preparing it as a string and supporting output streams. A MediaPad will be report in the following style: 'imx283 1-001a'[0] Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2024-09-05libcamera: utils: Add ScopeExitActions classLaurent Pinchart
The ScopeExitActions class is a simple object that performs user-provided actions upon destruction. It is meant to simplify cleanup tasks in error handling paths. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2024-09-03libcamera: ipa: Drop unneded includes from ipa_interface.hLaurent Pinchart
The ipa_interface.h file includes a number of headers that are not directly used. Remove them, and add them to the source files that include ipa_interface.h as required. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
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>