libcamera/vivid.git - libcamera pipeline handler for VIVID

summary refs log tree commit diff

Age	Commit message (Collapse)	Author
2021-10-19	android: camera_metadata: Rename get() to getMetadata()	Umang Jain
	Rename CameraMetadata::get() to CameraMetadata::getMetadata() to avoid confusion with std::unique_ptr::get() when CameraMetadata is used with a std::unique_ptr. No functional changes intended in this patch. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2021-10-19	android: camera_stream: Define explicit move constructor and destructors	Laurent Pinchart
	There's no need for the move constructor and the destructor to be inline. Define them explicitly, with default implementations. This allows usage of the CameraStream class without a complete definition of the PostProcessor class. Signed-off-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: Umang Jain <umang.jain@i# SPDX-License-Identifier: CC0-1.0 libcamera_sources += files([ 'camera_sensor.cpp', 'camera_sensor_properties.cpp', ])

res that any acquire fence that hasn't been waited on to be sent back to the framework as a release fence. The CameraDevice already copies the acquire fence to the release fence when signaling request completion, but the CameraStream incorrectly closes the fence when a wait fails and sets it to -1. Fix it. Signed-off-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: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19android: camera_request: Don't embed full camera3_stream_buffer_tLaurent Pinchart The camera3_stream_buffer_t structure is meant to communicate between the camera service and the HAL. They are short-live structures that don't outlive the .process_capture_request() operation (when queuing requests) or the .process_capture_result() callback. We currently store copies of the camera3_stream_buffer_t passed to .process_capture_request() in Camera3RequestDescriptor::StreamBuffer to store the structure members that the HAL need, and reuse them when calling the .process_capture_result() callback. This is conceptually not right, as the camera3_stream_buffer_t pass to the callback are not the same objects as the ones received in .process_capture_request(). Store individual fields of the camera3_stream_buffer_t in StreamBuffer instead of copying the whole structure. This gives the HAL full control of how data is stored, and properly decouples request queueing from result reporting. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-10-19android: camera_device: Use abortRequest() instead of open-coding itLaurent Pinchart Call abortRequest() in CameraDevice::requestComplete() instead of open-coding it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19android: camera_stream: Return non-const pointer from camera3Stream()Laurent Pinchart The camera3_stream_t instances are used to interact with the camera service, whose API uses non-const pointers. Replace the const reference returned by CameraStream::camera3Stream() with a non-const pointer. It turns out that nobody calls this function, but new users will be introduced in subsequent commits. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19android: camera_stream: Pass StreamBuffer to process()Laurent Pinchart Now that we have a proper structure to model a stream buffer, pass it to CameraStream::process() instead of the camera3_stream_buffer_t. This will allow accessing other members of StreamBuffer in subsequent commits. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19android: camera_device: Create struct to track per stream bufferUmang Jain The Camera3RequestDescriptor structure stores, for each stream, the camera3_stream_buffer_t and the libcamera FrameBuffer in two separate vectors. This complicates buffer handling, as the code needs to keep both vectors in sync. Create a new structure to group all data about per-stream buffers to simplify this. As a side effect, we need to create a local vector of camera3_stream_buffer_t in CameraDevice::sendCaptureResults() as the camera3_stream_buffer_t instances stored in the new structure in Camera3RequestDescriptor are not contiguous anymore. This is a small price to pay for easier handling of buffers, and will be refactored in subsequent commits anyway. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 2021-10-19android: camera_stream: Plumb process() with Camera3RequestDescriptorUmang Jain Data (or broader context) required for post processing of a camera request is saved via Camera3RequestDescriptor. Instead of passing individual arguments to CameraStream::process(), pass the Camera3RequestDescriptor pointer to it. All the arguments necessary to run the post-processor can be accessed from the descriptor. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 2021-10-19android: camera_device: Build capture_result dynamicallyLaurent Pinchart The camera3_capture_result_t is only needed to convey capture results to the camera service through the process_capture_result() callback. There's no need to store it in the Camera3RequestDescriptor. Build it dynamically in CameraDevice::sendCaptureResults() instead. This requires storing the result metadata created in CameraDevice::requestComplete() in the Camera3RequestDescriptor. A side effect of this change is that the request metadata lifetime will match the Camera3RequestDescriptor instead of being destroyed at the end of requestComplete(). This will be needed to support asynchronous post-processing, where the request completion will be signaled to the camera service asynchronously from requestComplete(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> 2021-10-19android: camera_request: Turn struct into a classLaurent Pinchart The Camera3RequestDescriptor structure is growing into an object with member functions. Turn it into a class, uninline the destructor to reduce code size, explicitly disable copy as requests are not copyable, and delete the default constructor to force all instances to be fully constructed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19camera_device: Remove private scope of Camera3RequestDescriptorUmang Jain Camera3RequestDescriptor is a utility structure that groups information about a capture request. It can be and will be extended to preserve the context of a capture overall. Since the context of a capture needs to be shared among other classes (for e.g. CameraStream) having a private definition of the struct in CameraDevice class doesn't help. Hence, de-scope the structure so that it can be shared with other components (through references or pointers). Splitting the structure to a separate file will help avoiding circular dependencies when using it through the HAL implementation. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 2021-10-19build: Preserve upstream git versioning using meson distNaushir Patuck When distributions build and package libcamera libraries, they may not necessarily run the build in the upstream source tree. In these cases, the git SHA1 versioning information will be lost. This change addresses that problem by requiring package managers to run 'meson dist' to create a tarball of the source files and build from there. On runing 'meson dist', the utils/run-dist.sh script will create a .tarball-version file in the release tarball with the version string generated from the existing utils/gen-version.sh script. The utils/gen-version.sh script has been updated to check for the presence of this .tarball-version file and read the version string from it instead of creating one. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-10-19utils: gen-version: Pass the meson source root to the gen-version.sh scriptNaushir Patuck The gen-version.sh script expects to be called from a git repo, and sets its src_root variable accordingly. This may not always be the case if it is built from a tarball source - full support for which is in a future commit. The MESON_SOURCE_ROOT environnement variable does not get set when called from the meson vcs_tag() function, but does when called from the run_command() function, so that cannot be used either. Instead, explicitly pass the meson source root to the gen-version.sh script. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-10-19utils: hooks: pre-push: Check push to integration/* branchesLaurent Pinchart Branches named integration/* are candidates for merge in the master branch. Subject them to the same checks in the pre-push git hook. An important difference between integration branches and the master branch is that the former are typically created as new branches. We can't check the whole history as there are known bad commits, so we have to identify the base commit for the integration branch. The best approximation is to use the remote master branch for the tree being pushed to. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-19README: Document dependencies for backtrace generationLaurent Pinchart libcamera now has the ability to use libdw and libunwind to generate backtraces, in addition to the glibc backtrace() function. libdw provides the most detailed output and is highly recommended, but is limited to parsing backtraces, it doesn't support capturing them. libunwind and backtrace() provide both features. If backtrace() is available, libunwind will not bring any improvement. 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-19libcamera: v4l2_videodevice: Improve debugging when buffer is too smallLaurent Pinchart When a dequeued buffer is too small, the condition is logged and an error is returned. The logged message doesn't provide any information about the sizes, making debugging more difficult. Improve it by logging both the bytesused value and the length of each plane. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Eugen Hristev <eugen.hristev@microchip.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-19ipa: ipu3: agc: Remove "using" directive from agc.h headerLaurent Pinchart "using" directives are harmful in headers, as they propagate the namespace short-circuit to all files that include the header, directly or indirectly. Drop the directive from agc.h, and use utils::Duration explicitly. While at it, shorten the namespace qualifier from libcamera::utils:: to utils:: in agc.cpp for Duration. 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: Paul Elder <paul.elder@ideasonboard.com> 2021-10-19ipa: ipu3: awb: Don't pass member variable to member functionLaurent Pinchart The Awb::generateZones() member function fills the zones vector passed as an argument, which is actually a member variable. Use it directly in the function. 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: Paul Elder <paul.elder@ideasonboard.com> 2021-10-19android: Re-order out-of-order completion pathJacopo Mondi When the camera HAL detects an out-of-order completion of a request, it sends to the camera framework a CAMERA3_MSG_ERROR_DEVICE error. Such error not only forces the service to close the camera as prescribed by the camera3 specification, but in some implementation (specifically the ChromeOS one) it causes the camera service to abort and exit. This prevents any error messages from being printed by libcamera, as the library gets terminated before getting to that point, and also hides the printout of error messages that lead to out-of-order completion, making it impossible to get from the output log what happened. Move the call to notifyError() at the end of the error path and demote the error message to LogLevels::Error from Fatal to let the service implementation decide how to handle CAMERA3_MSG_ERROR_DEVICE errors. Before this patch, when waiting on a fence fails and the capture request is not queued to the Camera, we get an out-of-order completion but no backtrace. With this patch applied the error path is visible: ERROR HAL camera_worker.cpp:122 Failed waiting for fence: 82: Timer expired ERROR HAL camera_device.cpp:1110 '\_SB_.PCI0.I2C2.CAM0': Out-of-order completion for request 0x00007e6de4004c70 Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-19Revert "android: camera_device: Configure one stream for identical stream ↵Jacopo Mondi requests" Commit d165f7da34b8 ("android: camera_device: Configure one stream for identical stream requests") introduced the ability to generate through post-processing YUV streams of identical size and format. However the change didn't fully take into account the situation where only mapped streams are contained in the request submitted by the camera service to the HAL. In this case the Request will be queued with no buffers and refused by the Camera. Even if this seems a corner case it causes a few CTS to fail, and more problematically it triggers out-of-order completion of requests, causing the camera service to abort. ERROR Camera camera.cpp:1031 Request contains no buffers ERROR HAL camera_device.cpp:1109 '\_SB_.PCI0.I2C2.CAM0': Out-of-order completion for request 0x00007a1f1800ccd0 ERROR cros_camera_service[15706:15711]: [camera_device_adapter.cc(744)] (15711) Notify(): Fatal device error; aborting the camera service Revert the commit until a proper solution is implemented. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Hirokazu Honda <hiroh@chromium.org> 2021-10-15android: capabilities: Cap frame rate to 30 FPSJacopo Mondi Limit the reported minumum frame duration to 30 FPS. The reason to do is to bring the libcamra HAL in par with the Intel HAL implementation on IPU3 platform, where 30FPS is the frame rate used to perform quality tuning in the closed-source IPA module and has been validated as the most efficient rate for the power/performace budget. This change bring into the HAL a platform specific constraints, which might be opportune for most platforms but should rather be configurable by system integrators. Record that with a \todo entry. Also record that, even if we report a lower frame rate, we currently do not limit what the camera actually produce. 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-10-15android: capabilties: Fix ANDROID_CONTROL_AE_AVAILABLE_TARGET_FPS_RANGESJacopo Mondi As reported by the CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES documentation in the Android developer reference: "For devices advertising any color filter arrangement other than NIR, or devices not advertising color filter arrangement, this list will always include (min, max) and (max, max) where min <= 15 and max = the maximum output frame rate of the maximum YUV_420_888 output size." Collect the higher FPS of the larger YUV stream and use it with the minimum FPS rate the camera can produce to populate the ANDROID_CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES static metadata. 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-10-15android: Populate streams and duration in the same loopJacopo Mondi The ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS and ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS static metadata are populated by looping on the streamConfigurations_ vector. Unify them in a single loop to avoid repeating it. 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-15android: capabilities: Print output stream listJacopo Mondi Add a debug statement to print out the list of collected output stream and their characteristics. 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-15android: Filter preview streams on FPSJacopo Mondi Register as preview streams only streams capable of producing at least 30 FPS. This requirement comes from inspecting the existing HAL implementation on Intel IPU3 platform and from inspecting the CTS RecordingTests results. 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-15android: capabilities: Collect absolute max frame durationsJacopo Mondi While building the list of supported stream configurations also collect the absolute max frame durations to be used to populate the sensor maximum frame duration. 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-15android: capabilties: Correctly populate STALL durationsJacopo Mondi We currently hardcode 2560x1920@30FPS as the only stalling frame duration. This is of course not correct, and all the required information to properly populate the ANDROID_SCALER_AVAILABLE_STALL_DURATIONS static metadata are available from initializeStaticMetadata(). Use the collected stalling durations and sizes to properly popoulate the static property. 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-15android: capabilities: Use per-configuration durationsJacopo Mondi Use the per-configuration stream durations as collected during initializeStreamConfigurations() to populate the ANDROID_SCALER_AVAILABLE_STREAM_CONFIGURATIONS_OUTPUT static metadata. 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-15android: capabilties: Assume controls::FrameDurationLimits is supportedJacopo Mondi As we now collect the per-stream frame durations at initializeStreamConfigurations() times, the Camera is now guaranteed to support the controls::FrameDurationLimits control. Remove the check for its presence when populating the ANDROID_CONTROL_AE_AVAILABLE_TARGET_FPS_RANGES static metadata. 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-15android: capabilities: Initialize camera state when building propertiesJacopo Mondi Now that building the list of supported stream configuration requires applying a configuration to the Camera, re-initialize the camera controls by applying a configuration generated for the Viewfinder stream role before building the list of static metadata. 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-15android: capabilities: Collect per-stream frame durationsJacopo Mondi Collect the per-stream frame durations while building the list of supported stream formats and resolutions. In order to get an updated list of controls it is necessary to apply to the Camera the configuration we're testing, which was so far only validated. The per-configuration durations will be used to populate the Android ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS static metadata. 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-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: ipu3: Split controls init/updateJacopo Mondi In order to prepare for updating the Camera controls limits when a new camera configuration is applied, split the initControls() function in two: - updateControls() to actually compute controls values - initControls() to initialize the sensor configuration and call updateControls Update the functions documentation accordingly. No functional changes intended. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> 2021-10-15libcamera: ipu3: Rationalize constant expressions namesJacopo Mondi Following the previous patch that moved all the ImgU-related contants in the ImgUDevice class namespace and that aligned their naming scheme to the 'kNameOfConstant' scheme, apply the same changes to the other components of the IPU3 pipeline handler. Cosmetic change, no functional changes intended. 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-10-15libcamera: ipu3: Centralize ImgU sizes definitionJacopo Mondi The definition of several constants that describe the ImgU characteristics are spread between two files: ipu3.cpp and imgu.cpp. As the ipu3.cpp uses definitions from the imgu.cpp file, in order to remove the usage of magic numbers, it is required to move the definitions to a common header file where they are accessible to the other .cpp modules. Move all the definitions of the ImgU sizes and alignments to the ImgUDevice class as static constexpr and update their users accordingly. Cosmetic changes, no functional changes intended. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-10-15libcamera: ipu3: Use the optimal sensor sizeJacopo Mondi As reported by commit 7208e70211a6 ("libcamera: ipu3: Always use sensor full frame size") the current implementation of the IPU3 pipeline handler always uses the sensor resolution as the ImgU input frame size in order to work around an issue with the ImgU configuration procedure. Now that the frame selection policy has been modified in the CIO2Device class implementation to comply with the requirements of the ImgU configuration script we can remove the workaround and select the most opportune sensor size to feed the ImgU with. 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: v4l2_subdevice: Set format field to V4L2_FIELD_NONELaurent Pinchart libcamera doesn't support interlaced formats, set the field to V4L2_FIELD_NONE explicitly instead of relying on drivers to interpret V4L2_FIELD_ANY the way we want it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-15libcamera: media_device: Print link information when setup failsLaurent Pinchart When setting up a link fails, the error message doesn't specify which link is being acted on. This makes debugging more difficult than it should be. Improve the message by printing the link information. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-15test: Remove using namespace in header filesHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in header files in test. 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-15lc-compliance: Remove using namespace in header filesHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in header files in lc-compliance. 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-15v4l2: Remove using namespace in header filesHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in header files in v4l2. 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-15qcam: Remove using namespace in header filesHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in header files in qcam. 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-15cam: Remove using namespace in stream_options.hHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in stream_options.h 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-15ipa: raspberrypi: agc: Remove using namespace in agc.hppHirokazu Honda "using namespace" in a header file propagates the namespace to the files including the header file. So it should be avoided. This removes "using namespace" in agc.hpp. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> 2021-10-15cam: Drop frames once the capture limit is reachedLaurent Pinchart The camera session keeps requeuing requests until the capture limit is reached. This causes more request than the limit to complete, as there's a queue of requests in flight. When capturing from multiple cameras concurrently, this results in the captureDone signal being emitted for every request completion after the limit is reached, instead of once per camera session when reaching the limit. Fix this by simply dropping any request that completes after the limit is reached. We could instead avoid requeuing more requests than needed to reach the limit, but that may cause request starvation in pipelines, which are currently not handled consistently (or correctly). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-15cam: Pass stream names to FileSinkLaurent Pinchart The FileSink class constructs stream names internally the same way that the CameraSession does, except that it fails to add the camera name. This results in files being written without the camera name. This could be fixed in FileSink, but we would still duplicate code to construct stream names. Pass the stream names map from CameraSession to FileSink instead, and store it internally. Fixes: 02001fecb0f5 ("cam: Turn BufferWriter into a FrameSink") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 2021-10-15cam: Rename CameraSession::streamName_ to streamNames_Laurent Pinchart The streamName_ map contains names for all streams, rename it to streamNames_ to make this more explicit. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@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>