summaryrefslogtreecommitdiff
path: root/src/libcamera
AgeCommit message (Collapse)Author
2022-11-17libcamera: pipeline: Add IMX8 ISI pipelineJacopo Mondi
Add a pipeline handler for the ISI capture interface found on several versions of the i.MX8 SoC generation. The pipeline handler supports capturing multiple streams from the same camera in YUV, RGB or RAW formats. The number of streams is limited by the number of ISI pipelines, and is currently hardcoded to 2 as the code has been tested on the i.MX8MP only. Further development will make this dynamic to support other SoCs. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-11-14libcamera: pipeline: raspberrypi: Free buffers when a camera is releasedDavid Plowman
Implement the PipelineHandlerRPi::releaseDevice method which allows us to free any allocated buffers when a camera is released. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-14libcamera: Add a PipelineHandler::releaseDevice methodDavid Plowman
This notifies pipeline handlers when a camera is released, in case they want to free any resources or memory buffers. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-14Revert "pipeline: raspberrypi: Do not unconditionally free buffers on close"David Plowman
This reverts commit 30d704732badc675f72fe73d14749669cb645c23. It turns out that this commit causes some regressions and is in fact unnecessary because the related commit "libcamera: v4l2_videodevice: Guard against releasing unallocated buffers" (a2bdff6d0b67475492ac7cf9318866b6d89a28fd) fixes the problem completely (if the buffers were never allocated, the video device avoids trying to free them even if the pipeline handler asks). The reason for the regressions is that in this new (broken) scheme we would never call clearBuffers() on all the streams if the internal buffers were never allocated (i.e. buffersAllocated_ is never set). This causes the stream's bufferMap_ list to get longer and longer if there are multiple back-to-back calls to configure, and dev_->importBuffers() will ultimately to fail. So either we need to think more carefully about how to stop the pipeline handler from freeing buffers that it doesn't own, or we just leave it as the other commit resolves the problem on its own. In the interim, simply reverting this commit certainly seems like the best solution. Fixes: 30d704732bad ("pipeline: raspberrypi: Do not unconditionally free buffers on close") Signed-off-by: David Plowman <david.plowman@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>
2022-11-14libcamera: v4l2_videodevice: Reduce zero sequence warning log levelKieran Bingham
The V4L2VideoDevice ensures that all sequence numbers for applications commence at zero from the libcamera perspective. This should be the behaviour expected by kernel drivers, but this is not always the case. This is handled internally to ensure consistency, and a warning is printed if the device does not start from zero. It was expected that the Warning would help highlight where kernel drivers should be fixed, but this has led to several false positive reports of failures where people have been concerned that this warning is a cause for unrelated issues. Lower the log level print to 'Info', to reduce the apparent severity of this warning. Info is likely more appropriate that Debug to continue to facilitate awareness of kernel drivers that could be improved, while not appearing to be a fault. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-11libcamera: camera_manager: Apply clang thread safety annotationHirokazu Honda
This annotates member functions and variables of CameraManager::Private by clang thread safety annotations. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-11-11libcamera: base: thread: Apply clang thread safety annotationHirokazu Honda
This annotates member variables of ThreadData by clang thread safety annotations. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-11-11libcamera: base: semaphore: Apply clang thread safety annotationHirokazu Honda
This annotates member functions and variables of Semaphore by clang thread safety annotations. Signed-off-by: Hirokazu Honda <hiroh@chromium.org> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-11-09pipeline: rkisp1: Pass info pointer to tryCompleteRequest()Laurent Pinchart
The tryCompleteRequest() function looks up the RkISP1FrameInfo that all but one of its callers already look up. Remove the double look up by passing the info pointer to tryCompleteRequest(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-11-09libcamera: pipeline_handler: Return unique_ptr from generateConfiguration()Laurent Pinchart
The PipelineHandler::generateConfiguration() function allocates a CameraConfiguration instance and returns it. The ownership of the instance is transferred to the caller. This is a perfect match for a std::unique_ptr<>, which the Camera::generateConfiguration() function already returns. Update PipelineHandler::generateConfiguration() to match it. This fixes a memory leak in one of the error return paths in the IPU3 pipeline handler. While at it, update the Camera::generateConfiguration() function documentation to drop the sentence that describes the ownership transfer, as that is implied by usage of std::unique_ptr<>. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-11-08libcamera: camera: Fix the isAcquired testDavid Plowman
All states count as "acquired" except for "CameraAvailable". Fixes: dfc6d711c9f7 ("libcamera: Allow concurrent use of cameras from same pipeline handler") Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-28pipeline: raspberrypi: Do not unconditionally free buffers on closeNaushir Patuck
When a camera is terminated, do not unconditionally free buffers in the RPiCameraData destructor. Otherwise, this causes harmless error log messages to be displayed if no buffer have previously been allocated. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-28libcamera: v4l2_videodevice: Guard against releasing unallocated buffersNaushir Patuck
releaseBuffers() unconditionally calls ioctl(REQBUFS, 0) to release device buffer allocations through the close() and class destructor functions. If another libcamera process is running concurrently with a different sensor, it would cause the ioctl to fail in the kernel because the buffer queue is owned owned by the other process. This in turn would cause libcamera to generate an error log message. Fix this by ensuring the releaseBuffers() only calls ioctl(REQBUFS, 0) if there have been buffers previously allocated by the device. This is done by testing the presense of the V4L2BufferCache in the object. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-28libcamera: make libdl optional when providedNicholas Roth
Currently, libdl is always required. Sometimes, the C++ runtime includes a dynamic loader, which is the case for Android. Additionally, Android 11 does not have libdl. This fix allows libcamera to build on Android. Signed-off-by: Nicholas Roth <nicholas@rothemail.net> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-20libcamera: base: log: Fix LogCategory creation issuesTomi Valkeinen
Each declaration of a LogCategory will create a new LogCategory, and will be stored in an unordered_set Logger::categories_. This means that when a plugin .so is unloaded and loaded, as happens when destructing and creating a CamereManager, we'll get duplicate categories. The Logger::registerCategory docs say "Log categories must have unique names. If a category with the same name already exists this function performs no operation.". The code does not comply with this. We solve the issue with two changes: Change the unordered_set to a vector for simplicity, as there's no need for an unordered_set. Instead of using the LogCategory constructor to create new categories in _LOG_CATEGORY() macro, use a factory method. The factory method will return either an existing LogCategory if one exists with the given name, or a newly created one. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-20libcamera: base: log: Fix use of freed nameTomi Valkeinen
LogCategory just stores the char * that was given to it in the constructor, i.e. it refers to memory "outside" LogCategory. If the LogCategory is defined in a .so that is unloaded, then it leads to the LogCategory pointing to freed memory, causing a crash. Fix this by taking a copy of the name by using a std::string instead of just storing the pointer. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18ipa: vimc: Add Flags to parametersPaul Elder
For the purpose of testing serializing/deserializing Flags in function parameters, add an enum class TestFlags and Flags<TestFlags> to some function parameters, both for input and output and Signals. While at it, update the ipa_interface_test. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18ipa: vimc: Add IPAOperationCode to init() parameter listPaul Elder
For the purpose of testing serializing/deserializing enums in function parameters, add IPAOperationCode to the parameter list of init(). Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18pipeline: ipa: raspberrypi: Add HBLANK control to DelayedControlsNaushir Patuck
Update CamHelper::getDelays() to return the sensor HBLANK delay. The HBLANK delay is set to the same value as VBLANK delay for all sensors in the Raspberry Pi IPA. Return the HBLANK gain delay from the IPA to the pipeline handler, and initialise DelayedControls to handle V4L2_CID_HBLANK with this delay value. As a drive-by, check that the V4L2_CID_HBLANK control is available when calling IPARPi::configure(). Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-18camera_sensor: Add minimum and maximum line length to IPACameraSensorInfoNaushir Patuck
Add fields for minimum and maximum line length (in units of pixels) to the IPACameraSensorInfo structure. This replaces the existing lineLength field. Update the ipu3, raspberrypi and rkisp1 IPAs to use IPACameraSensorInfo::minLineLength instead of IPACameraSensorInfo::lineLength, as logically we will always want to use the fastest sensor readout by default. Since the IPAs now use minLineLength for their calculations, set the starting value of the V4L2_CID_HBLANK control to its minimum in CameraSensor::init(). Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-15libcamera: v4l2_subdevice: Add JPEG_1X8 and BGR888_1X24 mbus formats to ↵Xavier Roumegue
formatInfoMap The warnings "Unknown subdev format 0x4001, defaulting to RGB encoding" and "Unknown subdev format 0x1013, defaulting to RGB encoding" are thrown while using simple pipeline handler with NXP ISI hardware. The JPEG_1X8 and BGR888_1X24 media bus formats, supported by the ISI driver, are missing in the V4L2SubdeviceFormatInfo structure storing the correspondence between a media bus format and a colour encoding. So populate the structure with the missing media bus formats. Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-13meson: Shared Object version handlingKieran Bingham
The libcamera project is not yet ready to declare ABI nor API stability, but it will benefit the community to be able to provide more regular release cycles to determine 'versioned' points of history. Ideally, these releases will be made at any ABI breakage, but can be made at arbitary time based points along the way. To support releases which may not be ABI stable, declare the soversion of both the libcamera and libcamera-base library to be dependant upon both the major minor and patch component of the project version. As part of this, introduce a new 'Versions' summary section to highlight the different version components that may become apparent within any given build. Bumping versions may leave dangling libcamera.so.* symlinks in build directories. This will confuse Doxygen which will print during its directory scanning phase a warning that the symlink can't be read. As we don't need Doxygen to follow symlinks, disable it with EXCLUDE_SYMLINKS. Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-10libcamera: v4l2_videodevice: Warn if bytesused == 0 when queuing output bufferLaurent Pinchart
V4L2 has deprecated queuing output buffers with bytesused set to 0. Warn if the caller attempts to do so. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10pipeline: rkisp1: Set bytesused before queuing parameters bufferLaurent Pinchart
The bytesused value for the parameters buffer is initialized to 0 and never set. The V4L2 API specification indicates that, for an output video device, the driver will set the bytesused value to the size of the plane in that case. The videobuf2 framework does so, but considers this as deprecated and prints a warning: [ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future, [ 54.388026] use the actual size instead. Fix it by setting bytesused to the correct value before queuing the parameters buffer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10pipeline: ipu3: Set bytesused before queuing parameters bufferLaurent Pinchart
The bytesused value for the parameters buffer is initialized to 0 and never set. The V4L2 API specification indicates that, for an output video device, the driver will set the bytesused value to the size of the plane in that case. The videobuf2 framework does so, but considers this as deprecated and prints a warning: [ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future, [ 54.388026] use the actual size instead. Fix it by setting bytesused to the correct value before queuing the parameters buffer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10libcamera: framebuffer: Move remaining private data to Private classLaurent Pinchart
Private members of the FrameBuffer class are split between FrameBuffer and FrameBuffer::Private. There was no real justification for this split, and keeping some members private in the FrameBuffer class causes multiple issues: - Future modifications of the FrameBuffer class without breaking the ABI may be more difficult. - Mutable access to members that should not be modified by applications require a friend statement, or going through the Private class. Move all remaining private members to the Private class to address the first issue, and add a Private::metadata() function to address the second problem. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-10-10libcamera: base: utils: Drop defoptLaurent Pinchart
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0, likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS support until mid-2024. As no workaround has been found to fix compilation on gcc 8.3.0 while still retaining the functionality of utils::defopt, remove it from the libcamera base library. This change could be reverted once support for gcc-8 will be dropped. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-10-07libcamera: controls: Construct Span with size for array controlsLaurent Pinchart
The ControlList::set() function overload used for array controls constructs a Span from an initializer list. It doesn't specify the Span size explicitly, which results in a dynamic extent Span being constructed. That causes a compilation failure for fixed-size array controls, as they are defined as Control<T> with T being a fixed-extent Span, and conversion from a dynamic-extent to fixed-extent Span when calling ControlValue::set() can't be implicit. Fix this by constructing the Span using the size of the control, which resolves to a fixed-extent and dynamic-extent Span for fixed-size and dynamic-size array controls respectively. The ControlList::set() function that takes an initializer list can then be used for fixed-size array controls. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07utils: gen-controls: Improve YAML notation for variable-size array controlsLaurent Pinchart
Array controls specify the array size through the YAML 'size' element, which stores a list of values, one per dimension. Variable-size arrays currently use an empty 'size' list, which prevents describing the number of dimensions of the array. Improve this by using the same notation for fixed-size and variable-size array controls. Dimensions that are not fixed are described as a string instead of an integer, such as [n], [n,3] or [w,h]. The strings have currently no special meaning, this may change in the future. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-10-07libcamera: pipeline_handler: Implement factories through class templatesLaurent Pinchart
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits from the PipelineHandlerFactory class, and implements a constructor and a createInstance() function. Replace the code generation through macro with the C++ equivalent, a class template, as done in libipa with the Algorithm and CameraSensorHelper factories. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Return unique_ptr from createInstanceLaurent Pinchart
Avoid naked pointer with memory allocation by returning a unique_ptr from PipelineHandlerFactory::createInstance(), in order to increase memory allocation safety. This allows iterating over factories in the CameraManager and unit tests using const pointers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-07libcamera: pipeline_handler: Make factory create() function constLaurent Pinchart
The PipelineHandlerFactory::create() function has no need to modify the factory instance. Make it const, as well as the createInstance() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-05test: threads: Fix link failure due to missing dependencyLaurent Pinchart
Commit 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination") added calls to functions provided by the pthread library in the threads test, but didn't add the corresponding dependency. This caused a link breakage on some platforms: /usr/bin/ld: test/threads.p/threads.cpp.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.4' /usr/bin/ld: /lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Fix it by adding the missing dependency. Fixes: 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination") Reported-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Acked-by: Jacopo Mondi <jacopo@jmondi.org>
2022-10-05pipeline: raspberrypi: Update naming convention for tuning filesNaushir Patuck
Append "_mono" to the sensor name when generating the tuning filename for monochrome sensor variants. So the new naming convention is as follows: <sensor_name>.json - Standard colour sensor variant <sensor_name>_mono.json - Monochrome sensor variant Rename the existing imx296.json file to imx296_mono.json as this tuning file is based on the monochrome variant of the IMX296. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> 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>
2022-10-05libcamera: bayer_format: Add unpacked mono 12-bit format to the conversion tableNaushir Patuck
Add BayerFormat conversions for formats::R12 (12-bit unpacked) format. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.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>
2022-10-04pipeline: raspberrypi: Detect monochrome "R" formats as being rawDavid Plowman
The "R" pixel formats (R8, R10, R10_CSI2P etc.) record the associated colour space as being YUV rather than RAW, meaning that the code was not detecting them as being raw formats. In the case of Raspberry Pi, we deal only with raw formats, so the revised test must work correctly for both these and the standard Bayer formats. Signed-off-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-10-04libcamera: v4l2_device: List controls when setting file descriptorLaurent Pinchart
The base V4L2Device class is bound to a video device node by either open(), which opens the device node and creates a new file descriptor, or setFd(), which takes an already open file descriptor. The former populates the V4L2Device instance controls, while the latter doesn't. This prevents using controls on V4L2 M2M devices. Fix it by populating controls in setFd(), which is called by open(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
2022-09-29libcamera: v4l2_device: Log control id instead of errorIdxUmang Jain
v4l2_ext_controls.errorIdx (in the case of single failing control for VIDIOC_*_EXT_CTRLS calls) represents the index of that control. Since it is a single control, we can print the control id rather than its index. This improves logging as the id can be easily co-related with the controls while reading the log. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-23pipeline: raspberrypi: Improve Unicam timeout handlingNaushir Patuck
Currently, if a Unicam timeout is signalled, the pipeline handler only raises an error message. Update the error handling to put the pipeline handler in an internal error state, disable all device streams, and return all outstanding requests as cancelled. Any subsequent requests that come into the pipeline handler will also be returned as cancelled. Any further error handling (e.g. a reset with camera stop()/start()) is up to the application to perform as it requires. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-09-23pipeline: raspberrypi: Add an error stateNaushir Patuck
Add an error state used internally in the Raspberry Pi pipeline handler. Currently this state is never set, but will be in a subsequent commit when a device timeout has been signalled. Add a isRunning() helper to identify if the state machine is in a stopped/error state. Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-09-15libcamera: ipa_manager: Fix build without opensslMatthias Fend
Since commit bedef55d9500 ("libcamera: pub_key: Gracefully handle failures to load public key") the build will fail if openssl is not found on the host system. Use the existing HAVE_IPA_PUBKEY define to avoid accessing pubKey_ which does not exist when building without openssl. Signed-off-by: Matthias Fend <matthias.fend@emfend.at> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-12libcamera: control_serializer: store/load all ControlValue typesChristian Rauch
The min/max/def ControlValue of a ControlInfo can take arbitrary types that are different from each other and different from the ControlId type. The serialiser serialises these ControlValue separately by their type but does not store the type. The deserialiser assumes that ControlValue types match the ControlId type. If this is not the case, deserialisation will try to deserialise values of the wrong type. Fix this by serialising each of the min/max/def ControlValue's ControlType and storing it just before the serialised ControlValue. Fixes: https://bugs.libcamera.org/show_bug.cgi?id=137 Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> Tested-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-08libcamera: v4l2_subdevice: Silence warning for unknown metadata formatsLaurent Pinchart
Commit e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on pixel format") has introduced a warning when trying to convert a color space from V4L2 to libcamera if the media bus code is unknown. This was meant to catch unknown image formats, but turned out to be also triggered for metadata formats. Color spaces are not applicable to metadata formats, there should thus be no warning. Fix it by skipping the color space translation and returning std::nullopt directly if the kernel reports V4L2_COLORSPACE_DEFAULT. This doesn't introduce any change in behaviour other than getting rid of the warning, as the V4L2Device::toColorSpace() function returns std::nullopt already in that case. Fixes: e297673e7686 ("libcamera: v4l2_device: Adjust colorspace based on pixel format") Reported-by: Naushir Patuck <naush@raspberrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
2022-09-07pipeline: uvcvideo: Fail match() if the camera has no supported formatLaurent Pinchart
A UVC device could expose only formats that are not supported by libcamera. The pipeline handler doesn't currently consider this as an error, and happily creates a camera. The camera won't be usable, and worse, generateConfiguration() and validate() will crash as those functions assume that at least one format is supported. Fix this by failing match() if none of the formats exposed by the camera are supported. Log an error message in that case to notify the user. Bug: https://bugs.libcamera.org/show_bug.cgi?id=145 Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
2022-09-07pipeline: uvcvideo: Cache supported formats in UVCCameraDataLaurent Pinchart
Populate and cache the list of supported formats in UVCCameraData::init(), to avoid repeating the operation every time generateConfiguration() is called. Combine this with the search for the largest size advertised by the camera to avoid iterating over the formats twice in init(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
2022-09-07pipeline: uvcvideo: Move camera ID generation to UVCCameraData classLaurent Pinchart
Move the camera ID generation to UVCCameraData, and cache the ID in that class. This will be useful to access the ID in multiple locations, such as when printing error messages. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: Christian Rauch <Rauch.Christian@gmx.de>
2022-09-05libcamera: v4l2_device: Report device node on failureKieran Bingham
When the V4L2Device fails to open, it is not clear what device caused the failure. The Entity name is presented, but not the device node. Provide it. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-05CameraSensor: Don't fail to add camera with faulty lensKieran Bingham
If the CameraSensor fails to identify the VCM specified, it could still be possible to continue to operate the sensor. Autofocus support will be disabled, but this would be no different to operating a camera with a fixed focus. While of course the fixed focus position may not be suitable, it would provide a better user experience to be able to continue to operate the camera, while still reporting that the lens is disabled. Bug: https://bugs.libcamera.org/show_bug.cgi?id=146 Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-05libcamera: yaml_parser: Report filename on failuresKieran Bingham
It can be helpful to know 'which' file failed to parse if there is a failure. Report it to the user in the error message. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-05libcamera: Override "libcamera" dependency in mesonBarnabás Pőcze
Overriding the dependency enables libcamera to be used as a meson subproject more easily. Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>