Commit 761545407c ("pipeline: rkisp1: Filter out sensor sizes not
supported by the pipeline") introduced a mechanism to determine maximum
supported sensor resolution and filter out resolutions that cannot be
supported by the ISP.
However, it missed to update the raw stream configuration path, where
it should have clamped the raw stream configuration size to the maximum
sensor supported resolution.
This patch fixes the above issue and can be confirmed with IMX283
on i.MX8MP:
From:
($) cam -c1 -srole=raw,width=5472,height=3072
INFO Camera camera.cpp:1197 configuring streams: (0) 5472x3648-SRGGB12
ERROR RkISP1 rkisp1_path.cpp:425 Unable to configure capture in 5472x3648-SRGGB12
Failed to configure camera
Failed to start camera session
To:
($) cam -c1 -srole=raw,width=5472,height=3072
INFO Camera camera.cpp:1197 configuring streams: (0) 4096x3072-SRGGB12
cam0: Capture until user interrupts by SIGINT
536.082380 (0.00 fps) cam0-stream0 seq: 000000 bytesused: 25165824
536.182378 (10.00 fps) cam0-stream0 seq: 000001 bytesused: 25165824
536.282375 (10.00 fps) cam0-stream0 seq: 000002 bytesused: 25165824
...
Fixes: 761545407c ("pipeline: rkisp1: Filter out sensor sizes not supported by the pipeline")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Integrate the RkISP1 pipeline handler to support sensor configuration
provided by applications through CameraConfiguration::sensorConfig.
The SensorConfiguration must be validated on both RkISP1Path (mainPath
and selfPath), so the parameters of RkISP1Path::validate() have been
updated to include sensorConfig.
The camera configuration will be marked as invalid when the sensor
configuration is supplied, if:
- Invalid sensor configuration (SensorConfiguration::isValid())
- Bit depth not supported by RkISP1 pipeline
- Sensor configuration output size is larger than maximum supported
sensor's size on RkISP1 pipeline
- No matching sensor configuration output size supplied by the sensor
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Tested-by: Stefan Klug <stefan.klug@ideasonboard.com>
As described in the coding style document, libcamera favours <cmath>
over <math.h>. Replace the last few occurrences of the latter with the
former and adapt the code accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
As explained in the coding style document, usage of std::lround() is
preferred over lroundf() as it picks the correct function based on
the argument type. Replace calls to lroundf() with std::lround() through
libcamera.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
When constructing a ControlValue from an enum value, an explicit cast to
int32_t is needed as we use int32_t as the underlying type for all
enumerated controls. This makes users of ControlValue more complex. To
simplify them, specialize the control_type template for enum types, to
support construction of ControlValue directly without a cast.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
It is possible that the maximum sensor size (returned by
CameraSensor::resolution()) is not supported by the pipeline. In such
cases, a filter function is required to filter out resolutions of the
camera sensor, which cannot be supported by the pipeline.
Introduce the filter function filterSensorResolution() in RkISP1Path
class and use it for validate() and generateConfiguration(). The
maximum sensor resolution is picked from that filtered set of
resolutions instead of CameraSensor::resolution().
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
The minResolution_ and maxResolution_ limits are dynamically queried
in populateFormats() from the RkISP1Path video node. Therefore,
initializing these limits with the resizer limits in the constructor is
unnecessary.
This change allows us to remove the hard-coded max/min resolution limits
of the resizer from RkISP1Path, simplifying its constructor further.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Which is not only what many other pipeline handlers use, but also a good
lower limit when dealing with DRM and similar APIs. Even Mesas EGL and
Vulkan WSI implementations use for the reason outlined in mesa commit
992a2dbba80aba35efe83202e1013bd6143f0dba:
> When the compositor is directly scanning out from the application's buffer it
> may end up holding on to three buffers. These are the one that is is currently
> scanning out from, one that has been given to DRM as the next buffer to flip
> to, and one that has been attached and will be given to DRM as soon as the
> previous flip completes. When we attach a fourth buffer to the compositor it
> should replace that third buffer so we should get a release event immediately
> after that. This patch therefore also changes the number of buffer slots to 4
> so that we can accomodate that situation.
Given the popularity of this buffer number the bump should be unlikely
to cause problems. At the same time it may help with performance or
even work around glitches.
The previous number was introduced in commit
a8964c28c8 without mentioning a specific
reason against the change at hand.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Use the standard libcamera mechanism to report the "current" controls
rather than delaying updates by counting from the last update.
A problem is that with software ISP we cannot be sure about the sensor
delay. The original implementation simply skips exposure updates for 2
frames, which should be enough in most cases. After this change, we
assume the delay being exactly 2 frames, which may or may not be correct
and may work with outdated values if the delay is shorter.
According to Kieran, the wrong parts are also wrong on the
IPU3/RKISP1/Mali pipelines and only RPi have this correct. We need to
fix this, by correctly specifying the gains in the libipa camera sensor
helpers. The sooner the better because this change could introduce a
risk of increasing oscillations.
This patch also prepares moving exposure+gain to an algorithm module
where the original delay mechanism would be a (possibly unnecessary)
complication.
Resolves software ISP TODO #11 + #12.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds Algorithm::queueRequest call for the defined algorithms.
As there are currently no control knobs in software ISP nor the
corresponding queueRequest call chain, the patch also introduces the
queueRequest methods and calls from the pipeline to the IPA.
This is preparation only since there are currently no Algorithm based
algorithms defined and no current software ISP algorithms support
control knobs.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds Algorithm::configure call for the defined algorithms.
This is preparation only since there are currently no Algorithm based
algorithms defined.
A part of this change is passing IPAConfigInfo instead of ControlInfoMap
to configure() calls as this is what Algorithm::configure expects.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
A previous preparation patch implemented passing frame ids to stats
processing but without actual meaningful frame id value passed there.
This patch extends that by actually providing the frame id and passing
it through to the stats processor.
The frame id is taken from the request sequence number, the same as in
hardware pipelines.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
This patch adds frame and bufferId arguments to stats related calls.
Although the parameters are currently unused, because frame ids are not
tracked and used and the stats buffer is passed around directly rather
than being referred by its id, they bring the internal APIs closer to
their counterparts in hardware pipelines.
It serves as a preparation for followup patches that will introduce:
- Frame number tracking in order to switch to DelayedControls
(software ISP TODO #11 + #12).
- A ring buffer for stats in order to improve passing the stats
(software ISP TODO #2).
Frame and buffer ids are unrelated for the given purposes but since they
are passed together at the same places, the change is implemented as a
single patch rather than two, basically the same, patches.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The ipa_interface.h file includes a number of headers that are not
directly used. Remove them, and add them to the source files that
include ipa_interface.h as required.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
The LSP autoformatter doesn't like some of the current formatting, let's
make it happier. Note that not all of its suggestions were accepted
because readability is preferred and adjusting .clang-format may not be
easy or possible.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
The uvcvideo pipeline handler always keeps the uvcvideo /dev/video# node
for a pipeline open after enumerating the camera.
This is a problem for uvcvideo, as keeping the /dev/video# node open
stops the underlying USB device and the USB bus controller from being
able to enter runtime-suspend causing significant unnecessary
power-usage.
Implement acquireDevice() + releaseDevice(), openening /dev/video# on
acquire and closing it on release to fix this.
And make validate do a local video_->open() + close() around validate()
when not open yet, to keep validate() working on unacquired cameras.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=168
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Now that the IPA module supports the extensible parameters format,
switch to it when available. If the kernel driver doesn't support the
new format, setFormat() will adjust paramFormat to the legacy format,
which will be passed to the IPA module, preserving backward
compatibility.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The ISP parameters buffer currently has a fixed payload size, which is
hardcoded in the pipeline handler. To prepare for support of the
extensible parameters format that has a variable payload size, pass the
size from the IPA module to the pipeline handler explicitly. Keep the
size hardcoded to sizeof(struct rkisp1_params_cfg) for now, this will be
udpated later.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The rkisp1 driver supports two formats for the ISP parameters buffer,
the legacy fixed format and the new extensible format. In preparation of
support for the new format, pass the parameters buffer format from the
pipeline handler to the IPA module and store it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
When the configuration file for an IPA module is missing, it is reported
as an error in the log, for example:
ERROR IPAProxy ipa_proxy.cpp:149 Configuration file 'imx219.yaml' not found for IPA module 'simple'
This is misleading because several pipelines use uncalibrated.yaml in
such a case and can continue working. And in case of software ISP,
there is currently no other configuration file so the error is always
reported.
On the other hand, in some other cases the presence of the configuration
file is required and it is an error if it is missing.
Let's introduce a new optional argument to IPAProxy::configurationFile
that specifies a fallback file if the requested file is not found. If
the primary requested file is not found and a non-empty fallback file is
specified then a warning is logged and the fallback file is looked up.
If neither the fallback file can be found then only then an error is
logged and the method returns an empty string. This change has also the
benefit of putting the common fallback file ("uncalibrated.yaml")
pattern to a single place.
Signed-off-by: Milan Zamazal <mzamazal@redhat.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>
SimplePipelineHandler::match may be called several times for different
pipeline configurations. Not all of these calls must succeed. For
example, for TI AM69 board with a single camera attached, the following
error is reported in the log even when libcamera works fine:
ERROR SimplePipeline simple.cpp:1558 No sensor found
This is because a sensor is found for /dev/media0 but not for
/dev/media1. The error is harmless in such a case and only confuses
users who may think no camera is detected at all. Let's change the
error to info and add the device node to the message to indicate the
error is specific to the given media only. It's up to the callers to
report a fatal error condition if libcamera cannot work due to no
matching pipeline configuration.
Signed-off-by: Milan Zamazal <mzamazal@redhat.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>
The converter interface uses the unsigned int output stream index to map
to the output frame buffers. This is cumbersome to implement new
converters because one has to keep around additional book keeping
to track the streams with their correct indexes.
The v4l2_converter_m2m and simple pipeline handler are adapted to
use the new interface. This work roped in software ISP as well,
which also seems to use indexes (although it doesn't implement converter
interface) because of a common conversionQueue_ queue used for
converter_ and swIsp_.
The logPrefix is no longer able to generate an index from a stream, and
is updated to be more expressive by reporting the stream configuration
instead, for example, reporting "1920x1080-MJPEG" in place of
"stream0".
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com> # sm8250 RB5
generateConfiguration() called validate() as a final step, causing the
stride and frameSize fields in StreamConfiguration to be filled in based
on the pixel format and width/height.
If a user application did not clear the stride field when setting up a
custom pixel format and width/height, the pipeline handler would respect
this stride and possibly overallocate buffers with a larger stride than
needed.
Fix this by removing the call to validate() completely, leaving the
stride and frameSize fields defaulting to 0. Removal of this call is
inconsequential as we hard-code a valid configuration for Raspberry Pi
platforms in generateConfiguration().
Bug: https://github.com/raspberrypi/libcamera/issues/138
Bug: https://github.com/raspberrypi/libcamera/issues/141
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>
Users of the DmaHeap class really just want some way to allocate
dma-buffers from userspace. This can also be done by using /dev/udmabuf
instead of using /dev/dma_heap/*.
Rename DmaHeap class to DmaBufAllocator in preparation of adding
/dev/udmabuf support.
And update the DmaHeap class docs to match including replacing references
to "dma-heap type" with "dma-buf provider".
This is a pure automated rename on the code ('s/DmaHeap/DmaBufAllocator/')
+ file renames + doc updates. There are no functional changes.
The DmaBufAllocator objects in vc4.cpp and software_isp.cpp are left named
dmaHeap_ to keep the changes to those 2 files to a minimum.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # Lenovo-x13s
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Starting in kernel v5.16, the vimc driver stopped hardcoding the scaler
factor. Use this to lift constraints on the camera configuration, and in
particular on the exotic output size alignment to a multiple of 6. As a
result, vimc-based cameras can more easily match common display
resolutions.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
The PipelineHandlerFactoryBase class has a name that is propagated to
the PipelineHandler instance it creates.
In present implementation, this name comes from the
REGISTER_PIPELINE_HANDLER registration macro. It corresponds to the
stringified name of the PipelineHandler derived class. Therefore,
PipelineHandler factories and instances names can be quite long such as
"PipelineHandlerRkISP1".
A libcamera user may have to explicitly refer to a PipelineHandler name
for configuration purpose: one usage of the name can be to define a
pipeline handlers match list and their priorities. It is desired, for
user convenience, to use a short name to designate a pipeline handler.
Reusing the short pipeline names already defined in the meson option
files is an existing and consistent way of naming pipelines.
This change adds an explicit name parameter to the
REGISTER_PIPELINE_HANDLER registration macro. That parameter is used to
define the name of a pipeline handler factory, instead of the current
pipeline handler class name.
Each pipeline registration is updated accordingly. The short name
assigned corresponds to the pipeline directory name in the source tree.
It is consistent with pipelines names used in meson.
Changing the pipeline name has an impact on the IPA modules: each module
defines a IPAModuleInfo structure. This structure has a pipelineName
member defining the pipeline handler name it shall match with.
Therefore, each internal IPA module definition has to be changed to have
its IPAModuleInfo pipelineName name updated with the short pipeline
handler name.
In addition to this pipelineName member, the IPAModuleInfo structure
also has a name member, associated to the IPA module name. Having
renamed the pipelines to a short name, the pipeline name and the IPA
module names of the IPAModuleInfo structure are the same: for in-tree
IPA, they correspond to the respective pipeline and IPA subdirectories
in the source tree. However the IPA name could be different, for
instance with a close source IPA implementation built out-of-tree. Thus,
it makes sense to keep the IPA name in that structure, as the 2
definitions may not always be redundant.
Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Adjust for clang-format style fix, reformat commitmsg]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment blocks in all
remaining locations that were not caught by the automated script as they
are out of sync with the file name.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Some V4L2 formats translate to the same pixel format, e.g. YU12 and
YM12 both produce YUV420. In this case our ISP driver advertises the
same size range for both, but we must not record the same thing twice
for the same pixel format (which will cause a failure later on).
Instead, ignore the V4l2 format if the pixel format has already been
seen.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-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: Kieran Bingham <kieran.bingham@ideasonboard.com>
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
To enable the Simple Soft ISP and Soft IPA for simple pipeline handler
configure the build with:
-Dpipelines=simple -Dipas=simple
Also using the Soft ISP for the particular hardware platform must
be enabled in the supportedDevices[] table. It is currently enabled
for and only for qcom-camss.
If the pipeline uses Converter, Soft ISP and Soft IPA aren't
available.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The converterBuffers_ and the converterQueue_ are not that specific
to the Converter, and could be used by another entity doing the format
conversion.
Rename converterBuffers_, converterQueue_, and useConverter_ to
conversionBuffers_, conversionQueue_ and useConversion_ to
disassociate them from the Converter.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
SimpleCameraConfiguration::validate() adjusts the configuration of its
streams (if the size is not in the outputSizes) to the captureSize. But
the captureSize itself can be not in the outputSizes, and then the
adjusted configuration won't be valid resulting in camera configuration
failure.
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> # sc8280xp Lenovo x13s
Tested-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Pipeline handlers may need to know the Bayer order produced by the
sensor when a Transform is applied (horizontal or vertical flip). This
is currently implemented manually in the Raspberry Pi pipeline handler.
Move the implementation to the CameraSensor class to make it usable in
other pipeline handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
