summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2022-10-07libcamera: pipeline_handler: Make registerType() privateLaurent Pinchart
The PipelineHandlerFactory::registerType() function is called by the PipelineHandlerFactory class only. Make it private. 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-07libcamera: camera_manager: Rename parameter to get()Laurent Pinchart
The CameraManager::get() function takes a string containing the ID of the requested camera. This is correctly documented and implemented in the .cpp file, but the header file names the parameter 'name' instead of 'id'. Fix it. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-09-30android: Add missing SPDX headers to Android headersLaurent Pinchart
Most headers imported from Android have an SPDX tag (added manually in commit 190bebef0840), but four headers that have been imported more recently are missing license identifiers. Fix them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-09-12libcamera: controls: initialise control info to ControlTypeNone by defaultChristian Rauch
The default ControlInfo constructor allows partially initialising the min/max/def values. Uninitialised values are assigned to 0 by default. This implicit initialisation makes it impossible to distinguish between an uninitialised and an explicitly 0-initialised ControlValue. Default construct the ControlValue in the ControlInfo default contructor to explicitly represent uninitialised values by the ControlTypeNone type. Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> 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-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-01libcamera: color_space: Move color space adjustment to ColorSpace classUmang Jain
The CameraConfiguration::validateColorSpaces() function performs color space validation on a camera configuration, by validating the color space of each stream individually, and optionally ensuring that all streams share the same color space. The individual validation is very basic, limited to ensuring that raw formats use a raw color space. Color spaces are more constrained than that: - The Y'CbCr encoding and quantization range for RGB formats must be YcbcrEncoding::None and Range::Full respectively. - The Y'CbCr encoding for YUV formats must not be YcbcrEncoding::None. Instead of open-coding these constraints in the validateColorSpaces() function, create a new ColorSpace::adjust() function to centralize color space validation and adjustment, and use it in validateColorSpaces(). Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-01libcamera: v4l2_videodevice: Improve toColorSpace() readabilityUmang Jain
Wrap V4L2Device::toColorspace() inside a private static member function in V4L2VideoDevice class. It improves readability in setting the colorspace for V4L2DeviceFormat. No functional changes intended. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-09-01libcamera: v4l2_device: Adjust colorspace based on pixel formatUmang Jain
V4L2 has no "none" YCbCr encoding, and thus reports an encoding for all formats, including RGB and raw formats. This causes the libcamera ColorSpace to report incorrect encodings for non-YUV formats. Fix it by overriding the encoding reported by the kernel to YCbCrEncoding::None for non-YUV pixel formats and media bus formats. Similarly, override the quantization range of non-YUV formats to full range, as limited range isn't used for RGB and raw formats. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-31libcamera: request: Rename Private::reuse() to Private::reset()Umang Jain
The Request::Private::reuse() is different from Request::reuse(). It resets the members of Request::Private to default values hence, rename it to a more appropriate Request::Private::reset(). Update the usage and documentation accordingly. Signed-off-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-08-31libcamera: base: signal: Disable connect() for functor if args mismatchLaurent Pinchart
If a pointer-to-member is passed to the Signal::connect() function with arguments that don't match the Signal type, the pointer-to-member version of connect() will not match during template argument resolution, but the functor version will. This results in a compilation error in the BoundMethodFunctor class, due to the pointer-to-member not being a functor and thus not being callable directly. The error messages are quite cryptic. With the following error applied, diff --git a/test/signal.cpp b/test/signal.cpp index 5c6b304dac0b..6dd11ac45313 100644 --- a/test/signal.cpp +++ b/test/signal.cpp @@ -107,6 +107,7 @@ protected: /* Test signal emission and reception. */ called_ = false; signalVoid_.connect(this, &SignalTest::slotVoid); + signalVoid_.connect(this, &SignalTest::slotInteger1); signalVoid_.emit(); if (!called_) { gcc outputs ../../include/libcamera/base/bound_method.h: In instantiation of ‘R libcamera::BoundMethodFunctor<T, R, Func, Args>::activate(Args ..., bool) [with T = SignalTest; R = void; Func = void (SignalTest::*)(int); Args = {}]’: ../../include/libcamera/base/bound_method.h:143:4: required from here ../../include/libcamera/base/bound_method.h:146:37: error: must use ‘.*’ or ‘->*’ to call pointer-to-member function in ‘((libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>*)this)->libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::func_ (...)’, e.g. ‘(... ->* ((libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTes t::*)(int)>*)this)->libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::func_) (...)’ 146 | return func_(args...); | ~~~~~^~~~~~~~~ and clang isn't much better: ../../include/libcamera/base/bound_method.h:146:11: error: called object type 'void (SignalTest::*)(int)' is not a function or function pointer return func_(args...); ^~~~~ ../../include/libcamera/base/bound_method.h:137:2: note: in instantiation of member function 'libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::activate' requested here BoundMethodFunctor(T *obj, Object *object, Func func, ^ ../../include/libcamera/base/signal.h:80:27: note: in instantiation of member function 'libcamera::BoundMethodFunctor<SignalTest, void, void (SignalTest::*)(int)>::BoundMethodFunctor' requested here SignalBase::connect(new BoundMethodFunctor<T, void, Func, Args...>(obj, nullptr, func)); ^ ../../test/signal.cpp:110:15: note: in instantiation of function template specialization 'libcamera::Signal<>::connect<SignalTest, void (SignalTest::*)(int), nullptr>' requested here signalVoid_.connect(this, &SignalTest::slotInteger1); ^ Improve error reporting by disabling the functor version of connect() when the Func argument isn't invocable with the Signal arguments. gcc will then complain with ../../test/signal.cpp:110:36: error: no matching function for call to ‘libcamera::Signal<>::connect(SignalTest*, void (SignalTest::*)(int))’ 110 | signalVoid_.connect(this, &SignalTest::slotInteger1); | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and clang with ../../test/signal.cpp:110:15: error: no matching member function for call to 'connect' signalVoid_.connect(this, &SignalTest::slotInteger1); ~~~~~~~~~~~~^~~~~~~ which are more readable. This change requires usage of std::is_invocable<>, which is only available starting in C++17. This is fine for usage of the Signal class within libcamera, as the project is compiled with C++17, but we try to keep the public API compatible C++14. Condition the additional checks based on the C++ version. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-08-26libcamera: color_space: Add fromString() functionLaurent Pinchart
Add a ColorSpace:fromString() function to parse a string into a color space. The string can either contain the name of a well-known color space, or four color space components separate by a '/' character. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-26utils: Satisfy LegacyInputIterator with StringSplitter::iteratorLaurent Pinchart
The StringSplitter::iterator is used with the utils::split() function to iterate over components of a split string. Add the necessary member types expected by std::iterator_trait in order to satisfy the LegacyInputIterator requirement and make the iterator usable in constructors for various containers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-25libcamera: color_space: Rename Jpeg to SyccLaurent Pinchart
The JPEG color space is badly name, as the JPEG specification (ITU-T T.81) doesn't define any particular color space: The interchange format does not specify a complete coded image representation. Application-dependent information, e.g. colour space, is outside the scope of this Specification. The JFIF specification (ITU-T T.871) is clearer as it requires ITU-R BT.601 YCbCr encoding and a full quantization range: The interpretations of Y, CB, and CR are derived from the E'Y, E'Cb, and E'Cr signals defined in the 625-line specification of Rec. ITU-R BT.601, but these signals are normalized so as to permit the usage of the full range of 256 levels of the 8-bit binary encoding of the Y component. It however doesn't specify color primaries or a transfer function explicitly. It only mentions the latter when describing the conversion from YCbCr to RGB: The inverse relationship for computing full scale 8-bit per colour channel gamma pre-corrected RGB values (following Rec. ITU-R BT.601 gamma pre-correction and colour primary specifications) from YCbCr colours (with 256 levels per component) can be computed as follows: [...] Given that ITU-R BT.601-5 (1995) didn't specify color primaries or a transfer function, and that the later ITU-R BT.601-7 (2011) version specifies color primaries for the 625-line variant that do not match sRGB, the JPEG color space in libcamera is badly named. This is confirmed by ITU-T T.871: As this Recommendation | International Standard is based on the prior informally-circulated JFIF version 1.02 specification that was produced in 1992, which referenced Rec. ITU-R BT.601 (formerly CCIR 601), it references that specification for definition of the E'Y, E'Cb, and E'Cr signals that correspond to the YCBCR values specified herein. However, since the development of the prior JFIF version 1.02 specification, additional industry specifications have been developed, Rec. ITU-R BT.601 has been updated, and common industry practice has emerged which often follows the sYCC specification in IEC 61966-2-1/Amd.1. The difference between the use of the colour interpretation specification in this Recommendation | International Standard and that of the sYCC specification may be considered negligible in practice. Rename the color space to sYCC, as its definition matches the sYCC standard, and indicate that it is typically used to encode JPEG images. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-21libcamera: yaml_parser: Enable YamlObject::get() for int8_t and uint8_tLaurent Pinchart
The YamlObject::get() function template is implemented for 16-bit and 32-bit integers. Add an 8-bit specialization that will be used in the rkisp1 IPA module, and extend the unit tests accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-16libcamera: base: Make message.h and mutex.h privateLaurent Pinchart
The message.h and mutex.h headers are not used in the libcamera public API. Make them private to avoid there usage in applications, and to prevent having to maintain them with a stable ABI. As mutex.h is used by libcamerasrc, the GStreamer element must switch from the libcamera_public to the libcamera_private dependency. 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>
2022-08-10libcamera: Allow concurrent use of cameras from same pipeline handlerLaurent Pinchart
libcamera implements a pipeline handler locking mechanism based on advisory locks on media devices, to prevent concurrent access to cameras from the same pipeline handler from different processes (this only works between multiple libcamera instances, as other processes won't use advisory locks on media devices). A side effect of the implementation prevents multiple cameras created by the same pipeline handler from being used concurrently. Fix this by turning the PipelineHandler lock() and unlock() functions into acquire() and release(), with a use count to replace the boolean lock flag. The Camera class is updated accordingly. As a consequence of this change, the IPU3 pipeline handler will fail to operate properly when the cameras it exposes are operated concurrently. The android.hardware.camera2.cts.MultiViewTest#testDualCameraPreview test fails as a result. This should be fixed in the IPU3 pipeline handler to implement mutual exclusion between cameras. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by: David Plowman <david.plowman@raspberrypi.com>
2022-08-10libcamera: formats: Fix warning for unknown V4L2 pixfmtJacopo Mondi
Commit f25ad4a2b16b ("libcamera: formats: Reimplement V4L2 PixelFormatInfo::info()") changed the PixelFormatInfo::info(const V4L2PixelFormat &format) function overload to: return info(format.toPixelFormat()); As part of the series that contains such commit, the PixelFormatInfo for the pixel format applied to a video device is now retrieved at V4L2VideoDevice::open() time. Some video devices register formats not available to applications, for example metadata formats or, in the case of ISP devices, formats to describe the ISP statistics and parameters. This causes the format.toPixelFormat() call to output a WARN message, which spams the log and unnecessarily alerts the users. Augment V4L2PixelFormat::toPixelFormat() with an optional argument to suppress warnings in the case a V4L2 pixel format is not known, to restore the behaviour preceding commit f25ad4a2b16b and returns an invalid PixelFormatInfo without outputting any unnecessary warning message. Fixes: f25ad4a2b16b ("libcamera: formats: Reimplement V4L2 PixelFormatInfo::info()") Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-08-09libcamera: pub_key: Support openssl as an alternative to gnutlsLaurent Pinchart
Support verify IPA signatures with openssl as an alternative to gnutls, to offer more flexibility in the selection of dependencies. Use gnutls by default, for no specific reason as both are equally well supported. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Eric Curtin <ecurtin@redhat.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-08-09libcamera: controls: Generate and use fixed-sized Span typesChristian Rauch
Define Span types explicitly as either variable- or fixed-sized. This introduces a new convention for defining Span dimensions in the property and control value definitions and generates Span types as variable-sized Span<T> or as fixed-sized Span<T,N>. Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-08-04pipeline: rkisp1: Move ControlInfoMap to IPA moduleLaurent Pinchart
Currently the pipeline handler advertises controls handled by the IPA from a ControlInfoMap it manually constructs. This is wrong, as the IPA module is the component that knows what controls it supports. Fix this by moving the ControlInfoMap construction to the IPA module, and pass it to the pipeline handler as a return value from the IPA init() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Florian Sylvestre <fsylvestre@baylibre.com>
2022-08-03libcamera: v4l2_subdevice: Add support for the V4L2 subdev routing APIJacopo Mondi
Extend the V4L2Subdevice class to support getting and setting routing tables. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-03libcamera: v4l2_subdevice: Collect subdev capabilitiesJacopo Mondi
Collect subdev capabilities at open() time. Model the V4L2SubdevCapabilties as V4L2Capability from the video device class. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
2022-08-03libcamera: v4l2_subdevice: Change V4L2Subdevice::WhenceJacopo Mondi
The V4L2Subdevice::Whence enumerations defines two values that should correspond to the V4L2_SUBDEV_FORMAT_ACTIVE and V4L2_SUBDEV_FORMAT_TRY definitions. The V4L2 symbols are defined as: V4L2_SUBDEV_FORMAT_TRY = 0, V4L2_SUBDEV_FORMAT_ACTIVE = 1, While the libcamera defined enumeration is: enum Whence { ActiveFormat, TryFormat, } As V4L2Subdevice::Whence values are used to populate data types defined in v4l2-subdev.h used as arguments to VIDIOC_SUBDEV_* ioctls, the V4L2Subdevice class is required to adjust their value as: subdevFmt.which = whence == ActiveFormat ? V4L2_SUBDEV_FORMAT_ACTIVE : V4L2_SUBDEV_FORMAT_TRY; Drop the adjustment by defining : Whence::TryFormat = V4L2_SUBDEV_FORMAT_TRY; Whence::ActiveFormat = V4L2_SUBDEV_FORMAT_ACTIVE; Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-08-03include: linux: Add V4L2 subdev internal routing APILaurent Pinchart
The V4L2 subdev internal routing API is under development. Add it manually to the v4l2-subdev.h kernel header for now. The code corresponds to the "[PATCH v11 00/36] v4l: routing and streams support" series as posted to the linux-media mailing list. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-03include: linux: Add V4L2 YUVA32 and YUVX32 pixel formatsLaurent Pinchart
These YUV 4:4:4 packed formats are used by the ISI driver. Add them to videodev2.h. This is merged in the upstream kernel as 00f6842ef41d ("media: v4l: Add packed YUV 4:4:4 YUVA and YUVX pixel formats"). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-03include: drm_fourcc: Add AVUY and XVUY 4:4:4 packet formatsLaurent Pinchart
Add FourCCs for the YUV 4:4:4 packed formats AVUY8888 and XVUY8888. This is merged in the upstream kernel as 53618649ca6d ("drm/fourcc: Add formats for packed YUV 4:4:4 AVUY and XVUY permutations"). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-03include: linux: Update kernel headers to version v5.19Laurent Pinchart
Update kernel headers to v5.19 using utils/update-kernel-headers.sh and re-instating libcamera local modifications. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Tested-by: Jacopo Mondi <jacopo@jmondi.org>
2022-08-03libcamera: v4l2_videodevice: Match formats supported by the deviceJacopo Mondi
Now that V4L2PixelFormat::fromPixelFormat() returns a list of formats to chose from, select the one supported by the video device by matching against the list of supported pixel formats. The first format found to match one of the device supported ones is returned. As the list of pixel formats supported by the video device does not change at run-time, cache it at device open() time. Maximize the lookup efficiency by storing the list of supported V4L2PixelFormat in an std::unordered_set<>. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-03libcamera: v4l2_pixelformat: Implement std::hash specializationLaurent Pinchart
Inject a specialization of std::hash<> for the V4L2PixelFormat class in the std namespace to make it possible to store instances of the class in the std::unordered_map and std::unordered_set containers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-03libcamera: v4l2_pixelformat: Return the list of V4L2 formatsJacopo Mondi
Multiple V4L2 formats can be associated with a single PixelFormat. Now that users of V4L2PixelFormat::fromPixelFormat() have been converted to use V4L2VideoDevice::toV4L2PixelFormat(), return the full list of V4L2 formats in order to prepare to match them against the ones supported by the video device. The V4L2 compatibility layer, not having any video device to interact with, is converted to use the first returned format unconditionally. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-03libcamera: v4l2_videodevice: Reintroduce toV4L2PixelFormat()Jacopo Mondi
This is a partial revert of commit 395d43d6d75b ("libcamera: v4l2_videodevice: Drop toV4L2PixelFormat()") The function was removed because it incorrectly maps non-contiguous V4L2 format variants (ie V4L2_PIX_FMT_YUV420M) to the API version supported by the video device (singleplanar API and multiplanar API). It was decided at the time to remove the function and let its users call directly V4L2PixelFormat::fromPixelFormat() which accepts a 'multiplanar' flags. As we aim to associate multiple V4L2PixelFormat to a single libcamera format, the next patches will verify which of them is actually supported by the video device. For now, return the contiguous version unconditionally. Re-introduce V4L2VideoDevice::toV4L2PixelFormat() and convert all the V4L2PixelFormat::fromPixelFormat() users to use it. The V4L2 compatibility layer is the only outlier as it doesn't have a video device to poke, hence it still uses V4L2PixelFormat::fromPixelFormat(). Next patches will implement the device format matching logic and handle the non-contiguous plane issue in V4L2VideoDevice::toV4L2PixelFormat(). Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-08-03libcamera: formats: Merge V4L2 single and multi formatsJacopo Mondi
To each libcamera PixelFormat two V4L2 formats are associated, the 'single' and 'multi' format variants. The two versions list plane contiguous and non-contiguous format variants, and an optional argument to V4L2PixelFormat::fromPixelFormat() was used to select which one to pick. In order to prepare to remove V4L2PixelFormat::fromPixelFormat(), and considering that no caller in the codebase uses the non-contiguous format variant, merge the two formats vectors in a single one and default the selection to the first available one, which is functionally equivalent to what is currently implemented. Signed-off-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by: Paul Elder <paul.elder@ideasonboard.com>
2022-07-28libcamera: Drop unnecessary typename keyword used with std::enable_if_tLaurent Pinchart
Usage of the std::enable_if_t type doesn't need to be prefixed by typename. Drop the unnecessary keyword. Reported-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-07-28include: linux: Update rkisp1 kernel header for DPCC configurationFlorian Sylvestre
To improve the kernel interface, a proposal has been made to the linux-kernel [1] to improve the configuration of the Defective Pixel Cluster Correction (DPCC). [1] https://lore.kernel.org/linux-media/20220616160456.21549-1-laurent.pinchart@ideasonboard.com/ Update the local copy of the rkisp1-config.h to match the proposal. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Acked-by: Paul Elder <paul.elder@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-07-28libcamera: base: utils: Provide defopt to simplify std::optional::value_or() ↵Laurent Pinchart
usage The std::optional<T>::value_or(U &&default_value) function returns the contained value if available, or default_value if the std::optional has no value. If the desired default value is a default-constructed T, the obvious option is to call std::optional<T>::value_or(T{}). This approach has two drawbacks: - The \a default_value T{} is constructed even if the std::optional instance has a value, which impacts efficiency. - The T{} default constructor needs to be spelled out explicitly in the value_or() call, leading to long lines if the type is complex. Introduce a defopt variable that solves these issues by providing a value that can be passed to std::optional<T>::value_or() and get implicitly converted to a default-constructed T. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-07-28libcamera: yaml_parser: Add getList() functionFlorian Sylvestre
Allow to retrieve a YAML list of any already supported types in a std::vector. Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2022-07-28libcamera: yaml_parser: Preserve order of items in dictionaryLaurent Pinchart
The std::map container used to store dictionary items in YamlObject doesn't preserve the YAML data order, as maps are ordered by key, not by insertion order. While this is compliant with the YAML specification which doesn't guarantee ordering of mappings, the Raspberry Pi IPA relies on elements being ordered as in the YAML data. To replace the dependency on boost with the YamlParser class, we thus need to guarantee that the order is preserved. Preserve the order by storing items in list_ unconditionally. Turn the list_ vector from storing YamlObject unique pointers to storing key-value pairs, with the key being absent when the object is a list, not a dictionary. The YamlObject implementation is updated to preserve the existing API, with the only difference being that YamlObject::memberNames() now returns member names in the same order as in the YAML file. The ordering is an implementation detail, so changing it doesn't violate the YAML specification. The documentation is not updated to reflect this, as we don't want any new user to rely on a particular ordering. This commit could be reverted if desired when the Raspberry Pi IPA updates to a new tuning data format and drops support for the old format. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Naushir Patuck <naush@raspberrypi.com>
2022-07-28libcamera: yaml_parser: Replace ok flag to get() with std::optionalLaurent Pinchart
The YamlObject::get() function takes a default value and an optional bool ok flag to handle parsing errors. This ad-hoc mechanism complicates error handling in callers. A better API is possible by dropping the default value and ok flag and returning an std::optional. Not only does it simplify the calls, it also lets callers handle errors through the standard std::optional class instead of the current ad-hoc mechanism. Provide a get() wrapper around std::optional::value_or() to further simplify callers that don't need any specific error handling. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Naushir Patuck <naush@raspberrypi.com> Tested-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
2022-07-27raspberrypi: Update Copyright statement in all Raspberry Pi source filesNaushir Patuck
s/Raspberry Pi (Trading) Limited/Raspberry Pi Ltd/ to reflect the new Raspberry Pi entity name. 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>
2022-07-20libcamera: controls: Suppress error message from ControlList::get()Naushir Patuck
Now that ControlList::get() returns a std::optional<T> to handle missing controls, the error log message in the call to ControlList::find() is unnecessary and likely invalid. Fix this by avoiding the call to ControlList::find() from ControlList::get() and replacing with a call to the underlying std::unordered_map::find(). Fixes: 1c4d48018505 ("libcamera: controls: Use std::optional to handle invalid control values") Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
2022-07-20libcamera: controls: Drop ControlList::contains()Laurent Pinchart
The ControlList::contains(const ControlId &id) function isn't used, as it has been replaced by usage of the get() function. Document get as being the preferred way to check for the presence of a control in a ControlList, and drop the contains() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
2022-07-20libcamera: Remove extra ':' after '\todo'Laurent Pinchart
The doxygen '\todo' directory doesn't need to be followed by a colon, yet a few strayed occurrences have made their way in. Fix them. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
2022-07-19libcamera: controls: Use std::optional to handle invalid control valuesChristian Rauch
Previously, ControlList::get<T>() would use default constructed objects to indicate that a ControlList does not have the requested Control. This has several disadvantages: 1) It requires types to be default constructible, 2) it does not differentiate between a default constructed object and an object that happens to have the same state as a default constructed object. std::optional<T> additionally stores the information if the object is valid or not, and therefore is more expressive than a default constructed object. Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de> Reviewed-by: Jacopo Mondi <jacopo@jmondi.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@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-04libcamera: framebuffer: Turn the cookie into a 64-bit integerLaurent Pinchart
To allow associating pointers with FrameBuffer instances, turn the cookie into a 64-bit integer. This matches the Request cookie with is also a uint64_t. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
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-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>