summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2021-11-02include: drm_fourcc: Add R10 and R12 FourCCLaurent Pinchart
Add FourCCs for 10- and 12-bit red format with padding to 16 bits. This is merged in the upstream kernel as 31fa8cbce466 ("drm: Add R10 and R12 FourCC") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-27libcamera: v4l2_videodevice: provide hasMediaController()Kieran Bingham
The V4L2Capability has helpers to interogate the capabilities of a device. V4L2VideoDevice::enumPixelformats accesses the raw capabilites to check if the device is supported by a MediaController device. Provide a helper, and update the usage. Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-25libcamera: request: Use external CameraControlValidatorKieran Bingham
Each Request is currently creating its own CameraControlValidator using the Camera instance at construction. Now that the Camera exposes its own CameraControlValidator on its private interface, use that one on all Requests. 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-10-25libcamera: camera: Create a CameraControlValidatorKieran Bingham
Create a Camera-specific CameraControlValidator for the Camera instance. This will allow requests to use a single validator instance without having to construct their own. 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-10-15ipa: ipu3: Update camera controls in configure()Jacopo Mondi
When a new CameraConfiguration is applied to the Camera the IPA is configured as well, using the newly applied sensor configuration and its updated V4L2 controls. Also update the Camera controls at IPA::configure() time by re-computing the controls::ExposureTime and controls::FrameDurationLimits limits and update the controls on the pipeline handler side after having configured the IPA. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-15libcamera: base: backtrace: Fallback to libunwind for symbolic namesLaurent Pinchart
libunwind has an API to provide symbolic names for functions. It's less optimal than using backtrace_symbols() or libdw, as it doesn't allow deferring the symbolic names lookup, but it can be usefull as a fallback if no other option is available. A sample backtrace when falling back to libunwind looks like libcamera::VimcCameraData::init()+0xbd libcamera::PipelineHandlerVimc::match(libcamera::DeviceEnumerator*)+0x3e0 libcamera::CameraManager::Private::createPipelineHandlers()+0x1a7 libcamera::CameraManager::Private::init()+0x98 libcamera::CameraManager::Private::run()+0x9f libcamera::Thread::startThread()+0xee decltype(*(std::__1::forward<libcamera::Thread*>(fp0)).*fp()) std::__1::__invoke<void (libcamera::Thread::*)(), libcamera::Thread*, void>(void (libcamera::Thread::*&&)(), libcamera::Thread*&&)+0x77 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (libcamera::Thread::*)(), libcamera::Thread*, 2ul>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (libcamera::Thread::*)(), libcamera::Thread*>&, std::__1::__tuple_indices<2ul>)+0x3e void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (libcamera::Thread::*)(), libcamera::Thread*> >(void*)+0x62 start_thread+0xde ??? Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-15libcamera: base: backtrace: Use libunwind when availableLaurent Pinchart
libunwind is an alternative to glibc's backtrace() to extract a backtrace. Use it when available to extend backtrace support to more platforms. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-15libcamera: base: Add Backtrace classLaurent Pinchart
Create a new class to abstract generation and access to call stack backtraces. The current implementation depends on the glibc backtrace() implementation and is copied from the logger. Future development will bring support for libunwind, transparently for the users of the class. The logger backtrace implementation is dropped, replaced by usage of the new Backtrace class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-15libcamera: geometry: Add Size members to grown or shrink by a marginLaurent Pinchart
Add four new member functions to the Size class (two in-place and two const) to grow and shrink a Size by given margins. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-10-06ipa: ipu3: Replace ipa::ipu3::algorithms::Ipu3AwbCellJean-Michel Hautbois
The intel-ipu3.h public interface from the kernel does not define how to parse the statistics for a cell. This had to be identified by a process of reverse engineering, and later identifying the structures from [0] leading to our custom definition of struct Ipu3AwbCell. [0] https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/refs/heads/master/hal/intel/include/ia_imaging/awb_public.h To improve the kernel interface, a proposal has been made to the linux-kernel [1] to incorporate the memory layout for each cell into the intel-ipu3 header directly. [1] https://lore.kernel.org/linux-media/20211005202019.253353-1-jeanmichel.hautbois@ideasonboard.com/ Update our local copy of the intel-ipu3.h to match the proposal and change the AGC and AWB algorithms to reference that structure directly, allowing us to remove the deprecated custom Ipu3AwbCell definition. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-29libcamera: Simplify header install paths with shortcut variablesLaurent Pinchart
Create local install_dir meson variable to store the full path to the installation directory for the libcamera and ipa headers. This shortens lines and avoids duplicating calls to get_option('includedir'). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-28libcamera: Fix base and ipa include dirLaurent Pinchart
All libcamera headers are meant to be installed in ${prefix}/include/libcamera/libcamera, with pkgconfig specifying the include directory as `-I ${prefix}/include/libcamera`. Applications then include the headers with `#include <libcamera/camera.h>`. The base and ipa headers are meant to be installed in subdirectories of the libcamera headers directory, but are mistakenly installed one level too high, in ${prefix}/include/libcamera. This leads to compilation failures when including the base or ipa header. Fix this by setting the meson libcamera_include_dir variable to the libcamera headers directory. All other header paths are derived from that variable and are now correct. Reported-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm> Bug: https://bugs.libcamera.org/show_bug.cgi?id=79 Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-27libcamera: control_serializer: Separate the handles spaceJacopo Mondi
Two independent instances of the ControlSerializer class are in use at the IPC boundaries, one in the Proxy class that serializes data from the pipeline handler to the IPA, and one in the ProxyWorker which serializes data in the opposite direction. Each instance operates autonomously, without any centralized point of control, and each one assigns a numerical handle to each ControlInfoMap it serializes. This creates a risk of potential collision on the handle values, as both instances will use the same numerical space and are not aware of what handles has been already used by the instance "on the other side". To fix that, partition the handles numerical space by initializing the control serializer with a seed according to the role of the component that creates the serializer and increment the handle number by 2, to avoid any collision risk. While this is temporary and rather hacky solution, it solves an issue with isolated IPA modules without too much complexity added. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-27libcamera: control_serializer: Use the right idmapJacopo Mondi
When a ControlList is deserialized, the code searches for a valid ControlInfoMap in the local cache and use its id map to initialize the list. If no valid ControlInfoMap is found, as it's usually the case for lists transporting libcamera controls and properties, the globally defined controls::controls id map is used unconditionally. This breaks the deserialization of libcamera properties, for which a wrong idmap is used at construction time. As the serialization header now transports an id_map_type field, store the idmap type at serialization time, and re-use it at deserialization time to identify the correct id map. Also make the validation stricter by imposing to list of V4L2 controls to have an associated ControlInfoMap available, as there is no globally defined idmap for such controls. To be able to retrieve the idmap associated with a ControlList, add an accessor function to the ControlList class. It might be worth in future using a ControlInfoMap to initialize the deserialized ControlList to implement controls validation against their limit. As such validation is not implemented at the moment, maintain the current behaviour and initialize the control list with an idmap. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-27libcamera: ipu3: Drop entityControls mapJacopo Mondi
The IPA::configure() function has an IPAConfigInfo parameters which contains a map of numerical indexes to ControlInfoMap instances. This is a leftover of the old IPA protocol, where it was not possible to specify a rich interface as it is possible today and each entity ControlInfoMap was indexed by a numerical id and stored in a map. Now that the IPA interface allows to specify parameters by name, drop the map and send the sensor's control info map only. If we'll need more ControlInfoMap to be shared with the IPA, a new parameter can be added to IPAConfigInfo. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-10libcamera: v4l2_pixelformat: Add helper function to get the descriptionPaul Elder
Add a helper function to V4L2PixelFormat for retrieving the V4L2 description string. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-10libcamera: v4l2_pixelformat: Add V4L2 description stringsPaul Elder
Add V4L2 description strings to the map of V4L2 formats. To achieve this, create an Info struct to wrap them. Update the one current user of the old map. This will be used later in the V4L2 compatibility layer to report the V4L2 format description. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-09libcamera: controls: Use a const ControlValidatorKieran Bingham
The ControlValidator passed to a ControlList constructor is used, but not modified. Make it const. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-09-07libcamera: framebuffer: Prevent modifying the number of metadata planesLaurent Pinchart
The number of metadata planes should always match the number of frame buffer planes. Enforce this by making the vector private and providing accessor functions. As this changes the public API, update all in-tree users accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: v4l2_videodevice: Cache PixelFormatInfoLaurent Pinchart
Cache the PixelFormatInfo instead of looking it up in every call to createBuffer(). This prepares for usage of the info in queueBuffer(), to avoid a looking every time a buffer is queued. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: framebuffer: Add a function to check if planes are contiguousLaurent Pinchart
Multi-planar frame buffers can store their planes contiguously in memory, or split them in discontiguous memory areas. Add a private function to check in which of these two categories the frame buffer belongs. This will be used to correctly handle the differences between the V4L2 single and multi planar APIs. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: framebuffer: Move planes check to constructorLaurent Pinchart
The FrameBuffer::planes() function checks that planes are correctly initialized with an offset. This can be done at construction time instead, as the planes are constant. The backtrace generated by the assertion will show where the faulty frame buffer is created instead of where it is used, easing debugging. As the runtime overhead is reduced, there's no real need to drop the assertion in the future anymore, it can be useful to ensure that the planes are correctly populated by the caller. Drop the comment that calls for removing the check. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: formats: Support V4L2 non-contiguous formatsLaurent Pinchart
V4L2 describes multi-planar formats with different 4CCs depending on whether or not the planes are stored contiguously in memory. Support this when translating between PixelFormat and V4L2PixelFormat. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
2021-09-07libcamera: formats: Add planeSize() helpers to PixelFormatInfoLaurent Pinchart
Add two helpers functions to the PixelFormatInfo class to compute the byte size of a given plane, taking the frame size, the stride, the alignment constraints and the vertical subsampling into account. Use the new functions through the code base to replace manual implementations. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: formats: Move plane info structure to PixelFormatInfoLaurent Pinchart
Move the PixelFormatPlaneInfo structure within the PixelFormatInfo class definition and rename it to Plane, to align the naming scheme with other parts of libcamera, such as FrameBuffer::Plane or FrameMetadata::Plane. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-07libcamera: v4l2_videodevice: Drop toV4L2PixelFormat()Laurent Pinchart
The V4L2VideoDevice::toV4L2PixelFormat() function is incorrectly implemented, as it will pick a multi-planar format if the device supports the multi-planar API, even if only single-planar formats are supported. This currently works because the implementation calls V4L2PixelFormat::fromPixelFormat(), which ignores the multiplanar argument and always returns a single-planar format. Fixing this isn't trivial. As we don't need to support multi-planar V4L2 formats at this point, drop the function instead of pretending everything is fine, and call V4L2PixelFormat::fromPixelFormat() directly from pipeline handlers. As the single-planar case is the most common, set the multiplanar argument to false by default to avoid long lines. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: file_descriptor: Add a function to retrieve the inodeLaurent Pinchart
The inode is useful to check if two file descriptors refer to the same file. Add a function to retrieve it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-07libcamera: base: utils: Use size_t for index in utils::enumerate()Laurent Pinchart
The index generated by utils::enumerate() is an iteration counter, which should thus be positive. Use std::size_t instead of the difference_type of the container. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-02libcamera: Drop emitter object pointer from signal argumentsLaurent Pinchart
Many signals used in internal and public APIs carry the emitter pointer as a signal argument. This was done to allow slots connected to multiple signal instances to differentiate between emitters. While starting from a good intention of facilitating the implementation of slots, it turned out to be a bad API design as the signal isn't meant to know what it will be connected to, and thus shouldn't carry parameters that are solely meant to support a use case specific to the connected slot. These pointers turn out to be unused in all slots but one. In the only case where it is needed, it can be obtained by wrapping the slot in a lambda function when connecting the signal. Do so, and drop the emitter pointer from all signals. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-02libcamera: base: signal: Support connecting signals to functorsLaurent Pinchart
It can be useful to connect a signal to a functor, and in particular a lambda function, while still operating in the context of a receiver object (to support both object-based disconnection and queued connections to Object instances). Add a BoundMethodFunctor class to bind a functor, and a corresponding Signal::connect() function. There is no corresponding disconnect() function, as a lambda passed to connect() can't be later passed to disconnect(). Disconnection typically uses disconnect(T *object), which will cover the vast majority of use cases. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-02libcamera: base: bound_method: Remove BoundMethodArgs specializationLaurent Pinchart
The BoundMethodArgs specialization for the void return type is only needed to avoid accessing the ret_ member variable that is lacking from the corresponding BoundMethodPack specialization. As the member variable is only accessed in the invokePack() function, instead of specializing the whole class we can use SFINAE to select between two different implementations of the function. SFINAE can only depend on the function template parameters, not the parameters of the class template in which the function is defined: "Only the failures in the types and expressions in the immediate context of the function type or its template parameter types are SFINAE errors." We thus can't use the type R in an std::enable_if expression for the invokePack() function. To work around this, we have to add a type T to the function template definition, which defaults to R, and use T with std::enable_if. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-02libcamera: base: bound_method: Remove BoundMethodMember specializationLaurent Pinchart
The BoundMethodMember specialization for the void return type is only needed to avoid accessing the ret_ member variable that is lacking from the corresponding BoundMethodPack specialization. By adding a BoundMethodPack::returnValue() function to read the member variable, we can remove the complete BoundMethodMember specialization. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-08-31libcamera: media_object: Expose entity typeLaurent Pinchart
Add a new field to the MediaEntity class to identify the type of interface it exposes to userspace. The MediaEntity constructor is changed to take a media_v2_interface pointer instead of just the device node major and minor to have access to the interface type. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Martin Kepplinger <martin.kepplinger@puri.sm>
2021-08-31libcamera: mapped_framebuffer: Rename maps() to planes()Hirokazu Honda
MappedFrameBuffer::maps() returns planes_. This renames the function name to planes(). 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-31libcamera: camera_sensor: Transform CameraSensor::sizes()Umang Jain
In CameraSensor, the mbusCodes() and sizes() accessor functions retrieves all the supported media bus codes and the supported sizes respectively. However, this is quite limiting since the caller probably isn't in a position to match which range of sizes are supported for a particular mbusCode. Hence, the caller is most likely interested to know about the sizes supported for a particular media bus code. This patch transforms the existing CameraSensor::sizes() to CameraSensor::sizes(mbuscode) to achieve that goal. The patch also transforms existing CIO2Device::sizes() in IPU3 pipeline handler to CIO2Device::sizes(PixelFormat) on a similar principle. The function is then plumbed to CameraSensor::sizes(mbusCode) to enumerate the per-format sizes as required in PipelineHandlerIPU3::generateConfiguration(). Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-30libcamera: framebuffer: Add assertion to detect offset is unfilledHirokazu Honda
The offset variable is introduced to FrameBuffer::Plane. In order to detect that the plane is used while the offset is not set, this adds the assertion to FrameBuffer::planes(). It should be removed in the future. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: v4l2_videodevice: Create color-format planes in createBuffer()Hirokazu Honda
V4L2VideDevice::createBuffer() creates the same number of FrameBuffer::Planes as V4L2 format planes. Therefore, if the v4l2 format single is single-planar format, the created number of FrameBuffer::Planes is 1. It should rather create the same number of FrameBuffer::Planes as the color format planes. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: mapped_framebuffer: Return plane begin address by ↵Hirokazu Honda
MappedBuffer::maps() MappedBuffer::maps() returns std::vector<MappedBuffer::Plane>. Plane has the address, but the address points the beginning of the buffer containing the plane. This makes the Plane point the beginning of the plane. So MappedBuffer::maps()[i].data() returns the address of i-th plane. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-30libcamera: framebuffer: Add offset to FrameBuffer::PlaneHirokazu Honda
This adds offset to FrameBuffer::Plane. It enables representing frame buffers that store planes in the same dmabuf at different offsets, as for instance required by the V4L2 NV12 pixel format. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-27base: class: Remove undesired semi-colon from LIBCAMERA_O_PTRKieran Bingham
The LIBCAMERA_O_PTR() define adds the ';' at the end of the templated call to _o(). While this works for the only current user in camera_manager.cpp, even the statement there adds another semi-colon following it. The addition of the semi-colon in the define unnecessarily prohibits the macro from being used in places other than the end of a statement. Remove it. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-08-23libcamera: controls: Initialize ControlInfoMap::idmap_Jacopo Mondi
The compiler generated constructor does not initialize the ControlInfoMap::idmap_ field. Fix this by explicitly initializing the field in the class declaration. Reported-by: Coverity CID=354657 Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-08-19ipa: Use FileDescriptor instead of int in layers above IPC payloadPaul 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 IPCUnixSocket::Payload converts between FileDescriptor and int. Additionally, change the data portion of the serialized form of FileDescriptor to a 32-bit unsigned integer, for alightnment purposes and in preparation for conversion to an index into the fd array. Also update the deserializer of FrameBuffer::Plane accordingly. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2021-08-17libcamera: pipeline_handler: Drop controls() and properties() functionsLaurent Pinchart
The PipelineHandler controls() and properties() functions are only used by the Camera class. Now that the controls and properties are stored in the Camera::Private class, we can drop those functions and access the private data directly in Camera::controls() and Camera::properties(). Suggested-by: Jacopo Mondi <jacopo@jmondi.org> 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-17libcamera: pipeline_handler: Drop CameraData classLaurent Pinchart
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>