| Age | Commit message (Collapse) | Author |
|---|
|
Split the Raspberry Pi pipeline handler and IPA source code into common
and VC4/BCM2835 specific file structures.
For the pipeline handler, the common code files now live in
src/libcamera/pipeline/rpi/common/
and the VC4-specific files in src/libcamera/pipeline/rpi/vc4/.
For the IPA, the common code files now live in
src/ipa/rpi/{cam_helper,controller}/
and the vc4 specific files in src/ipa/rpi/vc4/. With this change, the
camera tuning files are now installed under share/libcamera/ipa/rpi/vc4/.
To build the pipeline and IPA, the meson configuration options have now
changed from "raspberrypi" to "rpi/vc4":
meson setup build -Dipas=rpi/vc4 -Dpipelines=rpi/vc4
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
On Raspberry Pi Compute Module platforms, it is possible to attach a
single camera device only to the secondary Unicam port. The current
logic of PipelineHandlerRPi::match() will return a failure during
enumeration of the first Unicam media device (due to no sensor attached,
or sensor failure) and thus the second Unicam media device will never be
enumerated.
Fix this by looping over all Unicam instances in PipelineHandlerRPi::match()
until a camera is correctly registered, or return a failure otherwise.
Reported-on: https://github.com/raspberrypi/libcamera/issues/44
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a new parameter to the pipeline handler config file named
"unicam_timeout_value_ms" to allow users to override the automatically
computed Unicam timeout value.
This value is given in milliseconds, and setting a value of 0 (the
default value) disables the override.
An example use of this parameter would be if an application configured a
RAW stream, and provides buffers for the stream on every request. If the
application holds off on sending requests for a particular reason (e.g.
a timelapse use case), then we will possibly hit the watchdog timeout as
it is only a small multiple of the frame length. This override allows an
application to select a larger value with the knowledge that it may
space requests longer than the calculated timeout value.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add an explicit helper function setCameraTimeout() in the pipeline
handler to set the Unicam timeout value. This function is signalled from
the IPA to set up an appropriate timeout. This replaces the
maxSensorFrameLengthMs value parameter returned back from
IPARPi::start().
Adjust the timeout to be 5x the maximum frame duration reported by the
IPA.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Commit 613d5402673e ("pipeline: raspberrypi: Fix handling of colour
spaces") adjusts the colorspace to ColorSpace::Raw for raw streams.
However, if the colorspace is not requested for raw streams(nullopt),
we should still set the colorspace to ColorSpace::Raw, for raw streams.
Fixes: 613d5402673e ("pipeline: raspberrypi: Fix handling of colour spaces")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Commit 6f6e1bf704fe ("libcamera: camera_sensor: Apply flips at
setFormat()") extended the CameraSensor::setFormat() function
to apply vertical/horizontal flips on the sensor based on the
supplied Transform. To pass the Transform to the function the
V4L2SubdeviceFormat structure has been augmented with a Transform
member.
However as the newly added Transform is not used at all in the
V4L2Subdevice class, it should not be part of V4L2SubdeviceFormat.
Fix that by removing the transform field from V4L2SubdeviceFormat
and pass it as an explicit parameter to CameraSensor::setFormat().
Fixes: 6f6e1bf704fe ("libcamera: camera_sensor: Apply flips at setFormat())
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit 1a614866a29c ("libcamera: camera_sensor: Validate Transform") has
removed usage of the RPiCameraData::supportsFlips_ but hasn't removed
the field itself, nor its initialization. Drop those as they're unused.
Fixes: 1a614866a29c ("libcamera: camera_sensor: Validate Transform")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Add a new pipeline config parameter "disable_startup_frame_drops" to
disable any startup drop frames, overriding the IPA request.
When this parameter is set, it allows the pipeline handler to run with
no internally allocated Unicam buffers ("min_unicam_buffers").
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add the ability to read the platform configuration parameters from a
config file provided by the user through the LIBCAMERA_RPI_CONFIG_FILE
environment variable. Use the PipelineHandler::configurationFile()
helper to determine the full path of the file.
Provide an example configuration file named example.yaml. Currently two
parameters are available through the json file:
"min_unicam_buffers" The minimum number of internal Unicam buffers to
allocate.
"min_total_unicam_buffers" The minimum number of internal + external
Unicam buffers that must be allocated.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Reorder the code such that the IPA requested startup drop frames count is
available before the pipeline handler allocates any stream buffers.
This will be used in a subsequent change to stop Unicam buffer allocations if
there are no startup drop frames required and the application has configured a
raw stream and always provides buffers for it.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a configuration structure to store platform specific parameters used by
the pipeline handler. Currently, these only store Unicam buffer counts,
replacing the hardcoded static values in the source code.
In subsequent commits, more parameters will be added to the configuration
structure, and parameters will be read in through a config file.
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>
|
|
We implement a custom validateColorSpaces method that forces all
(non-raw) streams to same colour space, whilst distinguishing RGB
streams from YUV ones, as the former must have the YCbCr encoding and
range over-written.
When we apply the colour space, we always send the full YUV version as
that gets converted correctly to what our hardware drivers expect. It
is also careful to check what comes back as the YCbCr information gets
overwritten again on the way back.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
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>
|
|
Add a setLensControls() function to the IPA/pipeline handler interface. This
will be used in a future commit to control the lens actuator position from an
autofocus algorithm.
Signed-off-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Pass the available lens controls to the IPA through the configure() function.
Validate that the V4L2_CID_FOCUS_ABSOLUTE does exist. If it doesn't, log a
warning message, and do not advertise focus related controls from the IPA.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Replace the legacy entityControls map passed into ipa::configure() with explicit
fields for sensor and ISP controls. This removes any ambiguity over which set of
controls corresponds with specific integer keys.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Remove the streamConfig parameter from the ipa::configure() call, it is never
used.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Check if a lens actuator is available by the presense of the lens driver entity
in the pipeline handler. Pass this result to the IPA on init.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Nick Hollinghurst <nick.hollinghurst@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Previously the x,y offsets in the min/max ScalerCrop control values
were zero. Here we make them the same as the sensor's analogue crop
offset which is I think less misleading.
With this change, it also seems reasonable to advertise the default
scaler crop value to be the true default that you will get. This makes
it possible for applications to see what that value will be without
having to start the camera and wait for frames.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Augment the CameraSensor::setFormat() function to configure horizontal
and vertical flips before applying the image format on the sensor.
Applying flips before format is crucial as they might change the Bayer
pattern ordering.
To allow users of the CameraSensor class to specify a Transform,
add to the V4L2SubdeviceFormat class a 'transform' member, by
default initialized to Transform::Identity.
Moving the handling of H/V flips to the CameraSensor class allows to
remove quite some boilerplate code from the IPU3 and RaspberryPi
pipeline handlers.
No functional changes intended.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
|
|
The two pipeline handlers that currently support Transform (IPU3 and
RaspberryPi) implement it by operating H/V flips on the image sensor.
Centralize the code that validates a Transform request against the
sensor rotation capabilities in the CameraSensor class.
The implementation in the IPU3 pipeline handler was copied from the
RaspberryPi implementation, and is now centralized in CameraSensor to
make it easier for other platforms.
The CameraSensor::validateTransform() implementation comes directly from
the RaspberryPi pipeline handler, no functional changes intended.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
|
|
Pass an IPA cookie from the pipeline handler to the IPA and eventually back to
the pipeline handler through the setDelayedControls signal. This cookie is used
to index the RPiController::Metadata object to be used for the frame.
The IPA cookie is then returned from DelayedControls when the frame with the
applied controls has been returned from the sensor, and eventually passed back
to the IPA from the signalIspPrepare signal.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Allow the caller to provide a cookie value to DelayedControls::reset and
DelayedControls::push. This cookie value is returned from DelayedControls::get
for the frame that has the control values applied to it.
The cookie value is useful in tracking when a set of controls has been applied
to a frame. In a subsequent commit, it will be used by the Raspberry Pi IPA to
track the IPA context used when setting the control values.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Switch the Raspberry Pi pipeline handler to use the DelayedControls
implementation in the RPi:: namespace. This will allow us to use Raspberry Pi
specific API changes in future commits.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The BufferMask enum provides a way of identifying which stream a frame buffer
belongs to. This enum is defined in the raspberrypi.mojom interface file.
However, the IPA does not need these enum definitions to mmap buffers that it
uses.
Move this enum out of the raspberrypi.mojom interface file and put it into
the RPi namespace visible only to the pipeline handler. This removes the
need to include the auto-generated IPA interface header in the RPi::Stream
definition.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Implement the PipelineHandlerRPi::releaseDevice method which allows
us to free any allocated buffers when a camera is released.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This reverts commit 30d704732badc675f72fe73d14749669cb645c23.
It turns out that this commit causes some regressions and is in fact
unnecessary because the related commit "libcamera: v4l2_videodevice:
Guard against releasing unallocated buffers"
(a2bdff6d0b67475492ac7cf9318866b6d89a28fd) fixes the problem
completely (if the buffers were never allocated, the video device
avoids trying to free them even if the pipeline handler asks).
The reason for the regressions is that in this new (broken) scheme we
would never call clearBuffers() on all the streams if the internal
buffers were never allocated (i.e. buffersAllocated_ is never
set). This causes the stream's bufferMap_ list to get longer and
longer if there are multiple back-to-back calls to configure, and
dev_->importBuffers() will ultimately to fail.
So either we need to think more carefully about how to stop the
pipeline handler from freeing buffers that it doesn't own, or we just
leave it as the other commit resolves the problem on its own. In the
interim, simply reverting this commit certainly seems like the best
solution.
Fixes: 30d704732bad ("pipeline: raspberrypi: Do not unconditionally free buffers on close")
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The PipelineHandler::generateConfiguration() function allocates a
CameraConfiguration instance and returns it. The ownership of the
instance is transferred to the caller. This is a perfect match for a
std::unique_ptr<>, which the Camera::generateConfiguration() function
already returns. Update PipelineHandler::generateConfiguration() to
match it. This fixes a memory leak in one of the error return paths in
the IPU3 pipeline handler.
While at it, update the Camera::generateConfiguration() function
documentation to drop the sentence that describes the ownership
transfer, as that is implied by usage of std::unique_ptr<>.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When a camera is terminated, do not unconditionally free buffers in the
RPiCameraData destructor. Otherwise, this causes harmless error log messages
to be displayed if no buffer have previously been allocated.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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: 9dacde0d651d (pipeline: raspberrypi: Advertise ScalerCrop from the pipeline handler)
Reported-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
|
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>
|
|
Now that format classes implement the stream formatting operator<<(),
use it instead of the toString() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Now that geometry classes implement the stream formatting operator<<(),
use it instead of the toString() function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
FrameBuffer::cancel() is not meant to be used by applications. Move it
to the FrameBuffer::Private class.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
[Kieran: Handle rebase]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Enable the V4L2VideoDevice dequeue timeout for the Unicam Image node, and
connect the timeout signal to a slot in the pipeline handler. This slot will
log an error message informing the user of a possible hardware stall.
The timeout is calculated as 2x the maximum frame length possible for a given
mode, returned by the IPA.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
