| Age | Commit message (Collapse) | Author |
|---|
|
The meson custom_target() function accepts a 'depend_files' argument to
list additional dependency files. Files already listed in the 'command'
argument are handled automatically, and don't need to be added manually.
Drop them.
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>
|
|
The meson.build files mix array declarations with and without a space
after the opening and before the closing square bracket. The vast
majority of cases don't use spaces, so standardize on that.
While it it, fix indentation in a few places.
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 preparation for fast colour denoise, set the low resolution ISP
output stream (Output1) to a 1/4 resolution of the application requested
stream (Output0). This only happens if the application has not requested
an additional YUV or RGB stream.
We also constrain this 1/4 resolution to at most 1200 pixels in the
largest dimension to avoid being too taxing on memory usage and system
bandwidth.
Also switch the default StreamRole::VideoRecording to YUV420 to allow
fast colour denoise to run.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-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>
|
|
Refactor the high/low resolution stream format and output selection
routine. This change is in preparation of adding 1/4 resolution output
for fast colour denoise.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-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>
|
|
Buffers dequeued from the ImgU may not be associated with a Request as
they are internal (statistics, parameters and some RAW buffers). Fetch
the request they are used for from the frame information instead.
Fixes: 9708f49fecf2f9ee ("libcamera: ipu3: Share parameter and statistic buffers with IPA")
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Commit 7208e70211a6 ("libcamera: ipu3: Always use sensor full frame size")
changed the CIO2 configuration procedure to always select the full
sensor resolution to work around an ImgU configuration issue, as
reported in the todo item introduced in said commit.
When capturing a RAW stream only and the ImgU is not involved, the CIO2
has to be configured with the requested stream size to avoid adjusting
the stream to the sensor resolution.
As an example, capturing a raw frame smaller than the sensor resolution
with this patch applied results in the stream configuration to be
correctly assigned.
$ cam -c1 -swidth=1056,height=784,role=raw
ipu3.cpp:207 CIO2 configuration: 1056x784-SGRBG10_IPU3
ipu3.cpp:222 Validating stream: 1056x784-SGRBG10_IPU3
ipu3.cpp:233 Assigned 1056x784-SGRBG10_IPU3 to the raw stream
Without this patch the same operation results in the stream resolution
to be adjusted to the sensor resolution.
$ cam -c1 -swidth=1056,height=784,role=raw
ipu3.cpp:201 CIO2 configuration: 4224x3136-SGRBG10_IPU3
ipu3.cpp:216 Validating stream: 1056x784-SGRBG10_IPU3
ipu3.cpp:227 Assigned 4224x3136-SGRBG10_IPU3 to the raw stream
ipu3.cpp:297 Stream 0 configuration adjusted to 4224x3136-SGRBG10_IPU3
Camera configuration adjusted
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>
|
|
Report the crop region for every completed request.
The crop region is initialized as the sensor's analogue crop
rectangle and updated when a Request with a new region completes.
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>
|
|
Use the IPU3Frames helper to share parameters and statistics buffers
with the IPA. Track which parameter and statistic buffer is used for
which request and make sure the parameter buffers is filled in by the
IPA before it's needed and that the statistic buffer is consumed and
meta data generated before completing the request.
With this change the IPU3 pipeline is prepared to fully operate with an
IPA component.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a helper class to aid in associating a parameter and statistic
buffer with each request queued to the pipeline. The helper helps with
tracking the state of the extra buffers and in completing the request
once all extra processing is done.
This change only adds the helper more work is needed to integrate it
with the pipeline and an IPA.
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>
|
|
Map and unmap the parameters and statistic buffers in the IPA when the
pipeline handler allocates and frees the buffers.
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>
|
|
Instead of preparing for buffer importing allocate buffers that can be
used by an IPA.
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>
|
|
Attach to the IPA and allow it to push V4L2 controls that apply to the
camera sensor. The IPA is not fully integrated in the pipeline as
statistics and parameters buffers are not yet allocated, processed by
the IPA nor queued to the hardware.
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>
|
|
Propagate the frameStart event whenever the CSI-2 receiver in the CIO2
pipeline generates one.
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>
|
|
When adding IPA plumbing to the IPU3 pipeline handler it will be needed
to track which raw buffer was queued to the CIO2 for a specific request.
Currently if using an internally allocated raw buffer the FrameBuffer is
not exposed outside the CIO2Device as it was not needed. Prepare for the
IPA by exposing which internal raw buffer is picked for each request,
later changes will associate this with a Request.
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>
|
|
Add the parameters video device to the data structure of the ImgUDevice.
Even if the video device is configured, prepared to import buffers and
started no buffers are ever queued to it so it does not yet effect the
capture. Nor is does this change hinder the current capture mode to
function.
This is done in preparation to attach an IPA to the IPU3 pipeline.
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>
|
|
There is no reason to expose and call a separate configureStat() when
the statistics video device can be configured with the exact same
parameters as part of configure(). Move the configuration internally to
the ImgUDevice simplifying the interface, there is no functional change.
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Add a utils::reverse() function that creates an adapter wrapping in
iterable, such that range-based iteration over the adapter iterates over
the iterable in reverse order.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The presence of mandatory and optional controls is checked in
CameraSensor::validateSensorDriver() by trying to retrieve them. This
causes an error message to be printed in the V4L2Device class if an
optional control isn't present, while this isn't an error.
To fix this, use the control idmap reported by the V4L2Device to check
for controls availability. The function can now print the whole list of
missing controls, making debugging easier.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
YUV sensors don't provide the necessary information to fill
CameraSensorInfo, as they include an ISP and provide a higher-level API
that doesn't always expose low-level information. The CameraSensor class
makes low-level V4L2 controls mandatory for all sensors, which prevents
usage of YUV sensors with the simple pipeline handler.
Make CameraSensor::sensorInfo() available for raw sensors only. This
won't introduce any regression in pipeline handlers that currently use
the sensorInfo() function as they all operate with raw sensors, and
won't be a limitation for the simple pipeline handler as well as it
doesn't use sensor info. If part of the sensor info (such as the active
pixel array size for instance) becomes useful to expose for YUV sensors
in the future, the sensorInfo() function can be extended to report that
information only and skip data that is only available for raw sensors.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
The Bayer pattern is retrieved based on the media bus formats supported
by the sensor, when registering camera sensor properties. To prepare for
its usage elsewhere in the CameraSensor class, store it in a private
member variable.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
Sensor frame length is made up of active and inactive (blanking) lines.
The minimum and maximum frame length values may be used by pipeline
handlers to limit frame durations based on the sensor mode capabilities.
Store the minimum and maximum allowable frame length values (in lines)
in the CameraSensorInfo structure. These values are computed in
CameraSensor::sensorInfo() by querying the sensor subdevice
V4L2_CID_VBLANK control limits. This in turn means that V4L2_CID_VBLANK
is now a mandatory subdevice control.
Signed-off-by: Naushir Patuck <naush@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 the V4L2_CID_VBLANK control to the list of mandatory controls
the sensor driver has to report and document the new requirement.
The vertical blanking control is used to calculate the frame duration.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Signed-off-by: Naushir Patuck <naush@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>
|
|
IPA_RESULT_SENSOR_PARAMS
Fixup logic when handling IPA_RESULT_SENSOR_PARAMS where we must always
overwrite the parameters if provided by IPA. In the current codebase,
this only happens once on startup, so there is no effective functional
difference. But this change allows the option for the IPA to request new
sensor parameters per-mode if required.
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>
|
|
Rename the enum values to indicate pipeline handler -> IPA actions
(IPA_CONFIG_*) and IPA -> pipeline handler return results (IPA_RESULT_*).
Additionally, provide more descriptive names for these values.
Signed-off-by: Naushir Patuck <naush@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>
|
|
To transpose a BayerFormat means to flip it over its main diagonal.
For example:
G B G R
->
R G B G
The main diagonal goes from the top left to the bottom right. This
means, that the only two orders affected by a transpose are GBRG & GRBG.
When a transpose is used in combination with horizontal and/or vertical
flips it is performed after the flips. Therefore add the functionality
by switching GBRG (index 1) with GRBG (index 2), after the flips have
been applied.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: David Plowman <david.plowman@raspberrypi.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Enable to test two Bayer formats for equality by checking if the order
of the color channels, the bit depth of the pattern, and the packing
scheme match. Additionally, add the reverse operation (!=), which negates
the equality test result.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The new `fromV4l2PixelFormat` static member function renders an old
BayerFormat constructor useless, remove it together with the
`v4l2ToBayer` mapping table. The new function searches for a matching
mapped value instead of a matching key, therefore the `bayerToV4l2`
table is sufficient.
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add a static member function to get the corresponding BayerFormat from a
given V4L2PixelFormat. The motivation behind this patch is to align the
overall structure of the BayerFormat class with other parts of the code
base, such as the V4L2PixelFormat class.
The downside of this change is a slightly worse time complexity, but
the upside is a smaller codebase and lower memory consumption. As the
function is probably not used very frequently, I tend to favor the
mentioned upsides.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sebastian Fricke <sebastian.fricke@posteo.net>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
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>
|
