| Age | Commit message (Collapse) | Author |
|---|
|
Add a flags_ field to indicate stream state information in RPi::Stream.
This replaces the existing external_ and importOnly_ boolean flags.
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>
|
|
Create a new PipelineHandlerBase class that handles general purpose
housekeeping duties for the Raspberry Pi pipeline handler. Code the
implementation of new class is essentially pulled from the existing
pipeline/rpi/vc4/raspberrypi.cpp file with a small amount of
refactoring.
Create a derived PipelineHandlerVc4 class from PipelineHandlerBase that
handles the VC4 pipeline specific tasks of the pipeline handler. Again,
code for this class implementation is taken from the existing
pipeline/rpi/vc4/raspberrypi.cpp with a small amount of
refactoring.
The goal of this change is to allow third parties to implement their own
pipeline handlers running on the Raspberry Pi without duplicating all of
the pipeline handler housekeeping tasks.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Return a const std::string reference from RPi::Stream::name() to avoid
copying a string when not needed.
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>
|
|
Restructure the IPA mojom interface to be more consistent in the use
of the API. Function parameters are now grouped into *Params structures
and results are now returned in *Results structures.
The following pipeline -> IPA interfaces have been removed:
signalQueueRequest(libcamera.ControlList controls);
signalIspPrepare(ISPConfig data);
signalStatReady(uint32 bufferId, uint32 ipaContext);
and replaced with:
prepareIsp(PrepareParams params);
processStats(ProcessParams params);
signalQueueRequest() is now encompassed within prepareIsp().
The following IPA -> pipeline interfaces have been removed:
runIsp(uint32 bufferId);
embeddedComplete(uint32 bufferId);
statsMetadataComplete(uint32 bufferId, libcamera.ControlList controls);
and replaced with the following async calls:
prepareIspComplete(BufferIds buffers);
processStatsComplete(BufferIds buffers);
metadataReady(libcamera.ControlList metadata);
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
At present, the RPiStream buffer ids == -1 indicates an invalid value.
As a simplification, use id == 0 to indicate an invalid value. This
allows for better code readability.
As a consequence of this, use unsigned int for the buffer id values.
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>
|
|
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>
|
|
The current pipeline handler build files require a flat directory
struture for each pipeline handler. Modify the build files to remove
this restriction and allow a directory structure such as:
src/libcamera/pipeline/
|- raspberrypi
|- common
|- vc4
|- rkisp1
|- ipu3
where each subdir (e.g. raspberrypi/common, raspberrypi/vc4) has its own
meson.build file. Such a directory structure will be introduced for the
Raspberry Pi pipeline handler in a future commit.
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>
|
|
The STM32 contains a camera pipeline known as the DCMIPP (Digital
Camera-Memory Interface Pixel Processor) which receives data from a
parallel interface and dumps the post-processed data to memory. The
pipeline is capable of some processing in the form of downscaling
captured data through cropping or skipping the sensor's output.
The simple pipeline handler is quite capable of handling the DCMIPP
given its operation is handled entirely through configuring the pads
of a media graph, so add support for the driver to the pipeline's
supportedDevices array.
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.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>
|
|
Just like we do for other pipeline handlers already.
This ensures we corretly pass on transforms that are not handled by the
sensor - e.g. rotations - back to the app via the config, which is
required on devices like the Pinephone.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Tested-by: Arnav Singh <me@arnavion.dev>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Now that the media bus code selection procedure does not depend
on the ISICameraConfiguration::formatsMap_ remove the association
between PixelFormat supported by the ISI and the media bus code produced
by the sensor.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
At generateConfiguration() a YUV/RGB pixel format is preferred for the
StillCapture/VideoRecording/Viewfinder roles, but currently there are no
guarantees in place that the sensor provides a non-Bayer bus format from
which YUV/RGB can be generated.
This makes the default configuration generated for those roles not to
work if the sensor is a RAW-only one.
To improve the situation split the configuration generation in two,
one for YUV modes and one for Raw Bayer mode.
StreamRoles assigned to a YUV mode will try to first generate a YUV
configuration and then fallback to RAW if that's what the sensor can
provide.
As an additional requirement, for YUV streams, the generated mode has to
be validated with the sensor to confirm the desired sizes can be
generated as the ISI cannot up-scale. In order to test a format use the
newly introduced CameraSensor::tryFormat().
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
The ISICameraConfiguration::validate() function selects which media
bus format to configure the sensor with based on the pixel format
of the first configured stream using the media bus code associated to it
in the formatsMap_ map.
In order to remove the PixelFormamt-to-mbus-code association in
formatsMap_ provide a wrapper function for the newly introduced
getRawMediaBusFormat() and getYuvMediaBusFormat() that automatically
selects what media bus format to use based on the first stream pixel
format.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As per the RAW format selection, the media bus format selection
procedure relies on the direct association of PixelFormat and media
bus code in the formatsMap_ map.
As the ISI can generate YUV and RGB formats from any non-Bayer media
bus format, break out the YUV/RGB media bus format selection to a
separate function.
The newly introduced getYuvMediaBusFormat() tests a list of
known-supported media bus formats against the list of media bus
formats supported by the sensor and tries to prefer media bus
codes with the same encoding as the requested PixelFormat.
Use the newly introduced function in
ISICameraConfiguration::validateYuv() to make sure the sensor can
produce a YUV/RGB media bus format.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The current implementation of the ISI pipeline handler handles
translation of PixelFormat to media bus formats from the sensor
through a centralized map.
As the criteria to select the correct media bus code depends on if the
output PixelFormat is a RAW Bayer format or not, start by splitting
the RAW media bus code procedure selection out by adding a function
for such purpose to the ISICameraData class.
Add the function to the ISICameraData and not to the
ISICameraConfiguration because:
- The sensor is a property of CameraData
- The same function will be re-used by the ISIPipelineHandler
during CameraConfiguration generation.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Files opened internally in libcamera without the O_CLOEXEC file will
remain open upon a call to one of the exec(3) functions. As exec()
doesn't destroy local or global objects, this can lead to various side
effects. Avoid this by opening file descriptors with O_CLOEXEC for all
internal files.
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>
|
|
The ConverterFactoryBase::create() function returns a nullptr when no
converter is found. The only caller, SimpleCameraData::init(), checks if
the converter is valid with isValid(), but doesn't check if the pointer
is null, which can lead to a crash.
We could check both pointer validity and converter validity in the
caller, but to limit the complexity in callers, it is better to check
the converter validity in the create() function and return a null
pointer when no valid converter is found.
Signed-off-by: Suhrid Subramaniam <suhrid.subramaniam@mediatek.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>
|
|
Commit 1a614866a29c ("libcamera: camera_sensor: Validate Transform") has
removed usage of the IPU3CameraData::rotationTransform_ 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: 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>
|
|
Add a pipeline_data_dir variable to the meson build files. This variable
points to the location of pipeline handler specific configuration files
on the filesystem.
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: 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>
|
|
Add support for Transform to the RkISP1 pipeline handler.
The pipeline rotates using the sensor's V/H flips, hence use the
CameraSensor helpers to handle transformation requests from
applications.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-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>
|
|
Comply with a checkstyle suggestion and separate inclusion directives.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Fix various typos in the code base.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move the simple converter implementation to a generic V4L2 M2M class
derived from the converter interface. This latter could be used by
other pipeline implementations and as base class for customized V4L2 M2M
converters.
Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
Convert ControlRingBuffer to a templated class to allow arbitrary ring buffer
array types to be defined. Rename ControlRingBuffer to RingBuffer to indicate
this.
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>
|
|
Fork the libcamera::DelayedControls implementation in the RPi:: namespace, with
the intention of updating the API for Raspberry Pi specific features.
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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Implement support for raw Bayer capture during configuration generation,
validation and camera configuration.
While at it, fix a typo in a comment.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Implement support for raw Bayer capture at runtime, from start() to
stop(). Support of raw formats in the camera configuration is split to a
subsequent change to ease review.
In raw mode, the ISP is bypassed. There is no need to provide parameter
buffers, and the ISP will not generate statistics. This requires
multiple changes in the buffer handling:
- The params and stats buffers don't need to be allocated, and the
corresponding video nodes don't need to be started or stopped.
- The IPA module fillParamsBuffer() operation must not be called in
queueRequestDevice(). As a result, the IPA module thus doesn't emit
the paramsBufferReady signal. The main and self path video buffers
must thus be queued directly in queueRequestDevice().
- The tryCompleteRequest() function must not to wait until the params
buffer has been dequeued.
- When the frame buffer has been captured, the IPA module
processStatsBuffer() operation must be called directly to fill request
metadata.
Signed-off-by: Florian Sylvestre <fsylvestre@baylibre.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Unlike RkISP1Path::generateConfiguration(), the validate() function
doesn't take the camera sensor resolution into account but only
considers the absolute minimum and maximum sizes supported by the ISP to
validate the stream size. Fix it by using the same logic as when
generating the configuration.
Instead of passing the sensor resolution to the validate() function,
pass the CameraSensor pointer to prepare for subsequent changes that
will require access to more camera sensor data. While at it, update the
generateConfiguration() function similarly for the same reason.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Query the driver for the output formats and sizes that it supports,
instead of hardcoding them. This allows future-proofing for formats that
are supported by some but not all versions of the driver.
As the rkisp1 driver currently does not support VIDIOC_ENUM_FRAMESIZES,
fallback to the hardcoded list of supported formats and framesizes. This
feature will be added to the driver in parallel, though we cannot
guarantee that users will have a new enough kernel for it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
