| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
The ycbcrEncodingToV4l2 map is missing the YCbCrEncoding::None encoding,
which results in a failure of V4L2Device::fromColorSpace() to convert
color spaces from libcamera to V4L2 for RGB formats. Fix it by adding
the missing encoding. As V4L2 has no such encoding, use
V4L2_YCBCR_ENC_DEFAULT as the value doesn't matter.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add support for color space to the uvcvideo pipeline handler. UVC
devices have a fixed color space per format, so only the validate()
function needs to be extended to retrieve the color space from the
kernel. There is no need to pass the value back to the driver in
configure().
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
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>
|
|
Rectify the ColorSpace::Srgb to denote that it does not use
any Y'Cbcr encoding and uses full range.
The kernel on the other hand, recommends to use Rec601 as the encoding
for V4L2_COLORSPACE_SRGB. It is not very explicit but it can be
inferred that the kernel assumes V4L2_COLORSPACE_SRGB is a YUV-encoded
one. However, when the data is in RGB, no encoding is required (and
this is denoted by YcbcrEncoding::None in libcamera).
Hence, to be clear on the libcamera colorspace API, rectify the
ColorSpace::Srgb preset to use YcbcrEncoding::None and full range.
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>
|
|
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>
|
|
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>
|
|
Store the colour encoding corresponding to a media bus format in the
V4L2SubdeviceFormatInfo structure. This will be used to implement color
space adjustments.
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>
|
|
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>
|
|
doxygen didn't create proper links to the overloads of
MediaDevice::link because the signatures didn't match due to an
additional 'const'
While at it remove the unnecessary `MediaDevice::` and wrap the lines
Fixes: b65feafe3244 ("libcamera: media_device: Add functions to get a MediaLink")
Signed-off-by: Marvin Schmidt <marvin.schmidt1987@gmail.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>
|
|
Implement color space support in the rkisp1 pipeline handler, in the
configuration generation, configuration validation and camera
configuration. As all the processing related to the color space is
performed in the part of the pipeline shared by all streams, a single
color space must cover all stream configurations. This is enforced
manually when generating the configuration, and with the
validateColorSpaces() helper when validating it.
Only the Y'CbCr encoding and quantization range are currently taken into
account, and they are programmed through the V4L2 color space API. The
primary colors chromaticities and the transfer function need to be
configured in the ISP parameters buffer, and thus conveyed to the IPA,
but the rkisp1 driver does not currently support tone mapping, so this
will be done later.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Florian Sylvestre <fsylvestre@baylibre.com>
|
|
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>
|
|
Sort the members of the ColorSpace class in color_space.cpp to match the
color_space.h order. No functional change intended.
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>
|
|
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>
|
|
Using Size::expandTo() to find the max resolution might generate a non-existent
resolution. For example, when application request streams for 1920x1080 and
1600x1200, the max resolution will be wrongly 1920x1200 and fails the
configuration.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=139
Signed-off-by: Han-Lin Chen <hanlinchen@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Use a const reference in range-based for loops to avoid copies of the
loop elements.
While at it, change looping over controls in
PipelineHandlerUVC::processControls to use structured bindings.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The specializations of the YamlObject::get() function template for
integer types duplicate code that doesn't directly depend on the
template type argument. Move it to separate helper functions to reduce
the object size.
While at it, rephrase the comment about unsigned integer parsing.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
The YamlObject::get() function specializations for 16-bit integers cast
the return value of strto(u)l() to a 16-bit integer, rendering the
bounds checking useless. Fix them.
Fixes: c7d260c03abd ("libcamera: yaml_parser: Add get() specializations for 16-bit integers")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The variable 'ret' is assigned but not read until after the next
assignment.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The colorspace fields are read-only from an application point of view,
both on video devices and on subdevs, unless the
V4L2_PIX_FMT_FLAG_SET_CSC or V4L2_MBUS_FRAMEFMT_SET_CSC flags
(respectively) are set when calling the S_FMT ioctl.
Set the flags accordingly within the V4L2SubDevice and V4L2Device when
a colorspace is being set by the application.
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>
|
|
Usage of find_library() to find dependencies that libcamera needs to
compile against can lead to the library being found even if the
corresponding headers are not installed. This will then result in a
compilation failure. Switch to dependency() for libdw, libunwind and
lttng-ust to fix this, all three libraries come with a pkgconfig file
that is usually installed by the distribution package that contains the
library headers.
Reported-by: Christian Rauch <Rauch.Christian@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
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>
|
|
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>
|
|
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".
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The YamlParser::get<>() function returns an std::optional<> to indicate
when YAML parsing failed.
The current implementation returns a default constructed std::optional
in case of errors with
return {};
This has been reported as generating compiler warnings with a gcc 9.3.0
arm64 cross-compiler:
../src/libcamera/yaml_parser.cpp:184:11: error: ‘<anonymous>’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
184 | return {};
| ^
Replace this with an explicit
return std::nullopt;
which fixes the warnings and conveys the purpose more explicitly.
Reported-by: Christian Rauch <Rauch.Christian@gmx.de>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Commit b382f67c833d ("libcamera: Make IPA module signing mandatory for
the meantime") made openssl and gnutls dependencies mandatory to work
around the lack of proper IPA module isolation support, which broke
operation without module signatures. This has now been fixed, so IPA
module isolation isn't strictly required anymore.
There are few use cases for disabling module signing completely, given
that the openssl or gnutls dependencies are available on the vast
majority of systems and the overheard introduced by isolating all IPA
modules when signatures are not available is better avoided.
Nonetheless, libcamera should operate properly with forced IPA module
isolation, so we can support those use cases.
Adopt a middle-ground approach to avoid unintentional isolation by
documenting the dependencies as recommended, and warn at meson setup
time if they are not found.
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>
|
|
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>
|
|
If the public key fails to load, PubKey::isValid() function returns
false. The only user of the PubKey class, the IPAManager class, doesn't
check that condition, and still calls the PubKey::verify() function,
which leads to a crash.
Fix this by returning false from PubKey::verify() if the key isn't
valid, and log a warning in the IPAManager constructor to report the
issue.
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>
|
|
The gnutls library ships a pkgconfig .pc file. Use the standard
dependency() method to locate it, instead of cc.find_library().
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>
|
|
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>
|
|
One typo is corrected, and this format is added to one further table
where it was missing entirely.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The python3-yaml package (containing the PyYAML Python package) shipped
by Debian stable is documented as a YAML 1.1 parser:
Python3-yaml is a complete YAML 1.1 parser and emitter for Python3.
PyYAML doesn't implement YAML 1.2 support, but ignores the minor number
of the YAML directive, and thus doesn't choke on the libcamera internal
files used to generate format- and control-related source code that
explicitly state conformance with YAML 1.2. Still, given that we don't
use any feature of YAML 1.2, and that the tuning data files now use YAML
1.1, switch the internal YAML files to version 1.1 as well for
consistency.
The main drawback of YAML 1.1 is that the unquoted literal strings Yes,
No, On and Off will be parsed as booleans. We need to be careful to
avoid those values in YAML files, until libcamera can switch to YAML 1.2
once more recent versions of libyaml get shipped by the distributions we
want to support. This is however not an issue introduced by this change,
as the existing YAML 1.2 files were parsed with the YAML 1.1 string
literal parsing rules anyway.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
Several NXP i.MX8 SoCs (such as the i.MX8MN and i.MX8MP) contain a
camera pipeline made of sensor interfaces (with parallel and/or CSI-2
receivers) and an image processing engine named ISI. The ISI contains an
input crossbar switch and one or more processing pipelines capable of
format conversion and scaling.
This is a good candidate for the simple pipeline handler as a first
step. The i.MX8MP should eventually graduate to having its own pipeline
handler as it also contains two ISP instances (supported by the rkisp1
driver).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
If a subdev supports the internal routing API, pads unrelated to the
pipeline for a given camera sensor may carry streams for other cameras.
The link setup logic is updated to take this into account, by avoiding
disabling links to unrelated pads.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
When traversing the media graph to discover a pipeline from the camera
sensor to a video node, all sink-to-source paths inside subdevs are
considered. This can lead to invalid paths being followed, when a subdev
has restrictions on its internal routing.
The V4L2 API supports exposing subdev internal routing to userspace.
Make use of this feature, when implemented by a subdev, to restrict the
internal paths to the currently active routes. If a subdev doesn't
implement the internal routing operations, all source pads are
considered, as done today.
This change is needed to properly support multiple sensors with devices
such as the NXP i.MX8 ISI or the MediaTek i350 and i500 SENINF. Support
for changing routes dynamically will be added later when required.
Signed-off-by: Phi-Bang Nguyen <pnguyen@baylibre.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
To setup links the pipeline handler iterates over all entities in the
pipeline and disables all links but the ones we want to enable. Some
entities don't allow multiple sink links to be enabled, so the iteration
needs to be based on sink entities, disabling all their links first and
then enabling the sink link that is part of the pipeline.
The loop implementation iterates over all Entity instances, and uses
their source link to locate the MediaEntity for the connected sink. The
sink entity is then processed in the context of the source's loop
iteration. This prevents the code from being able to access extra
information about the sink entity, as we only have access to the
MediaEntity, not the Entity.
To prepare for subdev routing support that will require accessing
additional entity information, refactor the loop to process the sink
entity in the context of its Entity instance.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Reset the routing table of subdevices supporting the V4L2 streams API to
its default state when initializing the pipeline handler. This avoids
issues caused by usage of leftover state.
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>
|
