| Age | Commit message (Collapse) | Author |
|---|
|
Provide the request SensorTimestamp as the buffer completion time. This
is fake, as there is no SensorTimestamp on the VIVID pipeline as it's a
virtual video device, but it provides a suitable data point.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
In case the setFormat() call on the video device fails to match the
configuration, print both the requested and actual configurations to
ease debugging.
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>
|
|
Initialize the CameraData properties with Location and Model.
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>
|
|
When constructing the camera, we parse the available controls on the
video capture device, and map supported controls to libcamera controls,
and initialise the defaults.
The controls are handled during queueRequestDevice for each request and
applied to the device through the capture node.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The VIVID pipeline handler retains state globally of it's controls.
Ensure that when we configure this specific pipeline we set initial
parameters on the device that suit our (specific) needs.
This introduces how controls can be set directly on a device, however
under normal circumstances controls should usually be set from libcamera
controls as part of a request. These are VIVID specific only.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When a request is given to a pipeline handler, it must parse the request
and identify what actions the pipeline handler should take to enact on hardware.
In the case of the VIVID pipeline handler, we identify the buffer from the only
supported stream, and queue it to the video capture device.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
We can now add buffer management, and connect up our bufferReady signal
to a callback.
Note that we provide the ability to export buffers from our capture
device (data->video_) using the exportBuffers() functionality from the
V4L2VideoDevice which allows a FrameBufferAllocater to obtain buffers
from this device.
When buffers are obtained through the exportFrameBuffers API, they are
orphaned and left unassociated with the device, and must be reimported
at start() time anyway. This allows the same interface to be used
whether internal buffers, or external buffers are used for the stream.
When a buffer completes, we call the buffer completion handler on the
pipeline handler, and because we have only a single stream, we can also
immediately complete the request.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
When the configurations have been generated and validated, they can be
applied to a device.
Vivid supports only a single stream, so it directly obtains the first
StreamConfiguration from the CameraConfiguration.
The VIVID catpure device is a V4L2Video device, so we generate a
V4L2DeviceFormat to apply directly to the capture device node.
Note that we convert the libcamera Format stored in
cfg.pixelFormat to a V4L2PixelFormat using V4L2PixelFormat helper. This
currently defaults to the single-planar formats, and should be extended
to support the Multiplanar configuration from the V4L2Device.
[todo Repair the link between the multiplanar configuration of the
V4L2VideoDevice and the pixel format selection]
Following the call to set the format using the Kernel API, if the format
has been adjusted in any way by the kernel driver, then we have failed
to correctly handle the validation stages, and thus the configure
operation is idendified has having failed.
Finally stream specific data can be directly stored and set as
reflecting the state of the stream.
[NOTE: the cfg.setStream() call here associates the stream to the
StreamConfiguration however that should quite likely be done as part of
the validation process. TBD]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Implement the support for Generating and Validating the streams the
Camera can provide.
Vivid is a simple case with only a single stream.
Test the configurations can be generated and reported with cam -I:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -c 1 -I
[232:02:09.633067174] [2882911] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home//libcamera/build-vivid/src/ipa' to the IPA search path
[232:02:09.633332451] [2882911] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[232:02:09.633373414] [2882911] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+714-d1ebd889-dirty
Using camera vivid
0: 1280x720-BGR888
* Pixelformat: NV21 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: NV12 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: BGRA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
* Pixelformat: RGBA8888 (320x180)-(3840x2160)/(+0,+0)
- 320x180
- 640x360
- 640x480
- 1280x720
- 1920x1080
- 3840x2160
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Create a VividCameraData inheriting from the CameraData to handle camera
specific data, and use it to create and register the camera with the
CameraManager.
This can now be tested to see that the camera becomes available to
applications:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
[231:44:49.325333712] [2880028] INFO IPAManager ipa_manager.cpp:136 libcamera is not installed. Adding '/home/libcamera/build-vivid/src/ipa' to the IPA search path
[231:44:49.325428449] [2880028] WARN IPAManager ipa_manager.cpp:147 No IPA found in '/usr/local/lib/x86_64-linux-gnu/libcamera'
[231:44:49.325446253] [2880028] INFO Camera camera_manager.cpp:283 libcamera v0.0.11+713-d175334d-dirty
Available cameras:
1: vivid
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Verify that we can match on our expected device(s).
Use a temporary debug print to check that the pipeline finds
our device:
"""
LIBCAMERA_LOG_LEVELS=Pipeline,VIVID:0 ./src/cam/cam -l
<snipped>
[230:51:10.670503423] [2872877] DEBUG VIVID vivid.cpp:81 Obtained Vivid Device
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Explicitly disable the unused-parameter warning in this pipeline handler.
Parameters are left unused while they are introduced incrementally, so for
documentation purposes only we disable this warning so that we can compile
each commit independently without breaking the flow of the development
additions.
This is not recommended practice within libcamera, please listen to your
compiler warnings.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Provide all of the skeleton stubs to succesfully compile
and register a new Pipeline Handler for the Vivid test device.
Meson must be reconfigured to ensure that this pipeline handler is
included in the selected pipelines configuration, and after building, we
can test that the PipelineHandler is successfully registered by listing
the cameras on the system with LIBCAMERA_LOG_LEVELS enabled:
"""
LIBCAMERA_LOG_LEVELS=Pipeline:0 ./build-vivid/src/cam/cam -l
[230:30:03.624102821] [2867886] DEBUG Pipeline pipeline_handler.cpp:680 Registered pipeline handler "PipelineHandlerVivid"
Available cameras:
"""
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Drop libcamera_private dependency entirely as to avoid libcamerasrc
getting more dependent on it. In order to achieve that, one of the
mutex locks in GstLibcameraSrcState needs to be replaced with GMutex.
However doing so, this won't let us to use the clang's thread annotation
macros in libcamera (which should be fine as libcamerasrc would move
out of libcamera repo once matured).
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
Pipeline handlers can have custom dependencies.
Allow each pipeline handler subdir to add them to libcamera_deps[].
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If a user provided pipeline config file is not present, or if the
version reported in the file is invalid, do not return with an error
when creating the pipeline handler. Instead, log a warning message and
return success with default pipeline config values used.
This now matches the behaviour when the pipeline config file could not
be parsed correctly, and we revert to default values.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
|
|
In commit 0ee9339331c6, a default metering/exposure/constraint mode is
used if a control sets a mode that is not listed in the camera tuning
file.
Setting a default mode may be undesirable in these cases, so instead
keep the agc mode unchanged. This also matches the behaviour for other
IPA controls where no changes are made in error conditions.
Fixes: 0ee9339331c6 ("ipa: rpi: agc: Gracefully handle missing agc modes")
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
|
|
As the CameraSensor::validateTransform() function compensate
for the sensor's mounting rotation, the properties::Rotation value
should be adjusted to make sure application that receive already
"corrected" images do not get confused by Rotation still reporting
a value.
Howerver, as an image sensor can only compensate rotations by applying
H/V flips, only correct Rotation when the mounting rotation is 180
degrees.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Cameras such as the PiCam 3 support auto-focus, but the GStreamer plugin
for libcamera does not enable auto-focus. With this patch auto-focus can
be enabled for cameras that support it. By default it is disabled, which
means default behaviour remains unchanged. For cameras that do not
support auto-focus, an error message shows up if auto-focus is enabled.
This was tested on cameras that do not support auto-focus (e.g. PiCam2)
and was tested on a camera that does support auto-focus (PiCam3). The
test involved setting the focus to AfModeContinous and observing it.
However, by not setting "auto-focus-mode" or using AfModeManual as
the "auto-focus-mode" both resulting in auto-focus being disabled.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=188
Signed-off-by: Cedric Nugteren <cedric@plumerai.com>
Reviewed-by: Maarten Lankhorst <dev@lankhorst.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Tested-by: Umang Jain <umang.jain@ideasonboard.com>
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Register the identified device numbers with each camera as the
SystemDevices property.
This facilitates camera daemons or other systems to identify which
devices are being managed by libcamera, and can prevent duplication of
camera resources.
As the SystemDevices property now provides this list of devices, use it
directly from within the CameraManager when adding a Camera rather than
passing it through the internal API.
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.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>
|
|
Provide a new Camera property that allows pipeline handlers to list any
kernel device used to operate the camera. This allows other frameworks
and daemons such as PipeWire to better understand the resources consumed
by a Camera and consider ignoring those resources when enumerating
camera devices on a system.
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.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>
|
|
The CameraManager exposes addCamera and removeCamera as public API
calls, while they should never be called from an application. These
calls are only expected to be used by PipelineHandlers to update the
CameraManager that a new Camera has been created and allow the Camera
Manager to expose it to applications.
Remove the public calls and update the private implementations such that
they can be used directly by the PipelineHandler through the internal
CameraManager::Private provided by the Extensible class.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The CameraManager makes use of the Extensible pattern to provide an
internal private implementation that is not exposed in the public API.
Move the Private declaration to an internal header to make it available
from other internal components in preperation for reducing the surface
area of the public interface of the CameraManager.
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Tested-by: Ashok Sidipotu <ashok.sidipotu@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
If a metering/exposure/constraint mode is not listed in the sensor
tuning file, and a control for the missing mode is set on the agc, we
terminate the application with a fatal log message.
Instead of this fatal termination, log a warning message and switch to
the appropriate default mode so that the application continues running.
Bug: https://github.com/raspberrypi/libcamera/issues/59
Bug: https://github.com/ayufan/camera-streamer/issues/67
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Replace the char array strings in struct AgcStatus with std::string
objects. This simplifies the string handling in the source code.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Some sensor tuning files were missing the short and/or long exposure
mode profiles. Add the missing items to the relevant files.
As a drive-by, rename the "sport" exposure profile to "short" for the
IMX290 tuning.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The current implementation enumerates a single RAW format (the sensor's
resolution) and does that regardless of what role the
CameraConfiguration has been generated for.
Fix this by:
- Enumerate RAW StreamFormats only when the requested role is
StreamRole::Raw
- Add all the sensor's provided resolutions that fit the video device
output maximum size
Before this patch, a single RAW size was enumerated in stream formats
* Pixelformat: SRGGB10 (4208x3120)-(4208x3120)/(+1,+1)
- 4208x3120
With this patch applied all sensor's supported resolutions are
enumerated but only when the stream role RAW is explicitly requested
* Pixelformat: SRGGB10 (1048x780)-(4208x3120)/(+0,+0)
- 1048x780
- 2104x1560
- 4032x3024
- 4208x3120
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Currently each RkISP1 path (main and self) generate a configuration
by bounding the sensor's resolution to their respective maximum output
aspect ratio and size.
Size maxResolution = maxResolution_.boundedToAspectRatio(resolution)
.boundedTo(resolution);
In the case of self path, whose maximum size is 1920x1920, the generated
configuration could get assigned unusual sizes, as the result of the
above operation.
As an example, with the imx258 sensor whose resolution is 4208x3118, the
resulting size for the Viewfinder use case is an unusual 1920x1423.
Fix this by assigning to each role a desired output size:
- Use the sensor's resolution for StillCapture and Raw
- Use 1080p for Viewfinder and VideoRecording
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Crop on the resizer sink pad before downscaling to the aspect ratio
of the desired output size.
Cropping the input frame to the output aspect ratio allows to maintain
the correct picture proportions, as otherwise downscaling would change
the image geometry.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The generateConfiguration() implementation in the Rockchip RkISP1
pipeline handler uses by default the self path (if available) for
the Viewfinder and VideoRecording StreamRoles.
The validate() implementation, at the contrary, prefers using the main
path, when available, for all streams.
As the self-path is limited in output resolution to 1920x1920,
generating a configuration using the self path limits the maximum
stream size to 1920x1920, while higher resolutions can be obtained by
using the main path.
Align the generateConfiguration() implementation to the validate() one
by using the main path by default if available.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=180
Reported-by: libcamera@luigi311.com
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>
|
|
On the first ipa->configure() call, set the lens position (if a lens is
present) to the default position. Typically this would be the hyperfocal
position based on the tuning data.
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>
|
|
In addition to sensor controls, return lens controls from
IpaBase::configure() back to the pipeline handler. If there are lens
controls present in the ControlList, action them in the pipeline handler
as part of the configure routine.
Signed-off-by: Naushir Patuck <naush@raspberrypi.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>
|
|
Update the AfMode control description to explicitly define a
startup/default behaviour.
On startup, the camera will move the lens to the position given by the
default value of the LensPosition control if operating in manual focus
mode. Typically this would be the hyperfocal position of the lens.
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>
|
|
Commit a3178dd0391f ("ipa: rkisp1: agc: drop hard-coded analogue gain range")
removed both minimum and maximum limits for the analogue gain value.
However, as some sensors can potentially have a minimum gain lower than
1.0, restore the check for the minimum limit.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
As the sensor's analogue gain range is known, drop the arbitrary
maximum limit for the sensor analogue gain.
Signed-off-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Tested-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The addition of the CameraSensorHelperImx327 class was not correctly
inserted in alphabetical sort order.
Move it to the correct location.
Fixes: 7d5b38e2ef41 ("libipa: camera_sensor_helper: Add IMX327 helper")
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.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>
|
|
The controls relates to the public API, which doesn't expose IPA modules
as they are internal to libcamera. Replace the mention of "IPA" in the
controls documentation.
While at it, fix a small text reflow issue.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Do not advertise colour related controls (i.e. [A]WB, colour saturation)
in the ControlInfoMap of available controls returned out to the
application.
Silently ignore these controls in the control handler in case applications
don't use the advertised ControlInfoMap to validate controls.
As a drive-by fix, don't advertise controls::ColourCorrectionMatrix in
the ControlInfoMap as it is not handled by the IPA.
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 a new cfaPattern field to the IPACameraSensorInfo to pass the
CFA/Bayer pattern for the current sensor configuration to the IPA.
This field takes a value from properties::draft::ColorFilterArrangementEnum.
Populate cfaPattern in CameraSensor::sensorInfo(), called by the
pipeline handler before it calls ipa->init() and ipa->config().
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>
|
|
Fix code formatting.
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>
|
|
Update the noise profile and reference lux level with newly taken
calibration pictures. Remove GEQ/cross-talk processing block as this is
a mono sensor.
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>
|
|
We are using pybind11 'smart_holder' branch to solve the Camera
destructor issue (see the comment in this patch, or the commit
that originally added Python bindings support).
As it would be very nice to use the mainline pybind11 (which is packaged
in distributions), this patch adds a workaround allowing us to move to
the mainline pybind11 version.
The workaround is simply creating a custom holder class
(PyCameraSmartPtr), used only for the Camera, which wraps around the
shared_ptr. This makes the compiler happy.
Moving to mainline pybind11 is achieved with:
- Change the pybind11 wrap to point to the mainline pybdind11 version
- Tell pybind11 to always use shared_ptr<> as the holder for
PyCameraManager, as we use the singleton pattern for the
PyCameraManager, and using shared_ptr<> to manage it is a requirement
- Tell pybind11 to always use PyCameraSmartPtr<> as the holder for Camera
- Change the meson.build file to use a system-installed pybind11
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>
|
|
We have multiple methods which return an error code, mimicking the C++
API. Using exceptions is more natural in the Python API, so change all
those methods to raise an Exception instead.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Move ColorSpace and Transform classes to separate files from the main
py_main.cpp, for clarity.
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>
|
|
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>
|
