| Age | Commit message (Collapse) | Author |
|---|
|
The current CameraManager.version doesn't work at all (raises a
TypeError), as that's not how you use expose C++ static methods as
Python class methods.
Fix it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit 66c618f378aa ("android: mm: generic: use
GRALLOC_HARDWARE_MODULE_ID") made libhardware a required dependency for
the Android camera HAL on non-Chrome OS platforms. This isn't an issue
for real devices, as Android provides libhardware, but it prevents
compile-testing the camera HAL on traditional Linux systems.
To restore the compile-test coverage, stub the libhardware function used
by the camera HAL when libhardware isn't found.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # meson build test
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
PlatformFrameBufferAllocator is an abstraction over gralloc.
Right now hardwareModule_ points towards a CAMERA_HARDWARE_MODULE_ID.
When gralloc_open() is called we observe:
libcamera: DEBUG HAL camera3_hal.cpp:75 Open camera gpu0
libcamera: ERROR Camera camera.cpp:524 Camera in Configured state trying acquire() requiring state Available
01-23 14:14:04.742 370 416 E libcamera: FATAL HAL generic_frame_buffer_allocator.cpp:105 gralloc_open() failed: -87
Which is wrong, gralloc_open() is attempting to re-open the camera HAL,
instead of the gralloc HAL.
Point to a GRALLOC_HARDWARE_MODULE_ID instead so that we can request
buffers from gralloc in android.
Note: this adds new dependencies on android's libhardware [1] and on libdl.
[1] https://android.googlesource.com/platform/hardware/libhardware
Fixes: c58662c5770e ("android: Introduce PlatformFrameBufferAllocator")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Copy the sensor properties from Sony IMX290, as the IMX327 is a variant
of it.
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Adjust sort order]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
If a user uses a pipeline handler config file where a custom timeout
value is specified, it would lead to a segmentation fault when
loadPipelineConfiguration() tried to access the as yet uninitialised
V4L2VideoDevice object.
To fix this, parse the pipeline handler config file only after fully
initialising and registering the pipeline handler and V4L2VideoDevice
objects.
Fixes: 6c71ee1f15305 ("pipeline: raspberrypi: Introduce PipelineHandlerBase class")
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support for the Sony IMX327, which is added to the kernel with
commit 2d41947ec2c0 ("media: i2c: imx290: Add support for imx327
variant"). It is basically a derivate of the IMX290, therefore also
derive the helper.
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
As the sensor's analogue gain range is known (read-out in
IPARkISP1::configure()), drop the limiting hard-coded range.
This enables better performance in low-light conditions for sensors with
a higher gain (e.g. the imx327).
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When iterating over enabled pipelines and IPA modules, libcamera
descends into subdirectories in a recursive manner, which involves
nested loops. Both the outer and inner loops use the same loop variable
named 'pipeline'. As the outer loop uses the variable after descending
into the inner directory, it ends up using an incorrect value. Fix it by
moving all use of the variable before the subdir() call, and add a
comment that warns about the issue to avoid reintroducing it.
Fixes: e8526c0c2bc6 ("ipa: meson: Allow nested IPA directory structures")
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>
|
|
Now that we allow IPA modules to live in nested directories for the
RaspberryPi platform, it is required to allow parsing one more level
to be able to run libcamera from the source directory.
Without this patch the $(builddir)/src/ipa/rpi/vc4/ipa_rpi_vc4.so
IPA module cannot be loaded.
The issue is only present when running from the source directory
as when libcamera is installed all IPA modules are deployed to a single
$(prefix)/$(libcamera_libdir)/libamera/ location.
Fixes: 46aefed208fe ("pipeline: meson: Allow nested pipeline handler directory structures")
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@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.
The O_CLOEXEC flag should also be set when obtaining file handles from
the V4L2 VIDIOC_EXPBUF operation, but was missed during the updates to
both d942bdc913c5 ("libcamera: v4l2_device: openat(2) with O_CLOEXEC to
cleanup after exec(3)") and 436b38fd89fe ("libcamera: Open files with
O_CLOEXEC").
Set the O_CLOEXEC flag on calls to ioctl(VIDIOC_EXPBUF).
Fixes: 436b38fd89fe ("libcamera: Open files with O_CLOEXEC")
Signed-off-by: Elias Naur <mail@eliasnaur.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>
|
|
Move the v4l2-compat.so shared library installation to the libcamera
directory under libexec. This is the same location that the proxy
workers live and will facilitate easier packaging of the V4L2
compatibility layer with distributions.
Create a new libcamera_libexecdir variable within meson to simplify
representation of this path and update the proxy worker meson.build
infrastructure to make use of it as well.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
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>
|
|
The region weights for the the AGC zones are handled by the AGC
algorithm. Apply them directly in the IPA (vc4.cpp) to the statistics
that we pass to the AGC.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
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>
|
|
Create a new IpaBase class that handles general purpose housekeeping
duties for the Raspberry Pi IPA. The implementation of the new class
is essentially pulled from the existing ipa/rpi/vc4/raspberrypi.cpp file
with a minimal amount of refactoring.
Create a derived IpaVc4 class from IpaBase that handles the VC4 pipeline
specific tasks of the IPA. Again, code for this class implementation is
taken from the existing ipa/rpi/vc4/raspberrypi.cpp with a
minimal amount of refactoring.
The goal of this change is to allow third parties to implement their own
IPA running on the Raspberry Pi without duplicating all of the IPA
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>
|
|
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 current IPA build files require a flat directory structure for the
IPAs. Modify the build files to remove this restriction and allow a
directory structure such as:
src/ipa
|- raspberrypi
|- common
|- cam_helpers
|- controller
|- vc4
|- rkisp1
|- ipu3
where each subdir (e.g. raspberrypi/common, raspberrypi/cam_helper) has
its own meson.build file. Such a directory structure will be introduced
for the Raspberry Pi IPA 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>
|
|
Remove the restriction on using the '/' character in the IPA name
string. This allows more flexibility in IPA directory structures where
different IPA modules might live in subdirectories under the usual
src/ipa/<platform>/ top level directory.
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>
|
|
Allow an arbitrary mapping between the pipeline handler and IPA mojom
interface file in the build system. This removes the 1:1 mapping of
pipeline handler name to mojom filename, and allows more flexibility to
pipeline developers.
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 switch statement checks `roles.size()` with cases for 1 and 2,
so in the `default` branch, `role.size() > 2`, i.e. it is always
different from 1, so the check is unnecessary.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@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>
|
|
Bugfixes:
- meson: Ignore -Wredundant-move with gcc-13 and newer
- cam: file_sink: Workaround gcc-13 dangling-reference false positive
- libcamera: Open files with O_CLOEXEC
- meson: Fix git version parsing
- libcamera: camera_manager: Stop exponential explosive calls to createPipelineHandlers
- py: cam: Fix demosaic overflow issue
- libcamera: base: Make the registration of log categories atomic
Core:
- test: controls: control_info_map: Test default constructor
- controls: guard ControlInfoMap against nullptr idmap_
- device_enumerator_udev: Use std::string_view
- formats: Add 14-bits Bayer RAW formats
- device_enumerator_udev: Remove devnum from dependency map
- meson: libcamera: Report IPA signature method
- meson: Align handling of build metadata
- converter: Check converter validity
- Keep using syslog for isolated IPA modules
- utils: ipc: Update parser.py
- utils: checkstyle.py: Don't run commit title checker on staged commits
- framebuffer: Allow inheritance of FrameBuffer
- Remove transform from V4L2SubdeviceFormat
- libcamera: camera_sensor: Add tryFormat()
- camera_sensor: Fix typo in comment
- camera_sensor: Demote flip support message to Debug
- internal: tracepoints: Use correct include directive
- libcamera: camera: Ensure queued requests are invalid
ipa:
- doc: Clarify IPA acronym in its namespace description
- rkisp1: Add tuning files for PinephonePro sensors
- rkisp1: Add tuning files for Google DRU "Scarlet" sensors
- rkisp1: lsc: Fix integer division error
- libipa: Add OV2685 Camera Sensor Helper
- libipa: Add OV5647 Camera Sensor Helper
- raspberrypi: agc: Add "shadows" constraint mode
- raspberrypi: generalise algorithms
- raspberrypi: Fix default frame durations calculation
- raspberrypi: Ensure shutter speed and gain are clipped in the AGC
- raspberrypi: Use the new sensor limits fields in CameraMode
- raspberrypi: Add sensor mode limits to CameraMode
- raspberrypi: Fix crash under LTO
- raspberrypi: imx296: Minor tuning updates
- raspberrypi: agc: Fix overflow in Y value calculation
- raspberrypi: Better heuristics for calculating Unicam timeout
- raspberrypi: Generalise statistics
- raspberrypi: Change Unicam timeout handling
pipeline:
- simple: Validate transform
- imx8-isi: Remove mbusCode from formatsMap_
- imx8-isi: Automatically select media bus code
- imx8-isi: Split Bayer/YUV config generation
- imx8-isi: Break out RAW/YUV format selection
- raspberrypi: Iterate over all Unicam instances in match()
- raspberrypi: Add a Unicam timeout override config options
- raspberrypi: Always use ColorSpace::Raw for raw streams
- raspberrypi: Drop unused code
- ipu3: Drop unused code
apps:
- cam: kms_sink: Drop unique_ptr<> from DRM::AtomicRequest
- cam Return std::optional<> from StreamKeyValueParser::parseRole()
- android: jpeg: Add JEA implementation
ABI Compliance:
* abi-compliance-checker reports 98.6% ABI and 100% API compatibility with
with v0.0.4
Total binary compatibility problems: 1, warnings: 1
Total source compatibility problems: 0, warnings: 0
- First virtual method ~__dt ( ) has been added to this class.
1) The layout of type structure has been shifted by 8 bytes by the added v-table pointer.
2) Size of class has been increased by 8 bytes.
affected symbols: 6 (1.4%)
FrameBuffer::releaseFence ( )
FrameBuffer::setCookie ( uint64_t cookie )
FrameBuffer::cookie ( )
FrameBuffer::planes ( )
FrameBuffer::request ( )
FrameBuffer::metadata ( )
This ABI breakage was introduced by:
4843bfa66dc1 ("libcamera: framebuffer: Allow inheritance of FrameBuffer")
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
A new warning has been introduced to gcc-13 that produces a false
positive on the cam file sink object:
src/cam/file_sink.cpp:92:45: error: possibly dangling reference to a temporary [-Werror=dangling-reference]
92 | const FrameMetadata::Plane &meta = buffer->metadata().planes()[i];
| ^~~~
src/cam/file_sink.cpp:92:81: note: the temporary was destroyed at the end of the full expression '(& buffer->libcamera::FrameBuffer::metadata())->libcamera::FrameMetadata::planes().libcamera::Span<const libcamera::FrameMetadata::Plane>::operator[](i)'
92 | const FrameMetadata::Plane &meta = buffer->metadata().planes()[i];
| ^
cc1plus: all warnings being treated as errors
Workaround this issue by refactoring the code to take a local const
copy of the bytesused value, rather than a local const reference to the
plane.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=185
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107532
Co-developed-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
[Kieran: Commit and comment reworded prior to merge]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Starting from 13.1, gcc implements the C++23 version of automatic move
from local variables in return statements (see
https://en.cppreference.com/w/cpp/language/return). As a result, some
previously required explicit `std::move()` in return statements generate
warnings. This is the case when a function returns an object whose type
is a class derived from the class type the function returns:
struct U { };
struct T : U { };
U f()
{
T t;
return t;
}
Up to C++20, the automatic move from local variables selects the move
constructor of class U, which is not the move constructor of the
expression. Overload resolution is then performed a second time, with t
considered as an lvalue. An explicit `std::move(t)` is needed in the
return statement to select the U move constructor.
Starting from C++23, `t` is treated as an xvalue, and the U move
constructor is selected without the need for an explicit `std::move(t)`.
An explicit `std:move()` then generates a redundant-move warning, as in
the valueOrTuple() function in src/py/libcamera/py_helpers.cpp.
Omitting the `std::move()` silences the warning, but selects the copy
constructor of U with older gcc versions and with clang, which
negatively impacts performance.
The easiest fix is to disable the warning. With -Wpessimizing-move
enabled, the compiler will still warn of pessimizing moves, only the
redundant but not pessimizing moves will be ignored.
Signed-off-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 to the RkISP1 data configuration files for the imx258 and ov8858
sensors found on Pine64 PinephonePro devices.
The tuning file contain LSC tables extracted from the Rockchip Android
BSP the PinephonePro ships with.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Robert Mader <robert.mader@collabora.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add to the RkISP1 data configuration files for the ov2685 and ov5695
sensor found on Google DRU "Scarlett" tablet.
The tuning files contain LSC tables extracted from the Google Chrome
Android HAL configuration files, available at
src/overlays/overlay-scarlet/media-libs/cros-camera-hal-configs-scarlet/files/IQ/
at revision "stabilize-14790.B".
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@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>
|
|
Add a function to the CameraSensor class that allows to test a format
without applying it to the subdevice and without modifying any control
value associated with the camera sensor.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@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>
|
|
Both {Camera,PipelineHandler}::generateConfiguration() take a list
of `StreamRole` objects, and not a list of `StreamRoles` objects.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There is no need to wrap DRM::AtomicRequest in std::unique_ptr<>
in KMSSink::start(). Remove it so that the syntax becomes similar to
what we have in KMSSink::stop().
No functional changes intended.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
ControlInfoMap can be default-constructed. In that case, some of its
members (like idmap_) can be a nullptr, and ControlInfoMap.find() will segfault.
Add a test with a default constructed ControlInfoMap to cover this.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
It's possible to construct a Camera with an unsafe controlInfo_.
This is the case in the Simple pipeline, where the camera controls are
not populated.
With Simple, if we attempt to set a Control, we end up with a segfault
because the default constructor for ControlInfoMap doesn't
intialized idmap_ which is initialized at class declaration time as
const ControlIdMap *idmap_ = nullptr;
Add some safeguards in ControlInfoMap to handle this case.
Link: https://lists.libcamera.org/pipermail/libcamera-devel/2023-April/037439.html
Suggested-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
In `udevNotify()`, constructing an std::string from the device's
associated action is unnecessary as it is only compared against static
strings, and for that purpose an std::string_view works just as well,
while being cheaper to construct.
In the same vein, an std::string_view can be used to store the device's
devnode initially, and the string construction can be deferred until it
is needed.
Furthermore, previously `udev_device_get_devnode()` was called twice.
The extra call is now removed.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add formats definition and mappings for 14-bits Bayer RAW formats.
Add definitions for non-packed and CSI-2 packed variants.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Previously, after `addV4L2Device()` had seen all dependecies, it would
remove the `MediaDeviceDeps` object from the `pending_` list, which
would result in it being destroyed. However, there would still be
(dangling) pointers to this object in `devMap_` that were added in
`addUdevDevice()` (line 103). So remove the entry with the given devnum
when it is removed from the corresponding `MediaDeviceDeps` object.
Signed-off-by: Barnabás Pőcze <pobrn@protonmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The "shadows" constraint mode actually exists in a number of tuning
files, but had been omitted from the list of supported modes.
Signed-off-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: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Make the local mojom library the first priority in the sys path, to
avoid mixing the local one with the system one in build.
Tested on chromebook soraka-libcamera.
Signed-off-by: Harvey Yang <chenghaoyang@chromium.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Clarify IPA's acronym by specifying what "IPA" stands for as part of the
ipa namespaces' "brief" doxygen-generated description. This allows
visitors to the docs to immediately have an idea of the purpose of the
IPA namespace at a glance. Because of the prevalence and importance of
the IPA namespace and functionality, the fact that it stands for "Image
Processing Algorithm" should be accessible to even casual perusers of
the docs.
Signed-off-by: Gabby George <gabbymg94@gmail.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>
|
|
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 previous attempt to fix git version parsing in commit d34cefad1791
("meson: Fix git version parsing") was too naive, and didn't take into
account cases where the libcamera git version contains no or multiple
'+' signs.
Fixing this is more complex than a one-liner change, as meson doesn't
support Python-style slicing of arrays or a length method on strings.
The simplest and most versatile option is to patch the version string in
the gen-version.sh script. Do so, and clarify the comments related to
version handling in meson.build.
Fixes: d34cefad1791 ("meson: Fix git version parsing")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Use the generalised focus statistics structure to compute the centre
window focus FoM value. This avoids needed to hard-code a specific
grid size.
Remove the focus reporting algorithm as the functionality is duplicated
by this bit of IPA code. Remove focus_status.h as it is no longer needed.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
