| Age | Commit message (Collapse) | Author |
|---|
|
We have multiple code generation scripts in utils/, mixed with other
miscellaneous utilities, as well as a larger code base based on mojom in
utils/ipc/. To make code sharing easier between the generator scripts,
without creating a mess in the utils/ directory, move all the code
generation code to utils/codegen/.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
|
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>
|
|
Generate maps for each control enum which associate strings that
represent the enum values with the values themselves. This change
will allow us to refer to enumerated control values using the
string. For example if we want to pass variables to an algorithm
for use when a control has a particular value we can embed within
tuning files a dictionary that uses the control values as keys.
Reviewed-by: Stefan Klug <stefan.klug@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Label draft controls and properties through the "draft" vendor tag
and deprecate the existing "draft: true" mechanism. This uses the new
vendor tags mechanism to place draft controls in the same
libcamera::controls::draft namespace and provide a defined control id
range for these controls. This requires moving all draft controls from
control_ids.yaml to control_ids_draft.yaml.
One breaking change in this commit is that draft control ids also move
to the libcamera::controls::draft namespace from the existing
libcamera::controls namespace. This is desirable to avoid API breakages
when adding new libcamera controls. So, for example, the use of
controls::NOISE_REDUCTION_MODE will need to be replaced with
controls::draft::NOISE_REDUCTION_MODE.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add a new control_ranges.yaml file that is used to reserve control id
ranges/offsets for libcamera and vendor specific controls. This file is
used by the gen-controls.py script to generate control id values for
each control.
Draft controls now have a separate range from core libcamera controls,
breaking the existing numbering behaviour.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
|
|
Add support for using separate YAML files for controls and properties
generation. The mapping of vendor/pipeline handler to control file is
done through the controls_map variable in include/libcamera/meson.build.
This simplifies management of vendor control definitions and avoids
possible merge conflicts when changing the control_ids.yaml file for
core and draft controls. With this change, libcamera and draft controls
and properties files are designated the 'libcamera' vendor tag.
In this change, we also rename control_ids.yaml -> control_ids_core.yaml
and property_ids.yaml -> property_ids_core.yaml to designate these as
core libcamera controls.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
The template file to the gen-controls.py and gen-py-controls.py is now
passed in through the '-t' or '--template' command line argument instead
of being a positional argument. This will allow multiple input files to
be provided to the scripts in a future commit.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Add support for vendor-specific controls and properties to libcamera.
The controls/properties are defined by a "vendor" tag in the YAML
control description file, for example:
vendor: rpi
controls:
- MyExampleControl:
type: string
description: |
Test for libcamera vendor-specific controls.
This will now generate a control id in the libcamera::controls::rpi
namespace, ensuring no id conflict between different vendors, core or
draft libcamera controls. Similarly, a ControlIdMap control is generated
in the libcamera::controls::rpi namespace.
A #define LIBCAMERA_HAS_RPI_VENDOR_CONTROLS is also generated to allow
applications to conditionally compile code if the specific vendor
controls are present. For the python bindings, the control is available
with libcamera.controls.rpi.MyExampleControl. The above controls
example applies similarly to properties.
Existing libcamera controls defined in control_ids.yaml are given the
"libcamera" vendor tag.
A new --mode flag is added to gen-controls.py to specify the mode of
operation, either 'controls' or 'properties' to allow the code generator
to correctly set the #define string.
As a drive-by, sort and redefine the output command line argument in
gen-controls.py and gen-py-controls.py to ('--output', '-o') for
consistency.
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
|
|
Array controls specify the array size through the YAML 'size' element,
which stores a list of values, one per dimension. Variable-size arrays
currently use an empty 'size' list, which prevents describing the number
of dimensions of the array.
Improve this by using the same notation for fixed-size and variable-size
array controls. Dimensions that are not fixed are described as a string
instead of an integer, such as [n], [n,3] or [w,h]. The strings have
currently no special meaning, this may change in the future.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
The gen-controls.py script handles the data structure produced by the
YAML parser manually through the whole code base. Clean this up by
encapsulating it in Control and ControlEnum classes to model a control
and its enum values respectively, to decouple YAML data handling from
generation.
No functional change intended.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Umang Jain <umang.jain@ideasonboard.com>
|
|
Define Span types explicitly as either variable- or fixed-sized. This
introduces a new convention for defining Span dimensions in the property
and control value definitions and generates Span types as variable-sized
Span<T> or as fixed-sized Span<T,N>.
Signed-off-by: Christian Rauch <Rauch.Christian@gmx.de>
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 Doxygen documentation for enumerators 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>
Tested-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
|
|
Remove an extra whitespace in the declaration of a dictionary entry in
gen-controls.py script.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
For each Control that supports enumerated values generate an array
of ControlValue which contains the full list of valid values.
At the expense of a slight increase in memory occupation this change
allows the construction of the ControlInfo associated with a Control
from the values list, defaulting the minimum and maximum values
reported by the ControlInfo.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Rename the enumeration of supported values with the suffix "Enum"
in place of "Values" to prepare to re-use the suffix "Values"
for the vector of Control's value introduced by the next patch.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Extend the control and property framework to support exposing draft
controls and properties in a scoped namespace.
The controls/properties themselves will retain the same ordering in the
relevant enum/id maps - but the access to any draft control will require
explicitly referencing through its' draft:: namespace prefix.
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>
[Added missing hunk in control_ids.cpp.in and changed subject]
Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
|
|
Move the GPL2 utilities which handle generation of controls, formats and
the top level libcamera header to the utils subtree.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
|
