| Age | Commit message (Collapse) | Author |
|---|
|
There is already support for enums as struct members, but there was no
support for enums in function parameters. Add it.
This does not add support for returning enums as direct return values.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add an enum field to the test struct member to test
serialization/deserialization of enums that are struct members.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Update the imx219, imx477 and imx519 parsers to extract the line length
values from the embedded data stream and use these values in the
deviceStatus metadata, replacing the DelayedControls provided values.
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>
|
|
Rename CamHelper::getVBlanking to CamHelper::getBlanking, and update the
calculations in that function to return both horizontal and vertical
blanking values for a given exposure time and frame duration limits. The
calculations are setup such that vertical blanking is extended to the
maximum allowable value, and any remainder gets put into horizontal
blanking.
The calculated horizontal blanking value is now returned to the pipeline
handler to pass into DelayedControls to program into the sensor.
Update the IPA to now specify the maximum frame duration from the
maximum horizontal + vertical blanking values provided by the sensor
mode. Additionally, the IPA now uses the frame specific horizontal
blanking value (as returned by DelayedControls) in all instances.
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>
|
|
Add a lineLength field to the DeviceStatus structure to store the line
length used for a particular frame.
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>
|
|
Add CamHelper::hblankToLineLength() to calculate the line length
duration from the horizontal blanking (in pixels) value.
Add CamHelper::lineLengthToHblank() to calculate the horizontal blanking
(in pixels) value from the line length duration.
Add CamHelper::lineLengthPckToDuration() to calculate the line length
duration from the line length in pixels.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The pixel clock rate will be used in subsequent commits to calculate
line length durations.
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>
|
|
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>
|
|
Given that the single user of the CamHelper is the Raspberry Pi IPA, the
initialized_ field check is unnecessary. Remove the check and the field.
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>
|
|
Update CamHelper::exposureLines() and CamHelper::exposure() to take a
line length duration parameter for use in the exposure calculations.
For now, only use the minimum line length for all the calculations to
match the existing IPA behavior.
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>
|
|
Add fields for minimum and maximum line length duration to the
CameraMode structure. This replaces the existing lineLength field.
Any use of the existing lineLength field is replaced by the new
minLineLength field, as logically we always want to use the fastest
sensor readout by default.
As a drive-by cosmetic change, split all fields in the CameraMode
structure into separate lines.
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>
|
|
Add fields for minimum and maximum line length (in units of pixels) to
the IPACameraSensorInfo structure. This replaces the existing lineLength
field.
Update the ipu3, raspberrypi and rkisp1 IPAs to use
IPACameraSensorInfo::minLineLength instead of
IPACameraSensorInfo::lineLength, as logically we will always want to use
the fastest sensor readout by default.
Since the IPAs now use minLineLength for their calculations, set the
starting value of the V4L2_CID_HBLANK control to its minimum in
CameraSensor::init().
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>
|
|
Since libtiff version 20201219, the CFAPATTERN tag is using a variable
count and not the fixed 4 values size.
For reference, the commit introducing this is:
commit 2eb5a954cb7b7ad61559da00743c4b0e2fce34d0
Author: Sam Hasinoff <hasinoff@google.com>
Date: Sun Mar 8 21:23:16 2020 +0100
Make TIFFTAG_CFAPATTERN variable count
Add a version check in the DNGWriter::write function when this tag is
written as this breaks the raw capture in qcam.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
formatInfoMap
The warnings "Unknown subdev format 0x4001, defaulting to RGB encoding" and
"Unknown subdev format 0x1013, defaulting to RGB encoding" are thrown while using
simple pipeline handler with NXP ISI hardware.
The JPEG_1X8 and BGR888_1X24 media bus formats, supported by the ISI driver, are
missing in the V4L2SubdeviceFormatInfo structure storing the correspondence
between a media bus format and a colour encoding. So populate the structure with
the missing media bus formats.
Signed-off-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
This patch release commences the package release procedures for the
project.
Initial releases will include a bump to the patch (0.0.x) version
number, as well as a corresponding increment to the soname.
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Support making releases of libcamera by introducing a helper script
which will facilitate the increment of any release version, along with
generating an associated tag.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide the semver utility (version 3.4.0) from [0] to make use of it
with our versioning and release scripts.
[0] https://raw.githubusercontent.com/fsaintjacques/semver-tool/3c76a6f9d113f4045f693845131185611a62162e/src/semver
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The libcamera project is not yet ready to declare ABI nor API stability,
but it will benefit the community to be able to provide more regular
release cycles to determine 'versioned' points of history.
Ideally, these releases will be made at any ABI breakage, but can be
made at arbitary time based points along the way.
To support releases which may not be ABI stable, declare the soversion
of both the libcamera and libcamera-base library to be dependant upon
both the major minor and patch component of the project version.
As part of this, introduce a new 'Versions' summary section to highlight
the different version components that may become apparent within any
given build.
Bumping versions may leave dangling libcamera.so.* symlinks in build
directories. This will confuse Doxygen which will print during its
directory scanning phase a warning that the symlink can't be read. As we
don't need Doxygen to follow symlinks, disable it with EXCLUDE_SYMLINKS.
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The comment for supporting the custom script on 'make dist' contains a
typo. Fix it.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
V4L2 has deprecated queuing output buffers with bytesused set to 0. Warn
if the caller attempts to do so.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
The bytesused value for the parameters buffer is initialized to 0 and
never set. The V4L2 API specification indicates that, for an output
video device, the driver will set the bytesused value to the size of the
plane in that case. The videobuf2 framework does so, but considers this
as deprecated and prints a warning:
[ 54.375534] use of bytesused == 0 is deprecated and will be removed in the future,
[ 54.388026] use the actual size instead.
Fix it by setting bytesused to the correct value before queuing the
parameters buffer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Private members of the FrameBuffer class are split between FrameBuffer
and FrameBuffer::Private. There was no real justification for this
split, and keeping some members private in the FrameBuffer class causes
multiple issues:
- Future modifications of the FrameBuffer class without breaking the ABI
may be more difficult.
- Mutable access to members that should not be modified by applications
require a friend statement, or going through the Private class.
Move all remaining private members to the Private class to address the
first issue, and add a Private::metadata() function to address the
second problem.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
|
|
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0,
likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera
requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS
support until mid-2024.
As no workaround has been found to fix compilation on gcc 8.3.0 while
still retaining the functionality of utils::defopt, remove it from the
libcamera base library. This change could be reverted once support for
gcc-8 will be dropped.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
utils::defopt causes compilation issues on gcc 8.0.0 to gcc 8.3.0,
likely due to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521
that was fixed in gcc 8.4.0. gcc 8.3.0 may be considered old (libcamera
requires gcc-8 or newer), but it is shipped by Debian 10 that has LTS
support until mid-2024.
As no workaround has been found to fix compilation on gcc 8.3.0 while
still retaining the functionality of utils::defopt, stop using it in the
RkISP1 IPA module.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Commit 09c1b081baa2 ("libcamera: controls: Generate and use fixed-sized
Span types") added explicit Span casts for fixed extent spans that were
required due to the ControlList::set() function that takes an
std::initializer_list not being able to infer a control size from
template arguments. This has now been fixed, so the casts are not needed
anymore. Drop them.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Christian Rauch <Rauch.Christian@gmx.de>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The ControlList::set() function overload used for array controls
constructs a Span from an initializer list. It doesn't specify the Span
size explicitly, which results in a dynamic extent Span being
constructed. That causes a compilation failure for fixed-size array
controls, as they are defined as Control<T> with T being a fixed-extent
Span, and conversion from a dynamic-extent to fixed-extent Span when
calling ControlValue::set() can't be implicit.
Fix this by constructing the Span using the size of the control, which
resolves to a fixed-extent and dynamic-extent Span for fixed-size and
dynamic-size array controls respectively. The ControlList::set()
function that takes an initializer list can then be used for fixed-size
array controls.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Array controls specify the array size through the YAML 'size' element,
which stores a list of values, one per dimension. Variable-size arrays
currently use an empty 'size' list, which prevents describing the number
of dimensions of the array.
Improve this by using the same notation for fixed-size and variable-size
array controls. Dimensions that are not fixed are described as a string
instead of an integer, such as [n], [n,3] or [w,h]. The strings have
currently no special meaning, this may change in the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The gen-controls.py script handles the data structure produced by the
YAML parser manually through the whole code base. Clean this up by
encapsulating it in Control and ControlEnum classes to model a control
and its enum values respectively, to decouple YAML data handling from
generation.
No functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The REGISTER_PIPELINE_HANDLER() macro defines a class type that inherits
from the PipelineHandlerFactory class, and implements a constructor and
a createInstance() function. Replace the code generation through macro
with the C++ equivalent, a class template, as done in libipa with the
Algorithm and CameraSensorHelper factories.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Avoid naked pointer with memory allocation by returning a unique_ptr
from PipelineHandlerFactory::createInstance(), in order to increase
memory allocation safety.
This allows iterating over factories in the CameraManager and unit tests
using const pointers.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The PipelineHandlerFactory::registerType() function is called by the
PipelineHandlerFactory class only. Make it private.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The PipelineHandlerFactory::create() function has no need to modify the
factory instance. Make it const, as well as the createInstance()
function.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The REGISTER_CAMERA_SENSOR_HELPER() macro defines a class type that
inherits from the CameraSensorHelperFactory class, and implements a
constructor and createInstance() function. Replace the code generation
through macro with the C++ equivalent, a class template, as done by the
Algorithm factory.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Avoid naked pointer with memory allocation by returning a unique_ptr
from CameraSensorHelperFactory::createInstance(), in order to increase
memory allocation safety.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraSensorHelperFactory registerType() and createInstance()
functions are called by the CameraSensorHelperFactory class only. Make
them private.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraSensorHelperFactory::createInstance() function has no need to
modify the factory instance. Make it const.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Xavier Roumegue <xavier.roumegue@oss.nxp.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The CameraManager::get() function takes a string containing the ID of
the requested camera. This is correctly documented and implemented in
the .cpp file, but the header file names the parameter 'name' instead of
'id'. Fix it.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Tests are listed in meson.build using arrays that contain the test name
and source files at fixed positions. This isn't very readable, leading
to code using test[0], test[1] and test[2]. Replace the arrays with
dictionaries to improve readability.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The 't' name is very short and not very explicit. Rename it to 'test'
instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The IPAFrameContext documentation has a spurious Doxygen \struct
statement that is not needed, and uses a \struct instead of a \var in
another location. Fix both issues. This doesn't cause any change in the
generated documentation.
Note that the Doxygen output for IPAFrameContext is incorrect,
documentation is missing for all members. This is caused by using "."
instead of "::" in our documentation, which we currently do because the
correct syntax produces Doxygen warnings (and still incorrect output).
See https://github.com/doxygen/doxygen/issues/9343.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Commit 036d26d6677e ("test: threads: Test thread cleanup upon abnormal
termination") added calls to functions provided by the pthread library
in the threads test, but didn't add the corresponding dependency. This
caused a link breakage on some platforms:
/usr/bin/ld: test/threads.p/threads.cpp.o: undefined reference to symbol 'pthread_cancel@@GLIBC_2.4'
/usr/bin/ld: /lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Fix it by adding the missing dependency.
Fixes: 036d26d6677e ("test: threads: Test thread cleanup upon abnormal termination")
Reported-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: Naushir Patuck <naush@raspberrypi.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The sensor black level is 60 (in 10-bits), fix this in the mono variant tuning
file.
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>
|
|
Add the tuning file (imx296.json) for the colour variant of the IMX296 sensor.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
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>
|
|
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>
|
|
Add BayerFormat conversions for formats::R12 (12-bit unpacked) format.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
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>
|
|
Limit the minimum allowable exposure time to a single line in the IMX296
camera helper. This equates to approximately 30us.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The IMX296 implements a 2 frame delay for exposure, gain and vertical
blanking changes. Report this in the camera helper.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If a thread ends abnormally (that is, without retuning normally from its
run() function, for instance with a direct call to pthread_cancel()),
thread cleanup should still be performed. Add a test to ensure this.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
