summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-10-13README: Document GST_DEBUG values to debug libcamerasrcLaurent Pinchart
Problems with libcamerasrc are reported quite frequently. To help users diagnosing them, document how to obtain libcamerasrc debug messages through GST_DEBUG. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-12android: camera_device: Fix crash in calling CameraDevice::close()Hirokazu Honda
The problem is happening because we seem to add a CameraStream associated buffer (depending on the CameraStream::Type) to the Request, in CameraDevice::processCaptureRequest(). However, when the camera stops, all the current buffers are marked with FrameMetadata::FrameCancelled and proceed to completion. But the buffer associated with the CameraStream (that was previously added to the request) has now been cleared out with a part of streams_.clear(), even before the camera stop() has been invoked. Any access to those request buffers after they have been cleared, will result in a crash. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2021-10-10android: camera_stream: Fix error message for buffer creationLaurent Pinchart
Creating a CameraBuffer instance doesn't map memory. Fix the error message accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-10-07pipeline: raspberrypi: Create empty control lists correctlyDavid Plowman
When the pipeline handler start() method is supplied with a NULL list of controls, we send an empty control list to the IPA. When the IPA is running in isolated mode the control list goes through the data serializer, for which it must be marked correctly as a list of "controls::controls", otherwise the IPA process will abort. The IPA has a similar problem returning a control list in its configure() method. We must be careful to initialise it properly even when empty. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-07README: Add lc-compliance dependenciesHirokazu Honda
libevent-dev and libgtest-dev are required for lc-compliance. Write them into lc-compliance dependencies in README.rst. 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-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-10-06ipa: ipu3: agc: Rewrite and simplify the brightness loopJean-Michel Hautbois
Now that we know how the AWB statistics are formatted, use a simplified loop in processBrightness() to parse the green values and get the histogram. 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-10-06ipa: ipu3: awb: Introduce Black Level CorrectionJean-Michel Hautbois
The pixels output by the camera normally include a black level, because sensors do not always report a signal level of '0' for black. Pixels at or below this level should be considered black and to achieve that, we need to substract an offset to all the pixels. This can be taken into account by reading the lowest value of a special region on sensors which is not exposed to light. This provides a substracting factor to be able to adjust the expected black levels in the resulting images. For a camera outputting 10-bit pixel values (in the range 0 to 1023) a typical black level might be 64. It is a fixed value, obtained by capturing a raw frame with minimum exposure and gain fixed to 1.0 while covering the sensor (the darker the better). We consider it good enough as a very first approximation, until we measure it during a tuning process and include it in a configuration file 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-10-06ipa: ipu3: awb: Use the line stride for the statsJean-Michel Hautbois
The statistics buffer 'ipu3_uapi_awb_raw_buffer' stores the ImgU calculation results in a buffer aligned horizontally to a multiple of 4 cells. The AWB loop should take care of it to add the proper offset between lines and avoid any staircase effect. It is no longer required to pass the grid configuration context to the private functions called from process() which simplifies the code flow. 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-10-06ipa: ipu3: awb: Correct the gain multipliersJean-Michel Hautbois
The gains have a precision u3.13, range [0, 8[ which means that a gain multiplier value of 1.0 is represented as a multiplication by 8192 in the ImgU. Correct the gains as this was misunderstood in the first place. 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-10-06ipa: ipu3: awb: Correct the relevant zones proportionJean-Michel Hautbois
The algorithm uses the statistics of a cell only if there is not too much saturated pixels in it. The grey world algorithm works fine when there are a limited number of outliers. Consider a valid zone to be at least 80% of unsaturated cells in it. This value could very well be configurable, and make the algorithm more or less tolerant. While at it, implement it in a configure() call as it will not change during execution, and cache the cellsPerZone values estimated with std::round as we are using cmath. 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-10-06ipa: ipu3: Change limits and split loops in calculateBdsGrid()Jean-Michel Hautbois
The loops over the width and height of the image when calculating the BDS grid parameters are nested, but they're actually independent. Split them to reduce the complexity. While at it, split out the constants to documented const expressions for the grid sizes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 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-10-06ipa: ipu3: Change the limits of the AWB statsJean-Michel Hautbois
Until now, the limits used to calculate the grid based on the Bayer Down Scaler configuration where taken from the kernel documentation [0]. While testing and understanding the format of the ImgU statistics, it appears that the ones defined in CrOS [1] are the correct ones. Use those. [0] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-meta-intel-ipu3.html?highlight=v4l2_meta_fmt_ipu3_params#intel-ipu3-imgu-uapi-data-types [1] https://chromium.googlesource.com/chromiumos/platform/arc-camera/+/refs/heads/master/hal/intel/include/ia_imaging/awb_public.h 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-10-06ipa: ipu3: awb: Make the naming consistentJean-Michel Hautbois
The variables mix the terms cell, region and zone. It can confuse the reader, and make the algorithm more difficult to follow. Rename the local variables to be consistent with their definitions: - Cells are defined in Pixels - Zones are defined in Cells There is no "region" as such, so replace it with the correct term. 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-10-06ipa: ipu3: Change Accumulator structure layoutJean-Michel Hautbois
The pixel component sums for the Accumulator are inconsistent with other similar structures such as the IPAFrameContext::awb::gains. Group the red, green, and blue sums together in a struct and store them as uint64_t to reduce potential architectural differences. 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-10-06ipa: ipu3: Rename IspStatsRegion to AccumulatorJean-Michel Hautbois
The IspStatsRegion structure was introduced as an attempt to prepare for a generic AWB algorithm structure. The structure name by itself is not explicit and it is too optimistic to try and make a generic one for now. Its role is to accumulate the pixels in a given zone. Rename it to accumulator, and remove the uncounted field at the same time. It is always possible to know how many pixels are not relevant for the algorithm by calculating total-counted. The uncounted field was only declared and not used. Amend the documentation accordingly. 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-10-06ipa: ipu3: Move the AWB stats structuresJean-Michel Hautbois
The structure Ipu3AwbCell describes the AWB stats layout on the kernel side. We will need it to be used by the AGC algorithm to be introduced later, so let's make it visible from ipa::ipu3::algorithms and not only for the AWB class. The IspStatsRegion will be needed by AGC too, so let's move it in the same namespace too. 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-10-06android: camera_stream: Set right format for processor output bufferHirokazu Honda
CameraStream always sets the format of processor output buffer to MJPEG. This fixes the issue. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-05libcamera: Fix crash caused by reading uninitialised delayed controlsDavid Plowman
The cause is that we read out delayed values using a frame's sequence number (DelayedControls::get). But we fill the values up (DelayedControls::applyControls) incrementing writeCount by only one even if the sequence number has jumped by several since last time. This is exactly what happens when frames are being dropped. So the fix is to increment writeCount by "as much as the sequence number has jumped since last time", which means that we just follow the sequence number directly. Bug: https://bugs.libcamera.org/show_bug.cgi?id=74 Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-05cam: kms_sink: Print display pipeline configurationLaurent Pinchart
It can be useful, for diagnosis purpose, to know what plane and CRTC the KMS sink auto-selects. Print the display pipeline configuration at start time. 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-10-05libcamera: camera_sensor: Reverse the key and value of test pattern mode mapHirokazu Honda
The key and value of the test pattern mode are originally the index of v4l2 control and the corresponding test pattern mode control value. This key and value are useful in the initialization for reporting available test pattern modes. However, the map of the reversed key and value is much more useful in applying a requested test pattern mode. Reverses the key and value of the map as the initialization is one time but the test pattern mode request will be multiple times. 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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-05gstreamer: Check if Stream configurations were generated correctlyJavier Martinez Canillas
Currently, the gst_libcamera_device_new() function assumes that a call to Camera::generateConfiguration() will always succeed, but that may not be the case and the return value must to be checked. Otherwise, this could lead to a NULL pointer dereference if the pipeline handler fails to generate a config for the VideoRecording stream role. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-10-04test: gstreamer: Remove unnecessary header file includesVedant Paranjape
Remove header files which were not being used in the test code. The following headers were removed from the gstreamer_single_stream_test: - libcamera/base/utils.h - libcamera/internal/source_paths.h Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.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-09-30android: camera_device: Send capture results by inspecting the queueUmang Jain
There is a possibility that an out-of-order completion of capture request happens by calling process_capture_result() directly on error paths. The framework expects that errors should be notified as soon as possible, but the request completion order should remain intact. An existing instance of this is abortRequest(), which sends the capture results on flushing state, without considering order-of-completion. Since we have a queue of Camera3RequestDescriptor tracking each capture request placed by framework to libcamera HAL, we should be only sending back capture results from a single location, by inspecting the queue. As per the patch, this now happens in CameraDevice::sendCaptureResults(). Each descriptor is now equipped with its own status to denote whether the capture request is complete and ready to be send back to the framework or needs to be waited upon. This ensures that the order of completion is respected for the requests. Since we are fixing out-of-order request completion in abortRequest(), change the function to read from the Camera3RequestDescriptor directly, instead of camera3_capture_request_t. The descriptor should have all the information necessary to set the request buffers' state to error. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_device: Mark abortRequest() and notifyError() as constUmang Jain
abortRequest() and notifyError() do not modify any members of CameraDevice hence, these functions can be const. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_device: Transform descriptors_ map to queueUmang Jain
The descriptors_ map holds Camera3RequestDescriptor(s) which are per-capture requests placed by the framework to libcamera HAL. CameraDevice::requestComplete() looks for the descriptor for which the camera request has been completed and removes it from the map. Since the requests are placed in form of FIFO and the framework expects the order of completion to be FIFO as well, this calls for a need of a queue rather than a std::map. This patch still keeps the same lifetime of Camera3RequestDescriptor as before i.e. in the requestComplete(). Previously, a descriptor was extracted from the map and its lifetime was bound to requestComplete(). The lifetime is kept the same by manually calling .pop_front() on the queue. In the subsequent commit, this is likely to change with a centralized location of dropping descriptors from the queue for request completion. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-30android: camera_worker: Use Camera3RequestDescriptor as cookieUmang Jain
Use Camera3RequestDescriptor as cookie for the Capture Request. The cookie is used to lookup descriptors map in CameraDevice::requestComplete(). The map will be transformed to a queue in subsequent commit. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-29android: Wait on fences in CameraStream::process()Jacopo Mondi
Acquire fences for streams of type Mapped generated by post-processing are not correctly handled and are currently ignored by the camera HAL. Fix this by adding CameraStream::waitFence(), executed before starting the post-processing in CameraStream::process(). The change applies to all streams generated by post-processing (Mapped and Internal) but currently acquire fences of Internal streams are handled by the camera worker. Postpone that to post-processing time by passing -1 to the Worker for Internal streams. Also correct the release_fence handling for failed captures, as the framework requires the release fences to be set to the acquire fence value if the acquire fence has not been waited on. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Tested-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@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-28meson: Set a SONAME version in the libcamera librariesJavier Martinez Canillas
The libcamera and libcamera-base libraries are currently unversioned, but donwstream users expect these to have a proper SONAME version in order to package them. A stable release has not yet happened because the project is still under development and the API/ABI might change. But having a versioned SONAME would allow distributions to package libcamera, without the need to add any downstream patch to set the version. Since the "0.0.0" version is already used in different places, let's also use that as the library version. The meson build system will use the first part of the version ("0") as the SONAME version, which is aligned with the convention used by other projects: $ ls /lib64/libcamera*so* -1 /lib64/libcamera-base.so /lib64/libcamera-base.so.0 /lib64/libcamera-base.so.0.0.0 /lib64/libcamera.so /lib64/libcamera.so.0 /lib64/libcamera.so.0.0.0 $ objdump -p /lib64/libcamera.so.0.0.0 | grep SONAME SONAME libcamera.so.0 Signed-off-by: Javier Martinez Canillas <javierm@redhat.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> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-28android: camera_device: Fix race on queuing capture requestUmang Jain
The Camera3RequestDescriptor containing the capture request is added to the descriptors_ map after a call to CameraWorker::queueRequest(). This is a race condition since CameraWorker::queueRequest() queues requests to libcamera::Camera asynchronously. The requests may thus complete before they get added to descriptors_, in which case requestComplete() will fail to lookup the request in the map. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-09-28gstreamer: Fix spelling of the work manager used in a util functionVedant Paranjape
Fix all name in all instances of the function gst_libcamera_get_camera_mananger to gst_libcamera_get_camera_manager. Spelling of manager was incorrect. This patch has no functional changes. Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2021-09-28libcamera: control_serializer: Fix usage of uninitialized variableLaurent Pinchart
The idMap variable may be used uninitialized in the ControlSerializer::deserialize<ControlList>() function as reported by gcc 11: ../../src/libcamera/control_serializer.cpp: In member function ‘T libcamera::ControlSerializer::deserialize(libcamera::ByteStreamBuffer&) [with T = libcamera::ControlList]’: ../../src/libcamera/control_serializer.cpp:609:33: error: ‘idMap’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 609 | ControlList ctrls(*idMap); | This is due to a missing default case in a switch/case. Fix it by adding the default case. Fixes: 6b1404fc4836 ("libcamera: control_serializer: Fix usage of uninitialized variable") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2021-09-27Documentation: application-developer: Add camera detection checkLaurent Pinchart
The simple-cam application has a check to ensure that at least one camera is present before attempting to access the first camera, to avoid a crash. Update the application developer's guide to match this behaviour. 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-27Documentation: application-developer: Use correct type to store sizeLaurent Pinchart
The return type of std::vector::size() is size_t. Use the same type, instead of unsigned int, to store its return value when retrieving the number of allocated buffers. 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-27Documentation: application-developer: Make global variable staticLaurent Pinchart
The global "camera" variable isn't accessed outside of its compilation unit. Make it static. 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-27android: Fix generation of thumbnail for EXIF dataUmang Jain
Generation of thumbnail is not occuring currently because ANDROID_JPEG_THUMBNAIL_SIZE is not set for request metadata passed to PostProcessorJpeg::process(). The commit 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata") introduced the mechanism to retrieve the thumbanil size from request metadata, however it didn't add the counterpart i.e. inserting the size in the request metadata in request metadata template, at the first place. The patch fixes this issue by setting ANDROID_JPEG_THUMBNAIL_SIZE in the request metadata template populated by CameraCapabilities::requestTemplatePreview(). The value for ANDROID_JPEG_THUMBNAIL_SIZE is set to be the first non-zero size reported by static metadata ANDROID_JPEG_AVAILABLE_THUMBNAIL_SIZES. Fixes: 1264628d3c92("android: jpeg: Configure thumbnailer based on request metadata") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
2021-09-27android: camera_capabilities: Clarify CameraMetadata allocationUmang Jain
CameraMetadata's constructor take in number of entries and number of bytes to be allocated for those entries. However, CameraMetadata is already capable of resizing its container on the fly, in case more entries are added to it. Hence, the numbers passed in during the construction acts as hint values for initialization. Clarify this in CameraCapabilities::requestTemplatePreview() and remove the \todo, as the arguments and the \todo gives the perspective that we need to be quite accurate with the numbers of entries / bytes, which is not the case. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
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: Serialize info::def()Jacopo Mondi
The ControlInfo class was originally designed to only transport the control's minimum and maximum values which represent the control's valid limits. Later the default value of the control has been added to the ControlInfo class, but the control serializer implementation has not been updated accordingly. This causes issues in IPA modules making use of ControlInfo::def() as, when running in isolation, they would receive 0. Fix that by serializing and deserializing the additional ControlValue and update the protocol description accordingly. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@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-27ipa: proxy_worker: Reset ControlSerializer on workerJacopo Mondi
When running the IPA in isolated mode, each side of the IPC boundary has an instance of the ControlSerializer class which is used to serializer/deserialize controls before transmitting them on the wire. The IPAProxyWorker, which creates and manages the process the IPA runs in, does not reset its ControlSerializer upon an IPA::configure() call, while the IPAProxy does, effectively creating a misalignment between the two sides of the fence. This obviously creates issues as one side of the IPC runs with a populated and possibly stale cache of ControlInfoMap references, while the other side gets reset every time a new configuration is applied to the Camera. Fix that by resetting the IPAProxyWorker ControlSerializer on an IPA configure() call. This change fixes an issue which is easily triggered by running two consecutive capture sessions with the IPA running in isolated mode: ERROR Serializer control_serializer.cpp:520 Can't deserialize ControlList: unknown ControlInfoMap Fixes: 7832e19a599e ("utils: ipc: add templates for code generation for IPC mechanism") 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-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-26libcamera: camera_manager: Fix utils.h #include locationLaurent Pinchart
The utils.h header #include is separate from the rest of the group for no reason. Move it to where it should be. 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>
2021-09-24libcamera: Standardize URLs to git repositoriesLaurent Pinchart
When the libcamera project was started, we had no public git tree hosted on git.libcamera.org. The problem has been addressed a while ago, and the git.linuxtv.org libcamera repository is now a mirror of the main git tree. The mirror is useful to benefit from the linuxtv.org automated compile tests, but it can also confuse users who don't know where the official version is. To try and clarify this, use the git.libcamera.org URL consistently through the project. This doesn't void the validatity of the linuxtv.org repository which will continue to mirror the libcamera.org repository. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-24android: camera_device: Return unique_ptr from createFrameBufferLaurent Pinchart
Returning a non-managed pointer can cause leaks. Use a unique_ptr<> instead to avoid possible future issues. The std::move() for the planes argument to the FrameBuffer constructor is dropped as it's misleading. FrameBuffer has no constructor that takes an rvalue reference to planes, so the vector was copied despite the move. This only clarifies the intent, no functional change is introduced. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-24libcamera: v4l2_videodevice: Don't move planes to construct FrameBufferLaurent Pinchart
The FrameBuffer class has no constructor that takes an rvalue reference to planes. The std::move() is thus misleading as a copy will still take place. Drop it to clarify the code, no functional change is introduced. 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: Paul Elder <paul.elder@ideasonboard.com>
2021-09-24test: gstreamer: Add a test for gstreamer multi streamVedant Paranjape
This patch adds a test to test if multi stream using libcamera's gstreamer element works. Test will run only on devices that support multistream capture, eg., devices that use IPU3 and raspberrypi pipeline. This was tested on a Raspberry Pi 4B+. Signed-off-by: Vedant Paranjape <vedantparanjape160201@gmail.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2021-09-23test: v4l2_compat: Skip vimc as a test candidatePaul Elder
As the vimc scaler prevents us from passing v4l2-compliance, skip it until the fix has been merged. Instead of removing it from the supported_pipelines list, add an extra check, since we will have the same construct later when we check for the kernel version. 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>