summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2022-07-18qcam: format_converter: Support X RGB variantsKieran Bingham
Support the X variants of the RGB pixel formats along side the equivalent Alpha component based versions. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-07-18qcam: viewfinder_qt: Fix include ordersKieran Bingham
Update the header orders to match the code style as decreed by clang-format. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-07-18qcam: main_window: Fix include orderingKieran Bingham
Fix the sort order of the Qt headers to match the expected sort order from clang-format. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-07-18libcamera: raspberry: Fix format validationJacopo Mondi
If the pixel format gets adjusted to the default NV12 format during validation, it gets currently ignored and the user-supplied format is used nonetheless. Fix it by using the adjusted pixel format. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-07-15cam: sdl: Use uint32_t in place of SDL_PixelFormatEnumJacopo Mondi
The SDL_PixelFormatEnum type has been introduced in libsdl by 1a4c0d4e17e6 ("Fixed bug 4377 - SDL_PIXELFORMAT enum is anonymous, which prevents its use in a templated function") which is only available after release 2.0.10 of the library. Debian 10 ships libsdl at version 2.0.9 and building cam with sdl support there fails with error: ./src/cam/sdl_texture.h:27:8: error: ‘SDL_PixelFormatEnum’ does not name a type; did you mean ‘SDL_PixelFormat’? Fix that by using the base type uint32_t in place of SDL_PixelFormatEnum. Reported-by: https://buildbot.libcamera.org/#/builders/6/builds/355 Fixes: 11554a259f4e ("cam: sdl_sink: Add SDL sink with initial YUYV support") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com>
2022-07-14pipeline: raspberrypi: Fix incorrect advertising of ScalerCropNaushir Patuck
The controls::ScalerCrop in the ControlInfoMap was advertised based on the ISP output Rectangle. This is incorrect, it needs to be set based on the sensor analogue crop Rectangle. Fix this. Additionally, do not use emplace to be consistent with the other controls set in the ControlInfoMap. Fixes: 9dacde0d651d (pipeline: raspberrypi: Advertise ScalerCrop from the pipeline handler) Reported-by: David Plowman <david.plowman@raspberrypi.com> Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Tested-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-07-14pipeline: rkisp1: Support media graph with separate CSI RXPaul Elder
The rkisp1 hardware supports both a CSI-2 input and a parallel input, where the sensor is connected directly to the ISP. On RK3399, the CSI-2 receiver is internal, but on the i.MX8MP, the CSI-2 receiver is a separate IP core, connected to the parallel input of the ISP, and gets exposed to userspace as a V4L2 subdev. To prepare for this, handle an optional CSI-2 receiver subdev in the pipeline. Signed-off-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org>
2022-07-13libcamera: base: Suppress clang-11 compile error on ARM32Naushir Patuck
Compiling backtrace.cpp for ARM32 produces the following error with the clang-11 (and later) compiler: -------------------- ../src/libcamera/base/backtrace.cpp:195:12: error: use of SP or PC in the list is deprecated [-Werror,-Winline-asm] int ret = unw_getcontext(&uc); ^ /usr/include/arm-linux-gnueabihf/libunwind-common.h:114:29: note: expanded from macro 'unw_getcontext' ^ /usr/include/arm-linux-gnueabihf/libunwind-arm.h:270:5: note: expanded from macro 'unw_tdep_getcontext' "stmia %[base], {r0-r15}" \ ^ <inline asm>:1:2: note: instantiated into assembly here stmia r0, {r0-r15} -------------------- Suppress this compilation error with a clang-specific pragma around the offending statements. Further information about this error can be found at https://github.com/dotnet/runtime/issues/38652 Bug: https://bugs.libcamera.org/show_bug.cgi?id=136 Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@rasbperrypi.com> Tested-by: Naushir Patuck <naush@rasbperrypi.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-07-05libcamera: camera: Reset request sequence number on stop/startUmang Jain
We now have V4L2VideoDevice ensuring that sensor sequence numbers start from zero [1], and we desire that these should match the Request sequence number as well. [1] 1c9dc0fd89cf ("libcamera: v4l2_videodevice: Identify non-zero stream starts") Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-07-05delayed_controls: Remove reduandant firstSequence_Kieran Bingham
The DelayedControls implementation tracked the sequence numbers to determine the offset if a device did not commence with a sequence number of 0. This guarantee is now handled by the V4L2VideoDevice. Remove the firstSequence_ offset and the corresponding running_ flag which was used to track setting firstSequence_ from the DelayedControls. Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com> 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-07-04gstreamer: Fix race conditions in task pause/resumeLaurent Pinchart
The task run function races with two other threads that want to resume the task: the requestCompleted() handler and the buffer-notify signal handler. If the former queues completed requests or the latter queues back buffers to the pool, and then resume the task, after the task run handler checks the queues but before it attemps to pause the task, then the task may be paused without noticing that more work is available. The most immediate way to fix this is to take the stream_lock in the requestCompleted() and buffer-notify signal handlers, or cover the whole task run handler with the GstLibcameraSrcState lock. This could cause long delays in the requestCompleted() handler, so that's not a good option. Instead, pause the task unconditionally at the beginning of its run function, and track while processing buffers and requests if the task needs to be resumed. It may also get resumed externally by the buffer-notify signal handler or the request completion handler, which are guaranteed not to race due to the lock taken by the gst_task_pause() and gst_task_resume() functions. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
2022-07-04gstreamer: Split completed request processing to a separate functionLaurent Pinchart
Simplify the task run function futher by moving the processing of completed requests to a separate function. No functional change intended, only increased readability. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Split request creation to a separate functionLaurent Pinchart
In order to prepare for creation and queuing of multiple requests, move the request creation and queueing code to a separate function. No functional change intended. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Fix pads lockingLaurent Pinchart
The srcpads_ vector is protected by two different locks, the GstObject lock of the libcamerasrc element, and the stream_lock that covers the run function of the thread. This isn't correct. Use the stream_lock consistently to protect the pads. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Use dedicated lock for request queuesLaurent Pinchart
Add a new lock to the GstLibcameraSrcState class to protect the queued and completed requests queues. This replaces the GstObject lock, and minimizes the lock contention between the request completion handler and the task run handler as the former must run as fast as possible. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Combine the two pad loops in the task run handlerLaurent Pinchart
This simplifies the code, and allows removing the internal queue in the GstLibcameraPad object. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Handle completed requests in the libcamerasrc taskLaurent Pinchart
Move the request wrap to a completed queue in the request completion handler to move more of the request completion processing to the libcamerasrc task. This lowers the amount of time spent in the completion handler, and prepares for reworking the usage of locks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Rename queued requests queue to queuedRequests_Laurent Pinchart
To prepare for the addition of a completed requests queue, rename the existing queued requests queue from requests_ to queuedRequests_. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Move timestamp calculation out of pad loopLaurent Pinchart
The buffer pts and the pad latency are computed from the framebuffer timestamp, separately for each pad. Use the sensor timestamp provided through the request metadata instead, to compute the values once outside of the pads loop. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Pass Stream to RequestWrap::addBuffer()Laurent Pinchart
For symmetry with RequestWrap::removeBuffer(), pass the Stream pointer to addBuffer(). This handles streams at the GstPad level instead of the GstBuffer level, which allows making the GstLibcameraPool API a bit cleaner by removing the gst_libcamera_buffer_get_stream() helper function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Move variable to loop scopeLaurent Pinchart
The GstBuffer variable in GstLibcameraSrcState::requestCompleted() is only used within the loop scope. Make it a local loop variable. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-04gstreamer: Use gst_task_resume() when availableLaurent Pinchart
The gst_libcamera_resume_task() helper is an implementation of the gst_task_resume() function that predates its addition to GStreamer. Use gst_task_resume() when available, and rename gst_libcamera_resume_task() to gst_task_resume() to support older GStreamer versions. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Vedant Paranjape <vedantparanjape160201@gmail.com>
2022-06-29ipa: rkisp1: Add support of Black Level Correction tuningFlorian Sylvestre
Get the Black Level Correction algorithm parameters from YAML tuning data. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-29ipa: rkisp1: Add OV5640 tuning fileFlorian Sylvestre
Add the OV5640 tuning file containing default values for 'black level correction' algorithm. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-29ipa: rkisp1: Add IMX219 tuning fileLaurent Pinchart
Add a skeleton for the IMX219 tuning file, with data for the BLC algorithm. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29ipa: rkisp1: Add YAML tuning file supportFlorian Sylvestre
Retrieve root node in YAML tuning file and provide to each algorithm this YamlObject to allow them to grab their default parameters by calling init() function. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-29ipa: rkisp1: Register algorithmsLaurent Pinchart
To prepare for dynamic instantiation of algorithms from the tuning file, register the algorithms with the Module class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29pipeline: rkisp1: Support IPA tuning fileFlorian Sylvestre
Pass the path name of the YAML IPA tuning file to the IPA module. The file name is derived from the sensor name ("${sensor_name}.yaml"), with a fallback to "uncalibrated.yaml". The tuning file name can be manually overridden with the LIBCAMERA_RKISP1_TUNING_FILE environment variable. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-29ipa: libipa: module: Make the Module class LoggableLaurent Pinchart
To help attribute messages logged by the Module class to a particular IPA module, make the class loggable. The logPrefix() function must be implemented by the IPA module-specific derived class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29ipa: libipa: module: Add support for instantiation from YAMLLaurent Pinchart
Add a Module::createAlgorithms() function to instantiate algorithms from a YamlObject. The instantiated algorithms are stored in a private member variable list, exposed through the Module::algorithms() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29ipa: libipa: algorithm: Add init() function to the Algorithm classFlorian Sylvestre
Add the init() function that will be called during algorithm initialization to provide each algorithm the list of algorithms tuning data. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-29ipa: libipa: algorithm: Add an algorithm registration mechanismLaurent Pinchart
In order to allow dynamic instantiation of algorithms based on tuning data files, add a mechanism to register algorithms with the IPA module. The implementation relies on an AlgorithmFactory class and a registration macro, similar to the pipeline handler registration mechanism. The main difference is that the algorithm registration and instantiation are implemented in the Module class instead of the AlgorithmFactory class, making the factory an internal implementation detail. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29ipa: libipa: Move ipa namespace documentation to module.cppLaurent Pinchart
The libipa.cpp file exists for the sole purpose of documentating the ipa namespace. As we now have a top-level module.cpp file in libipa, move the documentation there, and drop libipa.cpp. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29ipa: libipa: Introduce a Module class templateLaurent Pinchart
libipa defines an abstract Algorithm class template that is specialized by IPA modules. IPA modules then instantiate and manage algorithms internally, without help from libipa. With ongoing work on tuning data support for the RkISP1, and future similar work for the IPU3, more code duplication for algorithms management is expected. To address this and share code between multiple IPA modules, introduce a new Module class template that will define and manage top-level concepts for the IPA module. The Module class template needs to be specialized with the same types as the Algorithm class. To avoid manual specialization of both classes, store the types in the Module class, and replace the template arguments of the Algorithm class with a single Module argument from which the other types are retrieved. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-06-29pipeline: raspberrypi: Advertise ScalerCrop from the pipeline handlerNaushir Patuck
The ScalerCrop control is handled directly by the pipeline handler. Remove the control from the IPA's static ControlInfoMap, and let the pipeline handler add it to the ControlInfoMap advertised to the application, ensuring the limits are set appropriately based on the current sensor mode. Signed-off-by: Naushir Patuck <naush@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-06-29pipeline: ipa: raspberrypi: Correctly report available control limitsNaushir Patuck
The ipa currently advertises a static ControlInfoMap to specify the available controls and their limits. Fix this limitation by having the IPA populate a new ControlInfoMap with updated limits for ExposureTime, AnalogueGain, and FrameDurationLimits controls based on the current sensor mode. This new ControlInfoMap is then returned back to the pipeline handler and available to the application after a successful Camera::configure() call. Before the first call to Camera::configure(), this ControlInfoMap provides some reasonable default limits for ExposureTime, AnalogueGain, and FrameDurationLimits. However, applications must not rely on these values, but obtain the correct limits after the call to Camera::configure(). 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-06-29pipeline: ipa: raspberrypi: Move ControlInfoMap to the IPANaushir Patuck
Currently the pipeline handler advertises controls handled by the IPA from a static ControlInfoMap defined in the raspberrypi.h header. This change removes this header file, and instead the IPA returns the ControlInfoMap to the pipeline handler from the ipa::init() function. This is done to allow the IPA to adjust the limits of the controls based on the sensor mode in a subsequent change. Bug: https://bugs.libcamera.org/show_bug.cgi?id=83 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-06-29ipa: raspberrypi: Use std::optional in DeviceStatusNaushir Patuck
Switch the aperture, lens_position, and flash_intensity fields in the DeviceStatus structure to use std::optional instead of using invalid default values. 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-06-29ipa: raspberrypi: imx477: Get sensor temperature from embedded dataNaushir Patuck
Fetch the sensor temperature value from the embedded data buffer and add it to the DeviceStatus structure in CamHelperImx477::PopulateMetadata(). 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-06-29ipa: raspberrypi: Add sensor temperature to DeviceStatusNaushir Patuck
Add an optional sensor_temperature field to the DeviceStatus structure. If a temperature measurement is available for a frame, the value is returned out through the SensorTemperature control in the Request metadata. Additionally, provide the sensor temperature value from the std::ostream &operator<< overload. 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-06-29libcamera: controls: Add SensorTemperature controlNaushir Patuck
Add a SensorTemperature control to return the temperature of the camera sensor in Celsius. This control will only be present in the Request metadata if a thermal sensor is available to the camera sensor. 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-06-27libcamera: v4l2_videodevice: Identify non-zero stream startsKieran Bingham
V4L2 Video devices should always start streaming from index zero. Identify and report a warning if they don't, and correct for any offset. 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-06-20cam: kms_sink: Remove limitation that camera and display must matchEric Curtin
There is a limitation that requires input and output to be pixel for pixel identical in terms of height and width. Remove this limitation to enable more hardware that doesn't match. Just start drawing from top left 0, 0 corner. Signed-off-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Eric Curtin <ecurtin@redhat.com>
2022-06-20libcamera: yaml_parser: Add get() specializations for 16-bit integersLaurent Pinchart
Extend the YamlObject::get() function template to support 16-bit integers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
2022-06-20libcamera: yaml_parser: Fix range checks for 32-bit integersLaurent Pinchart
The strtol() and strtoul() functions return long integers, which may be larger than 32-bit integers. Add manual range checks. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
2022-06-20libcamera: yaml_parser: Remove memberNames() functionLaurent Pinchart
Now that YamlObject supports iteration, the memberNames() function isn't useful anymore as it can be implemented using utils::map_keys() if really needed. Drop it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
2022-06-20android: Use the YamlObject iterator APILaurent Pinchart
Replace usage of YamlObject::memberNames() with the more efficient iterator API. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
2022-06-20libcamera: yaml_parser: Add iterator APILaurent Pinchart
Allow using range-based for loops over YamlObject instances by implementing iterators. New YamlObject::DictAdapter and YamlObject::ListAdapter adapter classes are introduced to provide different iterators depending on the object type. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Han-Lin Chen <hanlinchen@chromium.org>
2022-06-19cam: drm: Support /dev/dri cards other than 0Eric Curtin
Existing code is hardcoded to card0. Since recent fedora upgrades, we have noticed on more than one machine that card1 is present as the lowest numbered device, could theoretically be higher. This technique tries every file starting with card and continue only when we have successfully opened one. These devices with card1 as the lowest device were simply failing when they do not see a /dev/dri/card0 file present. Reported-by: Ian Mullins <imullins@redhat.com> Tested-by: Ian Mullins <imullins@redhat.com> Signed-off-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-06-18ipa: ipu3: awb: Correct the gains calculationJean-Michel Hautbois
The factor used right now in the IPU3 is 8192, as a multiplier of the estimated gain. This is wrong, as the isp is adding 1.0 to the gain applied, ie Pout = { Pin * (1 + Gx) }. Fix it, and to ease the reading, introduce a small helper function. Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>