Update CamHelper::getDelays() to return the sensor HBLANK delay. The
HBLANK delay is set to the same value as VBLANK delay for all sensors in
the Raspberry Pi IPA.
Return the HBLANK gain delay from the IPA to the pipeline handler, and
initialise DelayedControls to handle V4L2_CID_HBLANK with this delay
value.
As a drive-by, check that the V4L2_CID_HBLANK control is available when
calling IPARPi::configure().
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Append "_mono" to the sensor name when generating the tuning filename for
monochrome sensor variants. So the new naming convention is as follows:
<sensor_name>.json - Standard colour sensor variant
<sensor_name>_mono.json - Monochrome sensor variant
Rename the existing imx296.json file to imx296_mono.json as this tuning file
is based on the monochrome variant of the IMX296.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The "R" pixel formats (R8, R10, R10_CSI2P etc.) record the associated
colour space as being YUV rather than RAW, meaning that the code was
not detecting them as being raw formats.
In the case of Raspberry Pi, we deal only with raw formats, so the
revised test must work correctly for both these and the standard Bayer
formats.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
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>
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>
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>
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>
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>
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>
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>
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>
This is a partial revert of commit 395d43d6d7 ("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>
Denoise and Sharpness filters will be applied by RkISP1 during the
demosaicing step. The denoise filter is responsible for removing noise
from the image, while the sharpness filter will enhance its acutance.
Add filter algorithm with denoise and sharpness values based on user
controls.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The logic used to match asynchronous image and embedded buffers was being overly
aggressive by possibly allowing an unmatched image buffer to be sent to the IPA
if the matching embedded buffer had not yet been dequeued. This condition only
occurs when the system is heavily loaded and dropping frames.
Fix this by holding image buffer in the queue during these conditions until the
next embedded buffer dequeue event.
Reported-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Tested-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Some hardware supported by the rkisp1 driver, such as the ISP in the
i.MX8MP, don't have a self path. Although at the moment the driver still
exposes the self path, prepare the rkisp1 pipeline handler for when the
self path will be removed for devices that don't support it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Now that the ControlList::get() function returns an instance of
std::optional<>, we can replace the ControlList::contains() calls with a
nullopt check on the return value of get(). This avoids double lookups
of controls through the code base.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
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>
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>
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: 9dacde0d65 (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>
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>
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>
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>
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>
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>
As the simple pipeline handler targets simple pipelines on the SoC side,
it often gets used with platforms that have a YUV sensor capable of
outputting different sizes. Extend the heuristics used for pipeline
discovery and configuration to scale as much as possible on the sensor
side, in order to minimize the required bandwidth.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When enumerating the supported configurations, store the corresponding
sensor resolution in the SimpleCameraData::Configuration structure and
use it when configuring the camera, instead of hardcoding the sensor
full resolution. This prepares for support of downscaling in the camera
sensor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Commit 8a845ab078 ("libcamera: Replace toString with operator<<() for
format classes") incorrectly converted some of the toString() usages,
resulting in pointer values being printed instead of formats. Fix it.
Fixes: 8a845ab078 ("libcamera: Replace toString with operator<<() for format classes")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Use the removable attribute exposed by the USB device in sysfs to infer
if the camera is an external (when removable) or front (when
non-removable) camera. This is likely not perfect as the removable
attribute is derived from ACPI data which may not always be accurate,
and non-ACPI platforms likely report all devices as removable. Still,
this is a first step upon which a better method could be built.
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>
The freeBuffers() cleanup code calls into the IPA to unmap and free
shared buffers. However, this function could be called before the IPA
has opened (via registerCamera()), causing a segmentation fault. Fix
this by guarding against calling the IPA if it has not been opened.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
These changes retrieve the correct value for sensitivity of the mode
selected for the sensor. This value is known to the CamHelper which
passes it across to the pipeline handler so that it can be set
correctly in the camera properties.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Naushir Patuck
Laurent Pinchart
David Plowman
Han-Lin Chen via libcamera-devel
Christian Rauch
Phi-Bang Nguyen
Jacopo Mondi
Florian Sylvestre
Xavier Roumegue
Paul Elder