Allow the DmaBufAllocator used by the software ISP to use memfd() +
/dev/udmabuf for the software ISP destination buffers.
This is useful on Linux distributions where normal users are not allowed
to access /dev/dma_heap/* while they are allowed to access /dev/udmabuf.
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>
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>
The subdev embedded data support series includes a change to the
VIDIOC_SUBDEV_G_ROUTING and VIDIOC_SUBDEV_S_ROUTING ioctls that impacts
the userspace API.
Update to the new API, while preserving backward compatibility to ease
the transition. Document the backward compatibility to only be supported
for two kernel releases. As the routing API isn't enabled in any
upstream kernel yet, users of the API need kernel patches, and are
expected to be able to upgrade quickly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-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>
TODO #4 was recorded at a time where the IPA module computed gain values
and the ISP computed the look up tables. The gains were higher-level
parameters. Now that the look up tables are computed in the IPA module,
the IPA and ISP are more tightly coupled and the TODO item is less
relevant.
Let's drop the TODO item. We may or may not need to switch to a
different representation in future but there is currently no good need
for this and the conversion of the values would be just waste of CPU
cycles.
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>
Constructing the color mapping tables is related to stats rather than
debayering, where they are applied. Let's move the corresponding code
to stats processing.
The same applies to the auxiliary gamma table. As the gamma value is
currently fixed and used in a single place, with the temporary exception
mentioned below, there is no need to share it anywhere anymore.
It's necessary to initialize SoftwareIsp::debayerParams_ to default
values. These initial values are used for the first two frames, before
they are changed based on determined stats. To avoid sharing the gamma
value constant in artificial ways, we use 0.5 directly in the
initialization. This all is not a particularly elegant thing to do,
such a code belongs conceptually to the similar code in stats
processing, but doing better is left for larger refactoring.
This is a preliminary step towards building this functionality on top of
libipa/algorithm.h, which should follow.
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To match the enumerated media devices, each registered pipeline handler
is used in no specific order. It is a limitation when several pipelines
can match the devices, and user has to select a specific pipeline.
For this purpose, environment variable LIBCAMERA_PIPELINES_MATCH_LIST is
created to give the option to define an ordered list of pipelines to
match on.
LIBCAMERA_PIPELINES_MATCH_LIST="<name1>[,<name2>[,<name3>...]]]"
Example:
LIBCAMERA_PIPELINES_MATCH_LIST="rkisp1,simple"
Signed-off-by: Julien Vuillaumier <julien.vuillaumier@nxp.com>
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>
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>
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
template files and templates embedded in generator scripts.
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>
When the C library doesn't provide local object support, the
utils::strtod() function simply calls strtod() from the C library. The
current implementation does so incorrectly, and calls utils::strtod()
instead, resulting in infinite recursion. Fix it with a proper namespace
qualifier.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Provide the Sony IMX415 camera sensor properties and registration
with libipa for the gain code helpers.
The test patterns exposed by the IMX415 do not map well to the current
set of test pattern controls supplied by libcamera. These are left
intentionally unimplemented.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Black may not be represented as 0 pixel value for given hardware, it may
be higher. If this is not compensated then various problems may occur
such as low contrast or suboptimal exposure.
The black pixel value can be either retrieved from a tuning file for the
given hardware, or automatically on the fly. The former is the right
and correct method, while the latter can be used when a tuning file is
not available for the given hardware. Since there is currently no
support for tuning files in software ISP, the automatic, hardware
independent way, is always used. Support for tuning files should be
added in future but it will require more work than this patch.
The patch looks at the image histogram and assumes that black starts
when pixel values start occurring on the left. A certain amount of the
darkest pixels is ignored; it doesn't matter whether they represent
various kinds of noise or are real, they are better to omit in any case
to make the image looking better. It also doesn't matter whether the
darkest pixels occur around the supposed black level or are spread
between 0 and the black level, the difference is not important.
An arbitrary threshold of 2% darkest pixels is applied; there is no
magic about that value.
The patch assumes that the black values for different colors are the
same and doesn't attempt any other non-primitive enhancements. It
cannot completely replace tuning files and simplicity, while providing
visible benefit, is its goal. Anything more sophisticated is left for
future patches.
A possible cheap enhancement, if needed, could be setting exposure +
gain to minimum values temporarily, before setting the black level. In
theory, the black level should be fixed but it may not be reached in all
images. For this reason, the patch updates black level only if the
observed value is lower than the current one; it should be never
increased.
The purpose of the patch is to compensate for hardware properties.
General image contrast enhancements are out of scope of this patch.
Stats are still gathered as an uncorrected histogram, to avoid any
confusion and to represent the raw image data. Exposure must be
determined after the black level correction -- it has no influence on
the sub-black area and must be correct after applying the black level
correction. The granularity of the histogram is increased from 16 to 64
to provide a better precision (there is no theory behind either of those
numbers).
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
Define the Soft IPA main and event interfaces, add the Soft IPA
implementation.
The current src/ipa/meson.build assumes the IPA name to match the
pipeline name. For this reason "-Dipas=simple" is used for the
Soft IPA module.
Auto exposure/gain and AWB implementation by Dennis, Toon and Martti.
Auto exposure/gain targets a Mean Sample Value of 2.5 following
the MSV calculation algorithm from:
https://www.araa.asn.au/acra/acra2007/papers/paper84final.pdf
Use CameraSensorHelper to convert the analogue gain code read from the
camera sensor into real analogue gain value. In the future this makes
it possible to use faster AE/AGC algorithm. Right now the CameraSensorHelper
lets us use the full range of analogue gain values.
If there is no CameraSensorHelper for the camera sensor in use, a
warning log message is printed.
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>
Co-developed-by: Dennis Bonke <admin@dennisbonke.com>
Signed-off-by: Dennis Bonke <admin@dennisbonke.com>
Co-developed-by: Marttico <g.martti@gmail.com>
Signed-off-by: Marttico <g.martti@gmail.com>
Co-developed-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Add a CPU based SwStats implementation for SoftwareISP / SoftIPA use.
This implementation offers a configure function + functions to gather
statistics on a line by line basis. This allows CPU based software
debayering to call into interleave debayering and statistics gathering
on a line by line basis while the input data is still hot in the cache.
This implementation also allows specifying a window over which to gather
statistics instead of processing the whole frame.
Doxygen documentation by Dennis Bonke.
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>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Co-developed-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Co-developed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Co-developed-by: Dennis Bonke <admin@dennisbonke.com>
Signed-off-by: Dennis Bonke <admin@dennisbonke.com>
Co-developed-by: Marttico <g.martti@gmail.com>
Signed-off-by: Marttico <g.martti@gmail.com>
Co-developed-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Toon Langendam <t.langendam@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The SharedMemObject class template contains a fair amount of inline code
that does not depend on the template types T. To avoid duplicating it in
every template specialization, split that code to a separate base
SharedMem class.
We don't define copy semantics for the classes (we don't need one at the
moment) and we make them non-copyable since the default copy constructor
would lead to use-after-unmap.
Doxygen documentation by Dennis Bonke and Andrei Konovalov.
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Milan Zamazal <mzamazal@redhat.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Co-developed-by: Dennis Bonke <admin@dennisbonke.com>
Signed-off-by: Dennis Bonke <admin@dennisbonke.com>
Signed-off-by: Andrei Konovalov <andrey.konovalov.ynk@gmail.com>
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>
The CameraSensor class tests if the sensor HBLANK control is read-only
by comparing the minimum and maximum values, and documents this as being
a workaround for the lack of a read-only control flag in V4L2. This is
incorrect, as the V4L2 API provides such a flag. Use it to replace the
workaround.
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>
The CameraSensor class has grown a lot since its creation, with many
functions added for different types of purposes. They are not grouped by
categories in the class definition, generating confusion when reading
the header file. Improve readability by sorting functions by category:
- Getters for static data (model, entity, focus lens, ...)
- Format and sensor configuration accessors
- Properties and controls (including test pattern mode)
Update the .cpp file accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
The CameraSensor::updateControlInfo() function is a wrapper around the
same function of the V4L2Subdevice class. It was meant to be called by
pipeline handlers that modify the sensor configuration directly,
bypassing the CameraSensor::setFormat() function. This never happened,
and the function is called once only, internally to the CameraSensor
class. No external users are foreseen, drop the function and call
V4L2Subdevice::updateControlInfo() directly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
The V4L2Subdevice class deals with streams in two places:
- In routing tables, streams as expressed as a pad number and a stream
number in a v4l2_subdev_route instance.
- In the format and selection get and set functions, streams as
expressed using the Stream structure, which binds the pad number and
stream number.
Expressing streams in different ways requires pipeline handlers and
other helpers to convert between the two representations. This isn't
much of an issue yet as libcamera has little stream-aware code, but it
is expected to increasingly become a burden.
To simplify the API, introduce a V4L2Subdevice::Route structure that
mimicks the kernel v4l2_subdev_route structure but represents streams as
V4L2Subdevice::Stream instances. This will improve seamless integration
of routes, formats and selection rectangles.
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>
The main (and only at the moment) use case for the Routing::toString()
function is to print a representation of the routing table in a log
message. The function is implemented using an std::stringstream, and the
returned std::string is then inserted into an std::ostream. This is
inefficient. Replace the function with a specialization of the
operator<<() and use it in the caller.
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>
