libcamera/vivid.git - libcamera pipeline handler for VIVID

Age	Commit message (Collapse)	Author
2021-08-19	ipa: Use FileDescriptor instead of int in layers above IPC payload	Paul Elder
	Regarding (de)serialization in isolated IPA calls, we have four layers: - struct - byte vector + fd vector - IPCMessage - IPC payload The proxy handles the upper three layers (with help from the IPADataSerializer), and passes an IPCMessage to the IPC mechanism (implemented as an IPCPipe), which sends an IPC payload to its worker counterpart. When a FileDescriptor is involved, previously it was only a FileDescriptor in the first layer; in the lower three it was an int. To reduce the risk of potential fd leaks in the future, keep the FileDescriptor as-is throughout the upper three layers. Only the IPC mechanism will deal with ints, if it so wishes, when it does the actual IPC. IPCPipeUnixSocket does deal with ints for sending fds, so the conversion between IPCMessage and <svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-log-out"><path d="M9 21H5a2 2 0 0 1-2-2V5a2 2 0 0 1 2-2h4"></path><polyline points="16 17 21 12 16 7"></polyline><line x1="21" y1="12" x2="9" y2="12"></line></svg>

ss='logmsg'> The CameraData class isn't used anymore. Drop it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-16libcamera: pipeline_handler: Move CameraData members to Camera::PrivateLaurent Pinchart With pipeline handlers now being able to subclass Camera::Private, start the migration from CameraData to Camera::Private by moving the members of the base CameraData class. The controlInfo_, properties_ and pipe_ members are duplicated for now, to allow migrating pipeline handlers one by one. The Camera::Private class is now properly documented, don't exclude it from documentation generation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-16libcamera: camera: Pass Private pointer to Camera constructorLaurent Pinchart In order to allow subclassing Camera::Private in pipeline handlers, pass the pointer to the private data to the Camera constructor, and to the Camera::createCamera() function. The Camera::Private id_ and streams_ members now need to be initialized by the Camera constructor instead of the Camera::Private constructor, to allow storage of the streams in a pipeline handler-specific subclass of Camera::Private. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-16libcamera: base: extensible: Pass private pointer as unique_ptr<>Laurent Pinchart The Extensible constructor takes a pointer to a Private instance, whose lifetime it then manages. Make this explicit in the API by passing the pointer as a std::unique_ptr<Private>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-16ipa: vimc: Send and retrieve FrameBuffers from IPAUmang Jain Plumb through VIMC mojo interface to enable buffers passing. VIMC does not have parameters or statistics buffers but we can mimick the typical case of passing IPA buffers from pipeline handler to IPA using mock buffers. The mock IPA buffers are FrameBuffers which are dmabuf backed (in other words, mmap()able through MappedFramebuffer inside the IPA). This commits shows: - Passing the parameter buffer from the pipeline handler to the IPA through functions defined in mojom interface. - Passing request controls ControlList to the IPA. Any tests using VIMC will now loop in the IPA paths. Any tests running in isolated mode will help us to test IPA IPC code paths especially around (de)serialization of data passing from pipeline handlers to the IPA. Future IPA interface tests can simply extend the vimc mojom interface to achieve/test a specific use case as required. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-08-16ipa: vimc: Map and unmap buffersUmang Jain VIMC pipeline handler has dmabuf-backed mock FrameBuffers which are specifically targetted mimicking IPA buffers (parameter and statistics). Map these mock buffers to the VIMC IPA that would enable exercising IPA IPC code paths. This will provide leverage to our test suite to test IPA IPC code paths, which are common to various platforms. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-08-16ipa: vimc: Add configure() functionLaurent Pinchart As part of an effort to make the vimc IPA usable for testing, extend it with a configure function. The configuration is currently ignored by the IPA. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 2021-08-12libcamera: ipu3: Initialize controls in the IPAJacopo Mondi All the IPU3 Camera controls are currently initialized by the pipeline handler which initializes them using the camera sensor configuration and platform specific requirements. However, some controls are better initialized by the IPA, which might, in example, cap the exposure times and frame duration to the constraints of its algorithms implementation. Also, moving forward, the IPA should register controls to report its capabilities, in example the ability to enable/disable 3A algorithms on request. Move the existing controls initialization to the IPA, by providing the sensor configuration and its controls to the IPU3IPA::init() function, which initializes controls and returns them to the pipeline through an output parameter. The existing controls initialization has been copied verbatim from the pipeline handler to the IPA, if not a for few line breaks adjustments and the resulting Camera controls values are not changed. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> 2021-08-12libcamera: controls: Use ControlIdMap in deserializationJacopo Mondi Introduce a new field in the controls serialization protocol to allow discerning which ControlIdMap a ControlInfoMap refers to. The newly introduced IdMapType enumeration describes the possible info maps: - Either the globally available controls::controls and properties::properties maps, which are valid across IPC boundaries - A ControlIdMap created locally by the V4L2 device, which is not valid across the IPC boundaries At de-serialization time the idMapType field is inspected and - If the idmap is a globally defined one, there's no need to create new ControlId instances when populating the de-serialized ControlInfoMap. Use the globally available map to retrieve the ControlId reference and use it. - If the idmap is a map only available locally, create a new ControlId as it used to happen before this patch. As a direct consequence, this change allows us to perform lookup by ControlId reference on de-serialized ControlIdMap that refers to the libcamera defined controls::controls and properties::properties. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-08-12libcamera: controls: Create ControlInfoMap with ControlIdMapJacopo Mondi ControlInfoMap does not have a ControlId map associated, but rather creates one with the generateIdMap() function at creation time. As a consequence, when in the need to de-serialize a ControlInfoMap all the ControlId it contains are created by the deserializer instance, not being able to discern if the controls the ControlIdMap refers to are the global libcamera controls (and properties) or instances local to the V4L2 device that has first initialized the controls. As a consequence the ControlId stored in a de-serialized map will always be newly created entities, preventing lookup by ControlId reference on a de-serialized ControlInfoMap. In order to make it possible to use globally available ControlId instances whenever possible, create ControlInfoMap with a reference to an externally allocated ControlIdMap instead of generating one internally. As a consequence the class constructors take and additional argument, which might be not pleasant to type in, but enforces the concepts that ControlInfoMap should be created with controls part of the same id map. As the ControlIdMap the ControlInfoMap refers to needs to be allocated externally: - Use the globally available controls::controls (or properties::properties) id map when referring to libcamera controls - The V4L2 device that creates ControlInfoMap by parsing the device's controls has to allocate a ControlIdMap - The ControlSerializer that de-serializes a ControlInfoMap has to create and store the ControlIdMap the de-serialized info map refers to Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-08-10libcamera: MappedFrameBuffer: Use typed Flags<MapModes>Kieran Bingham Remove the need for callers to reference PROT_READ/PROT_WRITE directly from <sys/mman.h> by instead exposing the Read/Write mapping options as flags from the MappedFrameBuffer class itself. While here, introduce the <stdint.h> header which is required for the uint8_t as part of the Plane. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-08-10libcamera: Give MappedFrameBuffer its own implementationKieran Bingham The MappedFrameBuffer is a convenience feature which sits on top of the FrameBuffer and facilitates mapping it to CPU accessible memory with mmap. This implementation is internal and currently sits in the same internal files as the internal FrameBuffer, thus exposing those internals to users of the MappedFramebuffer implementation. Move the MappedFrameBuffer and MappedBuffer implementation to its own implementation files, and fix the sources throughout to use that accordingly. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-08-09libcamera: Rename 'method' to 'function'Laurent Pinchart Usage of 'method' to refer to member functions comes from Java. The C++ standard uses the term 'function' only. Replace 'method' with 'function' or 'member function' through the whole code base and documentation. While at it, fix two typos (s/backeng/backend/). The BoundMethod and Object::invokeMethod() are left as-is here, and will be addressed separately. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-08-03libcamera: camera: Make Camera::Private members privateLaurent Pinchart To prepare for the Camera::Private structure being used by pipeline handlers, turn all its members to private. Members that are useful for pipeline handlers will be made public again, or will be exposed through accessor functions, on a case-by-case basis. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: camera: Move Camera::Private to header fileLaurent Pinchart The Camera::Private class is defined in camera.cpp. To prepare for allowing it to be subclassed by pipeline handlers, move it to a new internal/camera.h header. The \file comment block in camera.cpp now needs to explicitly tell which camera.h file it refers to. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: base: class: Don't pass Extensible pointer to Private constructorLaurent Pinchart The Extensible and Extensible::Private classes contain pointers to each other. These pointers are initialized in the respective class's constructor, by passing a pointer to the other class to each constructor. This particular construct reduces the flexibility of the Extensible pattern, as the Private class instance has to be allocated and constructed in the members initializer list of the Extensible class's constructor. It is thus impossible to perform any operation on the Private class between its construction and the construction of the Extensible class, or to subclass the Private class without subclassing the Extensible class. To make the design pattern more flexible, don't pass the pointer to the Extensible class to the Private class's constructor, but initialize the pointer manually in the Extensible class's constructor. This requires a const_cast as the o_ member of the Private class is const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: base: class: Document Extensible::_d() functionsLaurent Pinchart The Extensible::_d() functions are meant to be called by users of the class. Document them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: file: Turn MapFlag and OpenModeFlag into enum classLaurent Pinchart Add type safety by turning the MapFlag and OpenModeFlag enum into enum class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: file: Use Flags<> class for open flagsLaurent Pinchart Use the newly introduced Flags<> class to store a bitfield of File::OpenMode in a type-safe way. The existing File::OpenMode enum is renamed to File::OpenModeFlag to free the File::OpenMode for the Flags<> type alias. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: file: Use Flags<> class for map flagsLaurent Pinchart Use the newly introduced Flags<> class to store a bitfield of File::MapFlag in a type-safe way. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-03libcamera: flags: Add type-safe enum-based flagsLaurent Pinchart Add a Flags template class that provide type-safe bitwise operators on enum values. This allows using enum types for bit fields, without giving away type-safety as usually done when storing combined flags in integer variables. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-08-02controls: Add boolean constructors for ControlInfoPaul Elder It would be convenient to be able to iterate over available boolean values, for example for controls that designate if some function can be enabled/disabled. The current min/max/def constructor is insufficient, as .values() is empty, so the values cannot be easily iterated over, and creating a Span of booleans does not work for the values constructor. Add new constructors to ControlInfo that takes a set of booleans (if both booleans are valid values) plus a default, and another that takes only one boolean (if only one boolean is a valid value). Update the ControlInfo test accordingly. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-07-27ipa: core.mojom: Rework core file documentationJacopo Mondi The comment block at the beginning of the core.mojom file is meant to provide an overview of how to use libcamera defined types in the definition of mojom interfaces. As the IPA/IPC interface definition mechanism evolved, the documentation has not been updated accordingly. Update the file comments to match the most recent IPA/IPC interface definition and generation mechanism. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-07-19libcamera: ipa_manager: Split common code out of createIPA()Laurent Pinchart The createIPA() template function starts with code that doesn't depend on the template parameters. Split it to a non-template function to avoid code duplication in the binary. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> 2021-07-19libcamera: ipa_manager: Fix IPA module min/max version checkLaurent Pinchart The IPAManager::createIPA() function has its minVersion and maxVersion parameters inverted. This doesn't cause any issue at the moment as both the minimum and maximum version are set to 1 by all callers, but it's still a bug. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> 2021-07-12libcamera: framebuffer: Make FrameBuffer class ExtensibleLaurent Pinchart Implement the D-Pointer design pattern in the FrameBuffer class to allow changing internal data without affecting the public ABI. Move the request_ field and the setRequest() function to the FrameBuffer::Private class. This allows hiding the setRequest() function from the public API, removing one todo item. More fields may be moved later. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-07-12libcamera: Drop the LIBCAMERA_D_PTR macro in favour of the _d() functionLaurent Pinchart Now that all Extensible classes expose a _d() function that performs appropriate casts, the LIBCAMERA_D_PTR brings no real additional value. Replace it with direct calls to the _d() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-07-12libcamera: base: class: Expose Extensible private data to other classesLaurent Pinchart Despite sharing the same name, the private data class created by the Extensible design pattern and the C++ private access specifier have different goals. The latter specifies class members private to the class, while the former stores data not visible to the application. There are use cases for accessing the private data class from other classes inside libcamera. Make this possible by exposing public _d() functions in the class deriving from Extensible. This won't allow access to the private data by applications as the definition of the Private class isn't visible outside of libcamera. The _d() functions need to be defined as template functions to delay their evaluation, as the static_cast() operator in the Extensible::_d() functions needs the Private class to be fully defined. The template argument is defaulted and ignored, as only its presence is required to delay evaluation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-07-11libcamera: buffer: Rename buffer.h to framebuffer.hLaurent Pinchart libcamera names header files based on the classes they define. The buffer.h file is an exception. Rename it to framebuffer.h. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-07-06libcamera: device_enumerator: Drop inclusion of linux/media.hLaurent Pinchart device_enumerator.h doesn't need to include linux/media.h. Drop inclusion of the header. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-07-06libcamera: media_device: Rename valid() function to isValid()Laurent Pinchart We use isValid() instead of valid() through the code base, make MediaDevice consistent. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> 2021-06-28libcamera: Add support for monochrome sensorsDavid Plowman This commit adds support for monochrome (greyscale) raw sensors. These are sensors that have no colour filter array, so all pixels are the same and there are no distinct colour channels. These sensors still require many of an ISP's processing stages, such as denoise, tone mapping, but not those that involve colours (such as demosaic, or colour matrices). Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-06-28libcamera: utils: Only enable utils::hex() for integer argumentsLaurent Pinchart The utils::hex() function is defined as a function template that has implementations for integer arguments only. When given a different argument type, the compiler will not catch the issue, but linking will fail: src/libcamera/libcamera.so.p/camera_sensor.cpp.o: in function `libcamera::CameraSensor::validateSensorDriver()': camera_sensor.cpp:(.text+0x1e6b): undefined reference to `libcamera::utils::_hex libcamera::utils::hex<libcamera::ControlId const*>(libcamera::ControlId const*, unsigned int)' Move the failure to compilation time by enabling the function for integer arguments only. This provides better diagnostics: ../../src/libcamera/camera_sensor.cpp: In member function ‘int libcamera::CameraSensor::validateSensorDriver()’: ../../src/libcamera/camera_sensor.cpp:199:77: error: no matching function for call to ‘hex(const libcamera::ControlId*&)’ Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> 2021-06-25libcamera/base: Validate internal headers as privateKieran Bingham Headers which must not be exposed as part of the public libcamera API should include base/private.h. Any interface which includes the private.h header will only be able to build if the libcamera_private dependency is used (or the libcamera_base_private dependency directly). Build targets which are intended to use the private API's will use the libcamera_private to handle the automatic definition of the inclusion guard. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move span to base libraryKieran Bingham Move span, and adjust the Doxygen exclusion as well. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move event_notifier to baseKieran Bingham Move the event notifier, and associated header updates. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move File to base libraryKieran Bingham The File abstraction is a base helper and not part of the libcamera API. Move it to to allow usage by users of the base library. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move extended base functionalityKieran Bingham Move the functionality for the following components to the new base support library: - BoundMethod - EventDispatcher - EventDispatcherPoll - Log - Message - Object - Signal - Semaphore - Thread - Timer While it would be preferable to see these split to move one component per commit, these components are all interdependent upon each other, which leaves us with one big change performing the move for all of them. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move class helpers to the base libraryKieran Bingham Move the class support infrastructure to the base library. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Move utils to the base libraryKieran Bingham Move the utils functionality to the libcamera/base library. Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera/base: Introduce new base libraryKieran Bingham The libcamera-base.so will feature internal support functionality that is utilised by libcamera, and can be shared in other places. This new library provides a layer beneath libcamera which provides common abstractions to internal objects. A pkg-config file is generated and named libcamera-base.pc which allows components such as external IPA modules to link directly to this library if they need. Normal applications will reference this library through the Requires: statement provided by the libcamera.pc package configuration, and linkage will be handled automatically through the pkg-config mechanisms. No code is moved to this library yet, this patch only introduces the framework, construction and linkage. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-25libcamera: Separate source and build path helpersKieran Bingham The libcameraSourcePath and libcameraBuildPath helper functions are internal and specific to libcamera needs while operating with the meson build system. In preparation for the upcoming move of utils to a common library, move these helpers out of utils and into their own build unit. Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda<hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-15libcamera: log: Destroy LogCategory instances in a controlled wayLaurent Pinchart The LogCategory instances are constructed on first use as static variables in accessor functions, following the Meyers singleton pattern. As a result, their destruction order is not guaranteed. This can cause issues as the global Logger object, constructed in a similar fashion, is accessed from the LogCategory destructor and may be destroyed first. To fix this, keep the same singleton pattern, but allocate the LogCategory instances dynamically. As they get registered with the global Logger instance, we can destroy them in the Logger destructor. This only avoids destruction order issues between LogCategory and Logger, and doesn't address yet the fact that LOG() calls from destructors of global objects may access an already destroyed Logger. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chormium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-06-14libcamera: CameraSensor: Enable retrieving supported test pattern modesHirokazu Honda This enables retrieving supported test pattern modes through CameraSensorInfo. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> 2021-06-14libcamera: CameraSensorProperties: Add table of v4l2 index and test patternHirokazu Honda The V4L2 specification defines the sensor test pattern modes through a menu control, where a numerical index is associated to a string that describes the test pattern. The index-to-pattern mapping is driver specific and requires a corresponding representation in the library. Add to the static list of CameraSensorProperties a map of indexes to libcamera::controls::TestPatternModes values to be able to map the indexes returned by the driver to the corresponding test pattern mode. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> 2021-06-14libcamera: V4L2Device: Support v4l2 menu controlHirokazu Honda This adds a support of v4l2 menu. The control info for v4l2 menu contains indices without names and 64bit values of querymenu. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> 2021-06-14libcamera: request: Add Request::cancel()Jacopo Mondi Add a cancel() function to the Request class that allows to forcefully complete the request and its associated buffers in error state. Only pending requests can be forcefully cancelled. Enforce that by asserting the request state to be RequestPending. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-06-14ipa: ipu3: Support return values from configure()Kieran Bingham The IPU3 IPA interface does not define a return value from configure(). This prevents errors from being reported back to the pipeline handler when they occur in the IPA. Update the IPU3 IPA interface and add return values to the checks in IPAIPU3::configure() accordingly Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>