Usage of 'method' to refer to member functions comes from Java. The C++
standard uses the term 'function' only. Replace 'method' with 'function'
or 'member function' through the whole code base and documentation.
While at it, fix two typos (s/backeng/backend/).
The BoundMethod and Object::invokeMethod() are left as-is here, and will
be addressed separately.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
To capture raw frames, the ImgU isn't needed. However, to implement
auto-exposure, we do need to configure the IPA since it shall setup
the sensor controls (exposure, vblank and so on) for the capture.
One cannot simply configure the IPA, without the ImgU as the
parameters and statistics buffer passed to the IPA are actually
managed by the ImgU.
Until we prepare and setup the ImgU to run an internal queue for
raw-only camera configuration, disallow this configuration and
report it as invalid.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Propagate the requested test pattern mode to libcamera::Camera
through libcamera::Request and also set the android metadata to
the test pattern mode contained by the complete Request.
Signed-off-by: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Currently, all UVC cameras are reported with CameraLocationExternal [1]
by libcamera-core since there is no universal information or standard,
to know the location of these cameras. However, in the libcamera HAL
layer, we can make an informed decision whether it's external or
internal, simply by checking its presence in the HAL configuration
file.
The CameraHalManager will now assign the numerical id of the camera
accordingly when initializing the CameraDevice, based on the camera
facing value set in the HAL config file.
[1] 76809320bb ("libcamera: pipeline: uvcvideo: Treat all UVC cameras
as external")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Error out on any camera's location if set to "external", in the HAL
configuration file. The HAL configuration file is meant to override the
location property, and overriding an internal camera location to
external doesn't make sense.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Currently CameraDevice wrapper is created first and then HAL config
validity is checked. If the validity checks fail, the code path will
simply return, in which case, creating CameraDevice seems a futile
exercise.
This patch defers the creation of CameraDevice wrapper until the HAL
config validity is checked for internal cameras. This will also enable
us to infer a few things beforehand, by reading the config file before
creating the CameraDevice wrapper.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
The GL_RG and GL_RED texture formats are not supported in OpenGL ES
prior to 3.0. In order to be compatible with OpenGL ES 2.0, use
GL_LUMINANCE_ALPHA and GL_LUMINANCE instead. The shader code needs to be
updated accordingly for GL_RG, as the second component is now stored in
the alpha component instead of the green component. Usage of the red
component is fine, the luminance value is stored in the red, green and
blue components.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Andrey Konovalov <andrey.konovalov@linaro.org>
The Camera::Private class is defined in camera.cpp. To prepare for
allowing it to be subclassed by pipeline handlers, move it to a new
internal/camera.h header.
The \file comment block in camera.cpp now needs to explicitly tell which
camera.h file it refers to.
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 FrameBuffer::Private class is exposed to pipeline handlers, and is
thus part of the internal libcamera API. As such, it should be
documented.
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 Extensible and Extensible::Private classes contain pointers to each
other. These pointers are initialized in the respective class's
constructor, by passing a pointer to the other class to each
constructor. This particular construct reduces the flexibility of the
Extensible pattern, as the Private class instance has to be allocated
and constructed in the members initializer list of the Extensible
class's constructor. It is thus impossible to perform any operation on
the Private class between its construction and the construction of the
Extensible class, or to subclass the Private class without subclassing
the Extensible class.
To make the design pattern more flexible, don't pass the pointer to the
Extensible class to the Private class's constructor, but initialize the
pointer manually in the Extensible class's constructor. This requires a
const_cast as the o_ member of the Private class is const.
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 LIBCAMERA_O_PTR macro is part of the Extensible class
infrastructure, but doesn't link to it. This makes the generated
documentation unclear. Fix it.
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>
Use the newly introduced Flags<> class to store a bitfield of
File::OpenMode in a type-safe way. The existing File::OpenMode enum is
renamed to File::OpenModeFlag to free the File::OpenMode for the Flags<>
type alias.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Add a Flags template class that provide type-safe bitwise operators on
enum values. This allows using enum types for bit fields, without giving
away type-safety as usually done when storing combined flags in integer
variables.
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>
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 helpers for setting android metadata from libcamera controls.
There are two versions, for scalars and collections, both of which take
a default value to fill in the android control if the libcamera control
is not found. They both return the value that was set.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Since we set entries with android tags directly, which are enums and not
arithmetic types, the addEntry template fails to match. Fix this by also
allowing enum values in addEntry.
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 convenience functions for checking if an entry is present in a
CameraMetadata instance, and to check if an array entry includes a
specific value.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
It would be convenient to be able to iterate over available boolean
values, for example for controls that designate if some function can be
enabled/disabled. The current min/max/def constructor is insufficient,
as .values() is empty, so the values cannot be easily iterated over, and
creating a Span of booleans does not work for the values constructor.
Add new constructors to ControlInfo that takes a set of booleans (if
both booleans are valid values) plus a default, and another that takes
only one boolean (if only one boolean is a valid value).
Update the ControlInfo test accordingly.
Signed-off-by: Paul Elder <paul.elder@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo@jmondi.org>
This commit adds a tuning file for the 12MP imx378 sensor. The sensor
actually shares the same driver (and CamHelper) as the imx477 so only
a new tuning file is required. The default choice of imx477.json can
be overridden by pointing LIBCAMERA_RPI_TUNING_FILE at a version of
the new imx378.json file.
Signed-off-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-by: Naushir Patuck <naush@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>
When RPiCameraData::clearIncompleteRequests() clears out the request
queue during a stop condition, it unconditionally calls completeBuffer()
on all buffers in each request. This is wrong, as a buffer could have
already been completed as part of the current request, but the request
itself may not yet have completed.
Fix this by checking if the buffers in the request have been completed
before cancelling them.
Fixes: d372aaa10d ("pipeline: raspberrypi: Simplify RPiCameraData::clearIncompleteRequests()")
Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
Tested-by: David Plowman <david.plowman@raspberrypi.com>
Reviewed-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 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>
Extend the CameraSensorHelper factory with support for the IMX258
sensor found in the Nautilus Chromebook.
The values are read by manually tweaking the IMX258 kernel driver.
The IMX258 kernel driver hints that the sensor may be compatible
with the MIPI CCS specification, as the register set matches.
The values for analog gain constants are obtained by reading the
register indexes, corresponding to the analog gain constants, as
mentioned in MIPI CCS v1.1 specification.
The values have further been confirmed by Dave Stevenson as being
those specified in the datasheet.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Laurent Pinchart
Umang Jain
Hirokazu Honda
David Plowman
Vedant Paranjape
Paul Elder
Naushir Patuck
Jacopo Mondi
Daniel Scally