Age | Commit message (Collapse) | Author |
|
QUERYBUF
QUERYBUF doesn't require the memory field to be pre-filled.
Also, V4L2VideoDevice::createBuffer uses dmabuf file descriptors, thus
using V4L2_MEMORY_MMAP makes things confusing, so remove it.
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The current logging to track the status of a Request when running the
Android camera HAL provide the following information:
When a Request is queued to libcamera:
HAL camera_device.cpp:1776 '\_SB_.PCI0.I2C2.CAM0': Queueing Request to libcamera with 1 HAL streams
When a Request completes:
Request request.cpp:268 Request has completed - cookie: 138508601719648
The queueing of a Request reports the number of streams it contains
while the completion of a Request reports the address of the associated
cookie.
This makes very hard to keep track of what Requests have completed, as
the logging associated with a queue/complete event does not allow to identify
a Request easily.
Add two more printouts to make it easier to track a Request life cycle.
To make it possible to print the Request cookie in the CameraDevice
class add a method to access it from the CameraRequest class.
The result looks like the following trace:
Request request.cpp:92 Created request - cookie: 140701719392768
HAL camera_device.cpp:1710 '\_SB_.PCI0.I2C2.CAM0': Queueing request 140701719392768 with 1 streams
HAL camera_device.cpp:1747 '\_SB_.PCI0.I2C2.CAM0': 0 - (4160x3104)[0x00000023] -> (4160x3104)[NV12] (direct)
...
Request request.cpp:268 Request has completed - cookie: 140701719392768
HAL camera_device.cpp:1800 '\_SB_.PCI0.I2C2.CAM0': Request 140701719392768 completed with 1 streams..
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The function declaration fits on one line.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
This new format corresponds to the V4L2 V4L2_PIX_FMT_RGB565X format, and
is the big-endian version of the DRM_FORMAT_RGB565 format.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
When moving the pipeline away from the Timeline design it was discovered
that the design of queuing the buffers to the device as soon as possible
was not the best idea. The parameter buffers were queued to the device
before the IPA had processed them and this violates the V4L2 API.
Fix this by waiting to queue any buffer to the device until the IPA has
filled in the parameters buffer.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
There are no users left of the Timeline and there is no longer a need to
keep emulating a start of exposure event as the CSI-2 resciver reports
it. Remove the Timeline helper and what's left of it's integration in
the pipeline.
There is no functional change as nothing i the pipeline uses the
Timeline.
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>
|
|
In the Timeline approach the idea was to delay queuing buffers to the
device until the IPA had a chance to prepare the parameters buffer. A
check was still added to warn if the IPA queued buffers before the
parameters buffer was filled in.
This check happened much sooner then needed as the parameter buffers
does not have to be ready when the buffer is queued but just before it's
consumed. As the pipeline now has true knowledge of each SOF we can move
the check there and remove the delaying of queuing of buffers.
This change really speeds up the IPA reactions as the delays used in the
Timeline where approximated while with this change they are driven by
events reported by the device.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Instead of setting controls using the RkISP1 local Timeline helper use
the DelayedControls. The result is the same, the controls are applied
with a delay.
The values of the delays are however different between the two methods.
The values used in the Timeline solution were chosen after some
experimentation and the values used in DelayedControls are taken from a
generic sensor. None of the two are a perfect match as the delays can be
different for different sensors used with the pipeline.
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>
|
|
Expose the device backing the CameraSensor instance.
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>
|
|
There are no users left, remove it.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Use the libcamera core helper DelayedControls instead of the local
StaggeredCtrl. The new helper is modeled after the StaggeredCtrl
implementation and behaves the same.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Some sensor controls take effect with a delay as the sensor needs time
to adjust, for example exposure. Add an optional helper DelayedControls
to help pipelines deal with such controls.
The idea is to provide a queue of controls towards the V4L2 device and
apply individual controls with the specified delay with the aim to get
predictable and retrievable control values for any given frame. To do
this the queue of controls needs to be at least as deep as the control
with the largest delay.
The DelayedControls needs to be informed of every start of exposure.
This can be emulated but the helper is designed to be used with this
event being provide by the kernel through V4L2 events.
This helper is based on StaggeredCtrl from the Raspberry Pi pipeline
handler but expands on its API. This helpers aims to replace the
Raspberry Pi implementations and mimics it behavior perfectly.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
|
|
Report in the Request metadata the scaler crop region as requested by
application through the request controls. No actual scaling is applied
in the pipeline at the moment.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Register the ScalerCrop control in the ImgU pipeline handler computed
by using the Viewfinder [1280x720] pipeline output configuration and
the sensor resolution as parameters.
The ScalerCrop control limits should be updated every time a new
configuration is applied to the sensor.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Calculate the controls::Exposure limits at camera registration time
and register it in the list of camera supported controls.
Cache the default exposure value to report it in the request metadata.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add the V4L2_CID_EXPOSURE control to the list of mandatory controls the
sensor driver has to report and document this new requirement.
While at it, re-sort the mandatory V4L2 controls in alphabetical
order in the CameraSensor class and remove the above comment as
the usage of the controls is better reported in the documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The current CameraSensor interface for reading and writing controls
is currently based on V4L2 controls.
Mention that more clearly in the documentation and, while at it, re-sort
the documentation to match the methods declaration order.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add support for setting V4L2_CID_VBLANK appropriately when setting
V4L2_CID_EXPOSURE. This will allow adaptive framerates during
viewfinder use cases (e.g. when the exposure time goes above 33ms, we
can reduce the framerate to lower than 30fps).
The minimum and maximum frame durations are provided via libcamera
controls, and will prioritise exposure time limits over any AGC request.
V4L2_CID_VBLANK is controlled through the staggered writer, just like
the exposure and gain controls.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.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>
|
|
Add an int64_t array control (controls::FrameDurations) to specify the
minimum and maximum (in that order) frame duration to be used by the
camera sensor.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.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>
|
|
The VIMC driver does not yet support all the features required
for all sensor drivers. As it is the main testing platforms and the
driver changes might take a long time to land in the developments
and testing platforms, temporary close the gap by skipping driver
validation and initializing properties with static information such
as the sensor resolution.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a const version of the MediaObject::dev() method to be able to
retrieve a pointer to a const MediaDevice from a constant instance of
a MediaObject sub-class.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Initialize the pixel array properties in the UVC pipeline handler as
they're now initialized in the CameraSensor class, which the UVC
pipeline handler does not use.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The 'rotation' property is not critical. Only register it if the
sensor driver reports it.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
If the sensor driver does not report the camera location default it
to 'External' instead of 'Front'.
As the camera location is used to construct the camera unique name
presented to the user, it makes more sense to report multiple 'External'
cameras instead of multiple 'Front' ones.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
As support for the V4L2_SEL_TGT_CROP selection target used to read the
sensor analogue crop rectangle is schedule to become mandatory but is
still optional, use the sensor's active area size as fallback value to
allow the creation of the CameraSensorInfo in the case the driver does
not support it.
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Support for the V4L2 selection API is currently optional in the
CameraSensor class. Properties registered by using values read through
that API are defaulted in several different places (the Android camera
HAL or the CameraSensor class).
In the future support for the selection API will be made mandatory, but to
give time to sensor drivers in all test platforms to be updated, use
sensor resolution as fallback values for sensor pixel array properties
and cache them as class member variables.
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>
|
|
The CameraSensor class requires the sensor driver to report
information through V4L2 controls and through the V4L2 selection API,
and uses that information to register Camera properties and to
construct CameraSensorInfo class instances to provide them to the IPA.
Currently, validation of the kernel support happens each time a
feature is requested, with slighly similar debug/error messages
output to the user in case a feature is not supported.
Rationalize this by validating the sensor driver requirements in a
single function
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The scope of File::exists() was changed to only validate that a file
exists and is therefore not usable to check if a directory exists. This
breaks the persistent name generation for DT based systems as it uses
File::exists() to check for directories, fix this by using stat()
directly.
On Scarlet the persistent names of the cameras are impacted by this and
where incorrectly reported as:
$ cam -l
Available cameras:
1: Internal front camera (platform/ff160000.i2c/i2c-7/7-003c ov2685)
2: Internal front camera (platform/ff160000.i2c/i2c-7/7-0036 ov5695
While the expected ones are restored with this fix:
$ cam -l
Available cameras:
1: Internal front camera (/base/i2c@ff160000/camera@3c)
2: Internal front camera (/base/i2c@ff160000/camera@36)
Fixes: 8f4e16f014c820a0 ("test: file: Check that directories are not treated as files")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
On the bail out path, always ensure that ImgU and CIO2 are stopped
before freeing the buffers. V4L2VideoDevice class guarantees that
calling stop() without having to call start() is harmless, hence use
this guarantee to simplify error paths.
Signed-off-by: Umang Jain <email@uajain.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Track the state of streamon/streamoff calls to simplify error paths.
Ensuring that streamOff() can be called on non-streaming streams
facilitates simpler error code paths, where a set of devices can all
call streamOff regardless of their initialisation state.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Umang Jain <email@uajain.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>
|
|
s/chance/change/
Signed-off-by: Sebastian Fricke <sebastian.fricke.linux@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Ensure that when we check for existence with File() it will only return
if the path leads to a file, and not a directory.
Device nodes which could still be opened by this class are still
supported.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Inspect the list of media bus codes supported by the camera sensor
in order to deduce the color filter arrangement and register the
ColorFilterArrangement draft property.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The existing implementation of the BayerFormat class supports
converting a V4L2PixelFormat to a BayerFormat and vice-versa.
Expand the class by adding support for converting a media bus code
to a BayerFormat instance, by providing a conversion table and a
dedicated static methods.
Do not provide support for converting a BayerFormat to a media bus code
as there's no 1-to-1 mapping between the two.
Reviewed-by: Paul Elder <paul.elder@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>
|
|
Define the 'ColorFilterArrangement' draft property. The property is
currently identical to ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
There are no users left of this field, drop it.
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>
|
|
There is no need to pass the Camera pointer to queueRequest(),
completeBuffer() and completeRequest() as the Request also passed
contains the same information. Remove the Camera argument to avoid
situations where the information in the Request and the argument differ.
There is no functional change and no public API change as the interface
is only used between the Camera and PipelineHandler.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Remove the unused configs_ member variable in SimpleCameraData.
Signed-off-by: Phi-Bang Nguyen <pnguyen@baylibre.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
The Doxygen documentation for enumerators of the ConnectionType
enumeration prefixes the enumerator name with the enumeration name. For
unscoped enumerations, this is incorrect. Drop the scope. This fixes
warnings produced by Doxygen when multiple enumerators with identical
names are defined in different scopes.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
This control reports the global digital gain applied by the pipeline
as a whole, after capturing a raw image from the sensor.
Signed-off-by: David Plowman <david.plowman@raspberrypi.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>
|
|
The initLinks() and createCamera() methods are declared but never
defined. Remove them.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Replace manual resource destruction with std::unique_ptr<> where
applicable. This removes the need for several destructors.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Replace manual construction of V4L2VideoDevice and V4L2Subdevide with
the fromEntityName() helper where possible. The returned pointer is
managed as a std::unique_ptr<>, which simplifies the VimcCameraData
destructor.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
The CameraSensor instance stored in RPiCameraData::sensor_ is allocated
dynamically and never deleted. Fix the memory leak by storing it in a
std::unique_ptr<>.
Fixes: 740fd1b62f67 ("libcamera: pipeline: Raspberry Pi pipeline handler")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
C++17 has a std::size() function that returns the size of a C-style
array. Use it instead of the custom ARRAY_SIZE macro.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <email@uajain.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
configure
The number of frames to drop (not display) is passed back now from the
start method, not configure. This means applications have a chance to
set fixed exposure/gain before starting the camera and this can affect
the frame drop count that is returned.
Note how we need to be able to tell the very first time we start the
camera from subsequent restarts, hence addition of the "firstStart_"
flag.
Both the IPA implementation file and the pipeline handler need
matching modifications.
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>
|
|
Camera::start
The ScalerCrop control is handled by the pipeline handler, not the
IPA, so must be handled explicitly in the Camera::start method. The
ScalerCrop code used when processing requests has been factored out to
make it easy to reuse.
Signed-off-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 fromEntityName() function returns a pointer to a newly allocated
V4L2Device instance, which must be deleted by the caller. This opens the
door to memory leaks. Return a unique pointer instead, which conveys the
API semantics better than a sentence in the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The fromEntityName() function returns a pointer to a newly allocated
V4L2Subdevice instance, which must be deleted by the caller. This opens
the door to memory leaks. Return a unique pointer instead, which conveys
the API semantics better than a sentence in the documentation.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Forward any controls passed into the pipeline handler to the IPA.
The IPA then sets up the Raspberry Pi controller with these settings
appropriately, and passes back any V4L2 sensor controls that need
to be applied.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|