| Age | Commit message (Collapse) | Author |
|---|
|
Source files in libcamera start by a comment block header, which
includes the file name and a one-line description of the file contents.
While the latter is useful to get a quick overview of the file contents
at a glance, the former is mostly a source of inconvenience. The name in
the comments can easily get out of sync with the file name when files
are renamed, and copy & paste during development have often lead to
incorrect names being used to start with.
Readers of the source code are expected to know which file they're
looking it. Drop the file name from the header comment block.
The change was generated with the following script:
----------------------------------------
dirs="include/libcamera src test utils"
declare -rA patterns=(
['c']=' \* '
['cpp']=' \* '
['h']=' \* '
['py']='# '
['sh']='# '
)
for ext in ${!patterns[@]} ; do
files=$(for dir in $dirs ; do find $dir -name "*.${ext}" ; done)
pattern=${patterns[${ext}]}
for file in $files ; do
name=$(basename ${file})
sed -i "s/^\(${pattern}\)${name} - /\1/" "$file"
done
done
----------------------------------------
This misses several files that are out of sync with the comment block
header. Those will be addressed separately and manually.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
|
|
Remove the verbose #ifndef/#define/#endif pattern for maintaining
header idempotency, and replace it with a simple #pragma once.
This simplifies the headers, and prevents redundant changes when
header files get moved.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
|
|
While building the list of supported stream configurations also collect
the absolute max frame durations to be used to populate the sensor
maximum frame duration.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Collect the per-stream frame durations while building the list
of supported stream formats and resolutions.
In order to get an updated list of controls it is necessary to apply
to the Camera the configuration we're testing, which was so far only
validated.
The per-configuration durations will be used to populate the Android
ANDROID_SCALER_AVAILABLE_MIN_FRAME_DURATIONS static metadata.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
If the camera devices does not support the MANUAL_SENSOR capabilities
there is no point in generating a request template for the Manual
capture use case.
This change fixes CTS tests
android.hardware.camera2.cts.CameraDeviceTest#testCameraDeviceManualTemplate
android.hardware.camera2.cts.NativeCameraDeviceTest#testCameraDeviceCreateCaptureRequest
For devices that do not support MANUAL_SENSOR capabilities.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add skeletal still and manual request templates so that we can expand
them for FULL support.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
We need to be able to add additional characteristics/request/result keys
into the corresponding list in the static metadata based on libcamera
camera capabilities. We also need to be able to easily check if the
lists have specific keys, for populating templates and result metadata.
Turn the characteristics, requests, and results keys vectors into sets,
and move them to member variables to achieve this.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
Add the infrastructure for checking and reporting capabilities. Use
these capabilities to determine the hardware level as well.
Bug: https://bugs.libcamera.org/show_bug.cgi?id=55
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The validation of RAW stream support is performed in two different
places:
- At initializeStreamConfigurations() time, by verifying that the
libcamera format associated with HAL_PIXEL_FORMAT_BLOB is a Raw format
and ensuring the Camera successfully validates it
- As initializeStaticMetadata() time by generating a CameraConfiguration
for the Raw stream role and ensuring it is a Raw format with a 16 bit
depth
The first check is used to build the list of supported Raw stream
resolutions. The latter is used to register the
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_RAW capability.
As building the list of supported Raw streams doesn't serve any
purpose if the RAW capability is not registered, centralize the Raw
format support verification at initializeStreamConfigurations() time by
ensuring the supported format is a Raw one with a 16 bit depth.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
The getYUVResolutions() and getRawResolutions() functions are called
from the initializeStreamConfigurations() function, which is called by
initialize().
Rationalize the function naming scheme by renaming the two functions to
initializeYUVResolutions() and initializeRawResolution().
Cosmetic change only.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
When building the list of supported YUV streams in getYUVResolutions()
the CameraConfiguration provided by the caller as first parameters is used.
As the CameraConfiguration will be later actually applied to the Camera,
avoid any possible overlap of the configuration parameters by using a
throw-away CameraConfiguration generated for the Viewfinder stream role
in getYUVResolutions().
It's also nicer to avoid having two functions with a similar purpose
such as getYUVResolutions() and getRawResolutions() with different
parameter lists, as the presence of a CameraConfiguration as first
parameter might be confusing to the reader.
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Move the class support infrastructure to the base library.
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The camera_device.cpp has grown a little too much, and it has quickly
become hard to maintain. Break out the handling of the static
information collected at camera initialization time to a new
CameraCapabilities class.
Break out from the camera_device.cpp file all the functions related to:
- Initialization of supported stream configurations
- Initialization of static metadata
- Initialization of request templates
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
Acked-by: Paul Elder <paul.elder@ideasonboard.com>
Tested-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
|
