Stop using v4l2_videodevice::allocateBuffer() for internal buffers and
instead export/import all buffers. This allows the pipeline to return
any stream buffer requested by the application as zero-copy.
Advertise the Unicam Image stream as the RAW capture stream now.
The RPiStream object now maintains a new list of buffers that are
available to queue into a device. This is needed to distinguish between
FrameBuffers allocated for internal use vs externally provided buffers.
When a Request comes in, if a buffer is not provided for an exported
stream, we re-use a buffer from this list.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The ipc_unixsocket.h and process.h internal headers don't need to
include event_notifier.h, the former because a forward declaration
suffices, and the latter because it doesn't use event notifiers. Remove
the unnecessary include, and include signal.h instead which is required
and was included indirectly through event_notifier.h.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
In most cases the last reference to a Camera instance will be the one
held by the CameraManager. That reference gets released when the
CameraManager thread cleans up, just before it stops. There's no need to
delete the camera with deleteLater() in that case.
To optimize this case, use deleteLater() only when the camera gets
deleted from a different thread, and delete is synchronously otherwise.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
When calculating the pipeline configuration for the IPU3 platform,
libcamera tries to be smart and select the smallest sensor frame
resolution large enough to accommodate the stream sizes
requested by the application.
While this makes a lot of sense, in practice optimizing the
selected sensor resolution makes the pipeline configuration calculation
process fail in multiple occasions, or results in stalls during capture.
As a trivial example, capturing with cam with the following command
line results in a stall:
$ cam -swidth=1280,height=720 -swidth=640,height=480 -c1 -C
Likewise, the Android HAL supported format enumeration fails in
reporting smaller resolutions as supported when used with the OV5670
sensor.
320x240:
DEBUG IPU3 ipu3.cpp:192 CIO2 configuration: 648x486-SGRBG10_IPU3
ERROR IPU3 imgu.cpp:408 Failed to calculate pipe configuration
ERROR IPU3 ipu3.cpp:299 Failed to calculate pipe configuration: unsupported resolutions.
640x480:
DEBUG IPU3 ipu3.cpp:192 CIO2 configuration: 320x240-SGRBG10_IPU3
ERROR IPU3 imgu.cpp:408 Failed to calculate pipe configuration
ERROR IPU3 ipu3.cpp:299 Failed to calculate pipe configuration: unsupported resolutions.
Furthermore the reference xml files used for the IPU3 camera
configuration on the ChromeOS platform restricts the number of sensor
resolution to be used for the OV5670 sensor to 2 from the 6 supported by
the driver [1].
The selection criteria of the correct CIO2 mode are not specified, and
for the time being, as a workaround, always use the sensor maximum
resolution at the expense of frame rate and bus bandwidth to allow the
pipeline to successfully support smaller modes for the OV5670 sensor and
solve pipeline stalls when capturing with both sensors.
[1] See the <sensor_modes> enumeration in:
https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/master/baseboard-poppy/media-libs/cros-camera-hal-configs-poppy/files/gcss/graph_settings_ov5670.xml
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Allow disabling compilation of the Android HAL adaptation layer
automatically when a dependency is missing by turning the android option
into a feature. The default value is set to 'disabled' to match the
current behaviour.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
The MediaDevice::setupLink() function fails (ioctl returns EINVAL) when
it passes only the MEDIA_LNK_FL_ENABLE flag to a link that is already
flagged with MEDIA_LNK_FL_ENABLE and MEDIA_LNK_FL_IMMUTABLE. Contrast to
media-ctl's equivalent media_setup_link() which ORs the new flags with
the existing values. Fix this by preserving all flags but
MEDIA_LNK_FL_ENABLED in MediaLink::setEnabled().
Signed-off-by: Dan Scally <djrscally@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>
Improve the device opening at class construction time by testing all
the available device paths and printout the appropriate error message.
While at it, initialize dmaHeapHandle_ to -1 and check for its value
at destruction time.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The default sensor orientation must be set early on in match() to ensure
generateConfiguration() and configure() return out the correct Bayer
ordering to the application. This is particularly important for RAW
capture streams.
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>
We build libcamera with -Wno-unused-parameter and this doesn't cause
much issue internally. However, it prevents catching unused parameters
in inline functions defined in public headers. This can lead to
compilation warnings for applications compiled without
-Wno-unused-parameter.
To catch those issues, remove -Wno-unused-parameter and fix all the
related warnings with [[maybe_unused]].
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Instead of using "delete obj" in the custom deleter of the shared
object, we should have been using the "obj->deleteLater()" to explain
how the deleteLater() API should be used in practice.
Fixes: 9558886f7a ("libcamera: object: Add deleteLater() support)
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Add a version of cameraData() that returns a const pointer and mark it
as a const operation. The assert in the non-const version of the
function already enforces that a std::map::at() operation would always
succeed so there is no change in operation from the non-const version.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
The Stream pointer just acts as a key in the Request object. There is no
good use-case to modify a stream from a pointer retrieved from the
Request, make it const. This allows pipeline handlers to better express
that the Stream pointer is retrieved in a Request should just be treated
as a key.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Declare a using directive for the map of Stream to FrameBuffer. Update
all users of Request::buffers() to use the new usage directive.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
When switching from V4L2 to DRM pixel formats V4L2_PIX_FMT_GREY was
dropped form the list of supported formats but the arrays size was never
decreased, fix this.
Fixes: 448716d8f7 ("libcamera: Switch PixelFormat to DRM FourCC values")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Provide a MappedFrameBuffer helper class which will map
all of the Planes within a FrameBuffer and provide CPU addressable
pointers for those planes.
The MappedFrameBuffer implements the interface of the MappedBuffer
allowing other buffer types to be constructed of the same form, with a
common interface and cleanup.
This allows MappedBuffer instances to be created from Camera3Buffer types.
Mappings are removed upon destruction.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Update the remaining (capitalised) Buffer references to the new FrameBuffer
object that they refer to.
Lower-case 'buffer' terms are kept, as a generic reference to a buffer
rather than the specific type 'FrameBuffer'.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Rename Camera::name() to camera::id() to better describe what it
represents, a unique and stable ID for the camera. While at it improve
the documentation for the camera ID to describe it needs to be stable
for a camera between resets of the system.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Generate camera names that are unique and persistent between system
resets. The name is constructed from the USB device information as well
as the USB controller on the host.
Before this change example of camera names:
Venus USB2.0 Camera: Venus USB2
Logitech Webcam C930e
After this change the same cameras are:
\_SB_.PCI0.RP05.PXSX-2.1.1:1.0-0ac8:3420
\_SB_.PCI0.RP05.PXSX-2.4:1.0-046d:0843
On OF-based system:
/base/soc/usb@7e980000/usb-port@1-1.2:1.0-0ac8:3420
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Use the CameraSensor ID as the camera name in pipelines that uses a
CameraSensors, this is done in preparation of turning the camera name
into an ID. The CameraSensor ID meets the requirements that will be put
on camera ID.
Before this change example of camera names:
* OF based systems
ov5695 7-0036
ov2685 7-003c
* ACPI based systems
ov13858 8-0010
ov5670 10-0036
* VIMC
VIMC Sensor B
After this change the same cameras are:
* OF based systems
/base/i2c@ff160000/camera@36
/base/i2c@ff160000/camera@36
* ACPI based systems
\_SB_.PCI0.I2C2.CAM0
\_SB_.PCI0.I2C4.CAM1
* VIMC
platform/vimc.0 Sensor B
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
The ID is generated from information in the firmware description of the
sensor if available or from module and model information if the sensor
is virtual (for example VIMC).
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
A system's firmware description is recorded differently in sysfs
depending if the system uses DT or ACPI. Add a helper to abstract
this, allowing users not to care which of the two are used.
For DT-based systems, the path is the full name of the DT node that
represents the device. For ACPI-based systems, the path is the absolute
namespace path to the ACPI object that represents the device. In both
cases, the path is guaranteed to be unique and persistent as long as the
system firmware is not modified.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
GCC5 does not provide prototypes for the math library functions defined
in the math.h header for the std:: namespace.
Include the C++ <cmath> header in place of <math.h> as it defines
overloads for the std::abs and std::fmod function.
This goes intentionally against the libcamera coding guidelines, and
is reported as warning by checkpatch.py.
Fixes: 968ab9bad0 ("libcamera: ipu3: imgu: Calculate ImgU pipe configuration")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
The ImgUDevice::configureInput() function does not only configure the
input format but applies rectangles to the IF, BDS and GDC components.
Rename it to ImgUDevice::configure().
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Instrument the ImgUDevice::configureInput() function to use the provided
pipe configuration parameters to configure the IF, BDS and GDC
rectangles.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Collect the desired ImgU pipe configuration while assigning
streams in the pipeline handler validate() function and ask the
ImgUDevice class to calculate the pipe configuration parameters.
If the requested pipe configuration results in a non-valid
configuration, return an error from the validate() function.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Naushir Patuck
Laurent Pinchart
Jacopo Mondi
Niklas Söderlund
Umang Jain
Dan Scally
Kieran Bingham
Kaaira Gupta