| Age | Commit message (Collapse) | Author |
|---|
|
In order to get the stats back, the imgu subdev needs to have the
V4L2_CID_INTEL_IPU3_MODE control set.
Set it to video mode by default to get the stats at each frame.
Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
[Kieran: Updated message to match Laurent's suggestion]
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The call to setFormat uses uninitialised data, which, could cause
unwanted effects. It is also trapped and reported by valgrind.
Initialise the V4L2SubdeviceFormat structure correctly before use.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Only update the lens shading control if it is present in the
ControlList.
Add the dmabuf file descriptor to the lens shading control in-place
rather than taking a copy.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Rename the IPA interface namespace to ipa::RPi for consistency with
the libcamera::RPi namespace label.
There is no functional change in this commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
This commit addresses a couple of tidy-ups after the IPAInterface
rework:
- Rename ConfigStaggeredWrite -> ConfigSensorParams
- Rename setIsp -> setIspControls
There is no functional change in this commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
With the recent IPAInterface changes, the signal handlers
statsMetadataComplete(), runISP() and embeddedComplete() would run
unconditionally when called. They should only run when state != Stopped.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Fixes: e201cb4f5450 ("libcamera: IPAInterface: Replace C API with the new C++-only API")
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Remove everything related to the C API, including ipa_context,
ipa_context_wrapper, and IPAInterfaceWrapper. Also remove relevant
documentation.
ipaCreate() provided by IPA implementations, and createInterface()
provided by IPAModule (wrapper around IPA implementation) both now
return a C++ object IPAInterface instead of struct ipa_context.
Although IPAInterfaceWrapper is the only component of libipa, the
skeleton and build files for libipa are retained.
After converting the C API to the C++-only API, make all pipeline
handlers and IPAs use the new API.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
This is a combination of 21 commits:
---
libcamera: IPAModule: Replace ipa_context with IPAInterface
With the new IPC infrastructure, we no longer need the C interface as
provided by struct ipa_context. Make ipaCreate_() and createInterface()
return IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: ipa_context_wrapper: Remove ipa_context_wrapper
Since ipa_context has been replaced with custom IPAInterfaces, it is not
longer needed. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAInterface: remove ipa_context and functions from documentation
Remove all the documentation related to ipa_context and the C IPA API,
as well as the documentation about the functions in the IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
libcamera: IPAInterface: Remove all functions from IPAInterface
Now that all the functions in the IPA interface are defined in the data
definition file and a specialized IPAInterface is generated per pipeline
handler, remove all the functions from the base IPAInterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAInterface: make ipaCreate return IPAInterface
With the new IPC infrastructure, we no longer need the C interface as
provided by struct ipa_context. Make ipaCreate return IPAinterface.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
ipa: remove IPAInterfaceWrapper
As every pipeline has its own proxy, IPAInterfaceWrapper is no
longer necessary. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Acked-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
libcamera: IPAProxy: Remove stop() override
Since stop() is part of the IPA interface, and the IPA interface is now
generated based on the data definition file per pipeline, this no longer
needs to be overrided by the base IPAProxy. Remove it.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAProxy, IPAManager: Switch to one-proxy-per-pipeline scheme
IPAProxy is changed in two major ways:
- Every pipeline has its own proxy, to support each pipeline's IPA
interface
- IPAProxy implementations always encapsulate IPA modules, and switch
internally for isolation or threaded
The IPAProxy registration mechanism is removed, as each pipeline will
have its own proxy, so the pipeline can pass the specialized class name
of the IPAProxy to the IPAManager for construction.
IPAManager is changed accordingly to support these changes:
- createIPA is a template function that takes an IPAProxy class, and
always returns an IPAProxy
- IPAManager no longer decides on isolation, and simply creates an
IPAProxy instance while passing the isolation flag
Consequently, the old IPAProxy classes (IPAProxyThread and
IPAProxyLinux) are removed. The IPAInterfaceTest is updated to use
the new IPAManager interface, and to construct a ProcessManager as no
single global instance is created anymore.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
---
libcamera: IPAProxy: Add isolate parameter to create()
Since IPAProxy implementations now always encapsulate IPA modules, add a
parameter to create() to signal if the proxy should isolate the IPA or not.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAManager: Fetch IPAProxy corresponding to pipeline
Now that each pipeline handler has its own IPAProxy implementation, make
the IPAManager fetch the IPAProxy based on the pipeline handler name.
Also, since the IPAProxy is used regardless of isolation or no
isolation, remove the isolation check from the proxy selection.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
---
libcamera: IPAManager: add isolation flag to proxy creation
When the IPA proxy is created, it needs to know whether to isolate or
not. Feed the flag at creation of the IPA proxy.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAManager: Make createIPA return proxy directly
Since every pipeline knows the type of the proxy that it needs, and
since all IPAs are to be wrapped in a proxy, IPAManager no longer needs
to search in the factory list to fetch the proxy factory to construct a
factory. Instead, we define createIPA as a template function, and the
pipeline handler can declare the proxy type when it calls createIPA.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: IPAProxy: Remove registration mechanism
Implementations of IPA proxies use a registration mechanism to register
themselves with the main IPA proxy factory. This registration declares
static objects, causing a risk of things being constructed before the
proper libcamera facilities are ready. Since each pipeline handler has
its own IPA proxy and knows the type, it isn't necessary to have a proxy
factory. Remove it to alleviate the risk of early construction.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: proxy: Remove IPAProxyLinux and IPAProxyThread
We have now changed the proxy from per-IPC mechanism to per-pipeline.
The per-IPC mechanism proxies are thus no longer needed; remove them.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
tests: ipa_interface_test: Update to use new createIPA
Update the IPA interface test to use the new createIPA function from
IPAManager. Also create an instance of ProcessManager, as no single
global instance is created automatically anymore. Update meson.build to
to depend on the generated IPA interface headers.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: PipelineHandler: Remove IPA from base class
Since pipeline handlers now have their own IPA interface types, it can no
longer be defined in the base class, and each pipeline handler
implementation must declare it and its type themselves. Remove it from
the base class.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
ipa: raspberrypi: Add mojom data definition file
Add a mojom data definition for raspberrypi pipeline handler's IPAs.
This simplifies the API between the raspberrypi pipeline handler and the
IPA, and is not a direct translation of what was used before with
IPAOperationData.
Also move the enums from raspberrypi.h to raspberrypi.mojom
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: raspberrypi: Use new data definition
Now that we can generate custom functions and data structures with mojo,
switch the raspberrypi pipeline handler and IPA to use the custom data
structures as defined in the mojom data definition file.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: vimc: Support the new IPC mechanism
Add support to vimc pipeline handler and IPA for the new IPC mechanism.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
---
libcamera: pipeline, ipa: rkisp1: Support the new IPC mechanism
Add support to the rkisp1 pipeline handler and IPA for the new IPC
mechanism.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
libcamera: pipeline, ipa: ipu3: Support the new IPC mechanism
Add support to ipu3 pipeline handler and IPA for the new IPC mechanism.
[Original version]
Signed-off-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
[Fixed commit message and small changes]
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
start method
Currently the call to the configure method of rkisp1 IPA
is called upon the 'start' of the pipeline. This should be done
in the 'configure' method instead.
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Paul Elder <paul.elder@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>
|
|
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>
|
|
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>
|
|
The function declaration fits on one line.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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 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>
|
|
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>
|
|
This change allows controls passed into PipelineHandler::start to be
forwarded onto IPAInterface::start(). We also add a return channel if the
pipeline handler must action any of these controls, e.g. setting the
analogue gain or shutter speed in the sensor device.
The IPA interface wrapper isn't addressed as it will soon be replaced by
a new mechanism to handle IPC.
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>
|
