src/qcam/assets/feathericons/gitlab.svg


1

<svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="feather feather-gitlab"><path d="M22.65 14.39L12 22.13 1.35 14.39a.84.84 0 0 1-.3-.94l1.22-3.78 2.44-7.51A.42.42 0 0 1 4.82 2a.43.43 0 0 1 .58 0 .42.42 0 0 1 .11.18l2.44 7.49h8.1l2.44-7.51A.42.42 0 0 1 18.6 2a.43.43 0 0 1 .58 0 .42.42 0 0 1 .11.18l2.44 7.51L23 13.45a.84.84 0 0 1-.35.94z"></path></svg>
/* SPDX-License-Identifier: Apache-2.0 */
/*
 * Copyright (C) 2013-2018 The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

#ifndef ANDROID_INCLUDE_CAMERA3_H
#define ANDROID_INCLUDE_CAMERA3_H

#include <system/camera_metadata.h>
#include "camera_common.h"

/**
 * Camera device HAL 3.5[ CAMERA_DEVICE_API_VERSION_3_5 ]
 *
 * This is the current recommended version of the camera device HAL.
 *
 * Supports the android.hardware.Camera API, and as of v3.2, the
 * android.hardware.camera2 API as LIMITED or above hardware level.
 *
 * Camera devices that support this version of the HAL must return
 * CAMERA_DEVICE_API_VERSION_3_5 in camera_device_t.common.version and in
 * camera_info_t.device_version (from camera_module_t.get_camera_info).
 *
 * CAMERA_DEVICE_API_VERSION_3_3 and above:
 *    Camera modules that may contain version 3.3 or above devices must
 *    implement at least version 2.2 of the camera module interface (as defined
 *    by camera_module_t.common.module_api_version).
 *
 * CAMERA_DEVICE_API_VERSION_3_2:
 *    Camera modules that may contain version 3.2 devices must implement at
 *    least version 2.2 of the camera module interface (as defined by
 *    camera_module_t.common.module_api_version).
 *
 * <= CAMERA_DEVICE_API_VERSION_3_1:
 *    Camera modules that may contain version 3.1 (or 3.0) devices must
 *    implement at least version 2.0 of the camera module interface
 *    (as defined by camera_module_t.common.module_api_version).
 *
 * See camera_common.h for more versioning details.
 *
 * Documentation index:
 *   S1. Version history
 *   S2. Startup and operation sequencing
 *   S3. Operational modes
 *   S4. 3A modes and state machines
 *   S5. Cropping
 *   S6. Error management
 *   S7. Key Performance Indicator (KPI) glossary
 *   S8. Sample Use Cases
 *   S9. Notes on Controls and Metadata
 *   S10. Reprocessing flow and controls
 */

/**
 * S1. Version history:
 *
 * 1.0: Initial Android camera HAL (Android 4.0) [camera.h]:
 *
 *   - Converted from C++ CameraHardwareInterface abstraction layer.
 *
 *   - Supports android.hardware.Camera API.
 *
 * 2.0: Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:
 *
 *   - Sufficient for implementing existing android.hardware.Camera API.
 *
 *   - Allows for ZSL queue in camera service layer
 *
 *   - Not tested for any new features such manual capture control, Bayer RAW
 *     capture, reprocessing of RAW data.
 *
 * 3.0: First revision of expanded-capability HAL:
 *
 *   - Major version change since the ABI is completely different. No change to
 *     the required hardware capabilities or operational model from 2.0.
 *
 *   - Reworked input request and stream queue interfaces: Framework calls into
 *     HAL with next request and stream buffers already dequeued. Sync framework
 *     support is included, necessary for efficient implementations.
 *
 *   - Moved triggers into requests, most notifications into results.
 *
 *   - Consolidated all callbacks into framework into one structure, and all
 *     setup methods into a single initialize() call.
 *
 *   - Made stream configuration into a single call to simplify stream
 *     management. Bidirectional streams replace STREAM_FROM_STREAM construct.
 *
 *   - Limited mode semantics for older/limited hardware devices.
 *
 * 3.1: Minor revision of expanded-capability HAL:
 *
 *   - configure_streams passes consumer usage flags to the HAL.
 *
 *   - flush call to drop all in-flight requests/buffers as fast as possible.
 *
 * 3.2: Minor revision of expanded-capability HAL:
 *
 *   - Deprecates get_metadata_vendor_tag_ops.  Please use get_vendor_tag_ops
 *     in camera_common.h instead.
 *
 *   - register_stream_buffers deprecated. All gralloc buffers provided
 *     by framework to HAL in process_capture_request may be new at any time.
 *
 *   - add partial result support. process_capture_result may be called
 *     multiple times with a subset of the available result before the full
 *     result is available.
 *
 *   - add manual template to camera3_request_template. The applications may
 *     use this template to control the capture settings directly.
 *
 *   - Rework the bidirectional and input stream specifications.
 *
 *   - change the input buffer return path. The buffer is returned in
 *     process_capture_result instead of process_capture_request.
 *
 * 3.3: Minor revision of expanded-capability HAL:
 *
 *   - OPAQUE and YUV reprocessing API updates.
 *
 *   - Basic support for depth output buffers.
 *
 *   - Addition of data_space field to camera3_stream_t.
 *
 *   - Addition of rotation field to camera3_stream_t.
 *
 *   - Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t
 *
 * 3.4: Minor additions to supported metadata and changes to data_space support
 *
 *   - Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if
 *     RAW_OPAQUE format is supported.
 *
 *   - Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as
 *     mandatory if any RAW format is supported
 *
 *   - Switch camera3_stream_t data_space field to a more flexible definition,
 *     using the version 0 definition of dataspace encoding.
 *
 *   - General metadata additions which are available to use for HALv3.2 or
 *     newer:
 *     - ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
 *     - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
 *     - ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
 *     - ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
 *     - ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
 *     - ANDROID_SENSOR_OPAQUE_RAW_SIZE
 *     - ANDROID_SENSOR_OPTICAL_BLACK_REGIONS
 *
 * 3.5: Minor revisions to support session parameters and logical multi camera:
 *
 *   - Add ANDROID_REQUEST_AVAILABLE_SESSION_KEYS static metadata, which is
 *     optional for implementations that want to support session parameters. If support is
 *     needed, then Hal should populate the list with all available capture request keys
 *     that can cause severe processing delays when modified by client. Typical examples
 *     include parameters that require time-consuming HW re-configuration or internal camera
 *     pipeline update.
 *
 *   - Add a session parameter field to camera3_stream_configuration which can be populated
 *     by clients with initial values for the keys found in ANDROID_REQUEST_AVAILABLE_SESSION_KEYS.
 *
 *   - Metadata additions for logical multi camera capability:
 *     - ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
 *     - ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
 *     - ANDROID_LOGICAL_MULTI_CAMERA_SYNC_TYPE
 *
 *   - Add physical camera id field in camera3_stream, so that for a logical
 *     multi camera, the application has the option to specify which physical camera
 *     a particular stream is configured on.
 *
 *   - Add physical camera id and settings field in camera3_capture_request, so that
 *     for a logical multi camera, the application has the option to specify individual
 *     settings for a particular physical device.
 *
 */

/**
 * S2. Startup and general expected operation sequence:
 *
 * 1. Framework calls camera_module_t->common.open(), which returns a
 *    hardware_device_t structure.
 *
 * 2. Framework inspects the hardware_device_t->version field, and instantiates
 *    the appropriate handler for that version of the camera hardware device. In
 *    case the version is CAMERA_DEVICE_API_VERSION_3_0, the device is cast to
 *    a camera3_device_t.
 *
 * 3. Framework calls camera3_device_t->ops->initialize() with the framework
 *    callback function pointers. This will only be called this one time after
 *    open(), before any other functions in the ops structure are called.
 *
 * 4. The framework calls camera3_device_t->ops->configure_streams() with a list
 *    of input/output streams to the HAL device.
 *
 * 5. <= CAMERA_DEVICE_API_VERSION_3_1:
 *
 *    The framework allocates gralloc buffers and calls
 *    camera3_device_t->ops->register_stream_buffers() for at least one of the
 *    output streams listed in configure_streams. The same stream is registered
 *    only once.
 *
 *    >= CAMERA_DEVICE_API_VERSION_3_2:
 *
 *    camera3_device_t->ops->register_stream_buffers() is not called and must
 *    be NULL.
 *
 * 6. The framework requests default settings for some number of use cases with
 *    calls to camera3_device_t->ops->construct_default_request_settings(). This
 *    may occur any time after step 3.
 *
 * 7. The framework constructs and sends the first capture request to the HAL,
 *    with settings based on one of the sets of default settings, and with at
 *    least one output stream, which has been registered earlier by the
 *    framework. This is sent to the HAL with
 *    camera3_device_t->ops->process_capture_request(). The HAL must block the
 *    return of this call until it is ready for the next request to be sent.
 *
 *    >= CAMERA_DEVICE_API_VERSION_3_2:
 *
 *    The buffer_handle_t provided in the camera3_stream_buffer_t array
 *    in the camera3_capture_request_t may be new and never-before-seen
 *    by the HAL on any given new request.
 *
 * 8. The framework continues to submit requests, and call
 *    construct_default_request_settings to get default settings buffers for
 *    other use cases.
 *
 *    <= CAMERA_DEVICE_API_VERSION_3_1:
 *
 *    The framework may call register_stream_buffers() at this time for
 *    not-yet-registered streams.
 *
 * 9. When the capture of a request begins (sensor starts exposing for the
 *    capture) or processing a reprocess request begins, the HAL
 *    calls camera3_callback_ops_t->notify() with the SHUTTER event, including
 *    the frame number and the timestamp for start of exposure. For a reprocess
 *    request, the timestamp must be the start of exposure of the input image
 *    which can be looked up with android.sensor.timestamp from
 *    camera3_capture_request_t.settings when process_capture_request() is
 *    called.
 *
 *    <= CAMERA_DEVICE_API_VERSION_3_1:
 *
 *    This notify call must be made before the first call to
 *    process_capture_result() for that frame number.
 *
 *    >= CAMERA_DEVICE_API_VERSION_3_2:
 *
 *    The camera3_callback_ops_t->notify() call with the SHUTTER event should
 *    be made as early as possible since the framework will be unable to
 *    deliver gralloc buffers to the application layer (for that frame) until
 *    it has a valid timestamp for the start of exposure (or the input image's
 *    start of exposure for a reprocess request).
 *
 *    Both partial metadata results and the gralloc buffers may be sent to the
 *    framework at any time before or after the SHUTTER event.
 *
 * 10. After some pipeline delay, the HAL begins to return completed captures to
 *    the framework with camera3_callback_ops_t->process_capture_result(). These
 *    are returned in the same order as the requests were submitted. Multiple
 *    requests can be in flight at once, depending on the pipeline depth of the
 *    camera HAL device.
 *
 *    >= CAMERA_DEVICE_API_VERSION_3_2:
 *
 *    Once a buffer is returned by process_capture_result as part of the
 *    camera3_stream_buffer_t array, and the fence specified by release_fence
 *    has been signaled (this is a no-op for -1 fences), the ownership of that
 *    buffer is considered to be transferred back to the framework. After that,
 *    the HAL must no longer retain that particular buffer, and the
 *    framework may clean up the memory for it immediately.
 *
 *    process_capture_result may be called multiple times for a single frame,
 *    each time with a new disjoint piece of metadata and/or set of gralloc
 *    buffers. The framework will accumulate these partial metadata results
 *    into one result.
 *
 *    In particular, it is legal for a process_capture_result to be called
 *    simultaneously for both a frame N and a frame N+1 as long as the
 *    above rule holds for gralloc buffers (both input and output).
 *
 * 11. After some time, the framework may stop submitting new requests, wait for
 *    the existing captures to complete (all buffers filled, all results
 *    returned), and then call configure_streams() again. This resets the camera
 *    hardware and pipeline for a new set of input/output streams. Some streams
 *    may be reused from the previous configuration; if these streams' buffers
 *    had already been registered with the HAL, they will not be registered
 *    again. The framework then continues from step 7, if at least one
 *    registered output stream remains (otherwise, step 5 is required first).
 *
 * 12. Alternatively, the framework may call camera3_device_t->common->close()
 *    to end the camera session. This may be called at any time when no other
 *    calls from the framework are active, although the call may block until all
 *    in-flight captures have completed (all results returned, all buffers
 *    filled). After the close call returns, no more calls to the
 *    camera3_callback_ops_t functions are allowed from the HAL. Once the
 *    close() call is underway, the framework may not call any other HAL device
 *    functions.
 *
 * 13. In case of an error or other asynchronous event, the HAL must call
 *    camera3_callback_ops_t->notify() with the appropriate error/event
 *    message. After returning from a fatal device-wide error notification, the
 *    HAL should act as if close() had been called on it. However, the HAL must
 *    either cancel or complete all outstanding captures before calling
 *    notify(), so that once notify() is called with a fatal error, the
 *    framework will not receive further callbacks from the device. Methods
 *    besides close() should return -ENODEV or NULL after the notify() method
 *    returns from a fatal error message.
 */

/**
 * S3. Operational modes:
 *
 * The camera 3 HAL device can implement one of two possible operational modes;
 * limited and full. Full support is expected from new higher-end
 * devices. Limited mode has hardware requirements roughly in line with those
 * for a camera HAL device v1 implementation, and is expected from older or
 * inexpensive devices. Full is a strict superset of limited, and they share the
 * same essential operational flow, as documented above.
 *
 * The HAL must indicate its level of support with the
 * android.info.supportedHardwareLevel static metadata entry, with 0 indicating
 * limited mode, and 1 indicating full mode support.
 *
 * Roughly speaking, limited-mode devices do not allow for application control
 * of capture settings (3A control only), high-rate capture of high-resolution
 * images, raw sensor readout, or support for YUV output streams above maximum
 * recording resolution (JPEG only for large images).
 *
 * ** Details of limited mode behavior:
 *
 * - Limited-mode devices do not need to implement accurate synchronization
 *   between capture request settings and the actual image data
 *   captured. Instead, changes to settings may take effect some time in the
 *   future, and possibly not for the same output frame for each settings
 *   entry. Rapid changes in settings may result in some settings never being
 *   used for a capture. However, captures that include high-resolution output
 *   buffers ( > 1080p ) have to use the settings as specified (but see below
 *   for processing rate).
 *
 * - Limited-mode devices do not need to support most of the
 *   settings/result/static info metadata. Specifically, only the following settings
 *   are expected to be consumed or produced by a limited-mode HAL device:
 *
 *   android.control.aeAntibandingMode (controls and dynamic)
 *   android.control.aeExposureCompensation (controls and dynamic)
 *   android.control.aeLock (controls and dynamic)
 *   android.control.aeMode (controls and dynamic)
 *   android.control.aeRegions (controls and dynamic)
 *   android.control.aeTargetFpsRange (controls and dynamic)
 *   android.control.aePrecaptureTrigger (controls and dynamic)
 *   android.control.afMode (controls and dynamic)
 *   android.control.afRegions (controls and dynamic)
 *   android.control.awbLock (controls and dynamic)
 *   android.control.awbMode (controls and dynamic)
 *   android.control.awbRegions (controls and dynamic)
 *   android.control.captureIntent (controls and dynamic)
 *   android.control.effectMode (controls and dynamic)
 *   android.control.mode (controls and dynamic)
 *   android.control.sceneMode (controls and dynamic)
 *   android.control.videoStabilizationMode (controls and dynamic)
 *   android.control.aeAvailableAntibandingModes (static)
 *   android.control.aeAvailableModes (static)
 *   android.control.aeAvailableTargetFpsRanges (static)
 *   android.control.aeCompensationRange (static)
 *   android.control.aeCompensationStep (static)
 *   android.control.afAvailableModes (static)
 *   android.control.availableEffects (static)
 *   android.control.availableSceneModes (static)
 *   android.control.availableVideoStabilizationModes (static)
 *   android.control.awbAvailableModes (static)
 *   android.control.maxRegions (static)
 *   android.control.sceneModeOverrides (static)
 *   android.control.aeState (dynamic)
 *   android.control.afState (dynamic)
 *   android.control.awbState (dynamic)
 *
 *   android.flash.mode (controls and dynamic)
 *   android.flash.info.available (static)
 *
 *   android.info.supportedHardwareLevel (static)
 *
 *   android.jpeg.gpsCoordinates (controls and dynamic)
 *   android.jpeg.gpsProcessingMethod (controls and dynamic)
 *   android.jpeg.gpsTimestamp (controls and dynamic)
 *   android.jpeg.orientation (controls and dynamic)
 *   android.jpeg.quality (controls and dynamic)
 *   android.jpeg.thumbnailQuality (controls and dynamic)
 *   android.jpeg.thumbnailSize (controls and dynamic)
 *   android.jpeg.availableThumbnailSizes (static)
 *   android.jpeg.maxSize (static)
 *
 *   android.lens.info.minimumFocusDistance (static)
 *
 *   android.request.id (controls and dynamic)
 *
 *   android.scaler.cropRegion (controls and dynamic)
 *   android.scaler.availableStreamConfigurations (static)
 *   android.scaler.availableMinFrameDurations (static)
 *   android.scaler.availableStallDurations (static)
 *   android.scaler.availableMaxDigitalZoom (static)
 *   android.scaler.maxDigitalZoom (static)
 *   android.scaler.croppingType (static)
 *
 *   android.sensor.orientation (static)
 *   android.sensor.timestamp (dynamic)
 *
 *   android.statistics.faceDetectMode (controls and dynamic)
 *   android.statistics.info.availableFaceDetectModes (static)
 *   android.statistics.faceIds (dynamic)
 *   android.statistics.faceLandmarks (dynamic)
 *   android.statistics.faceRectangles (dynamic)
 *   android.statistics.faceScores (dynamic)
 *
 *   android.sync.frameNumber (dynamic)
 *   android.sync.maxLatency (static)
 *
 * - Captures in limited mode that include high-resolution (> 1080p) output
 *   buffers may block in process_capture_request() until all the output buffers
 *   have been filled. A full-mode HAL device must process sequences of
 *   high-resolution requests at the rate indicated in the static metadata for
 *   that pixel format. The HAL must still call process_capture_result() to
 *   provide the output; the framework must simply be prepared for
 *   process_capture_request() to block until after process_capture_result() for
 *   that request completes for high-resolution captures for limited-mode
 *   devices.
 *
 * - Full-mode devices must support below additional capabilities:
 *   - 30fps at maximum resolution is preferred, more than 20fps is required.
 *   - Per frame control (android.sync.maxLatency == PER_FRAME_CONTROL).
 *   - Sensor manual control metadata. See MANUAL_SENSOR defined in
 *     android.request.availableCapabilities.
 *   - Post-processing manual control metadata. See MANUAL_POST_PROCESSING defined
 *     in android.request.availableCapabilities.
 *
 */

/**
 * S4. 3A modes and state machines:
 *
 * While the actual 3A algorithms are up to the HAL implementation, a high-level
 * state machine description is defined by the HAL interface, to allow the HAL
 * device and the framework to communicate about the current state of 3A, and to
 * trigger 3A events.
 *
 * When the device is opened, all the individual 3A states must be
 * STATE_INACTIVE. Stream configuration does not reset 3A. For example, locked
 * focus must be maintained across the configure() call.
 *
 * Triggering a 3A action involves simply setting the relevant trigger entry in
 * the settings for the next request to indicate start of trigger. For example,
 * the trigger for starting an autofocus scan is setting the entry
 * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTROL_AF_TRIGGER_START for one
 * request, and cancelling an autofocus scan is triggered by setting
 * ANDROID_CONTROL_AF_TRIGGER to ANDROID_CONTRL_AF_TRIGGER_CANCEL. Otherwise,
 * the entry will not exist, or be set to ANDROID_CONTROL_AF_TRIGGER_IDLE. Each
 * request with a trigger entry set to a non-IDLE value will be treated as an
 * independent triggering event.
 *
 * At the top level, 3A is controlled by the ANDROID_CONTROL_MODE setting, which
 * selects between no 3A (ANDROID_CONTROL_MODE_OFF), normal AUTO mode
 * (ANDROID_CONTROL_MODE_AUTO), and using the scene mode setting
 * (ANDROID_CONTROL_USE_SCENE_MODE).
 *
 * - In OFF mode, each of the individual AE/AF/AWB modes are effectively OFF,
 *   and none of the capture controls may be overridden by the 3A routines.
 *
 * - In AUTO mode, Auto-focus, auto-exposure, and auto-whitebalance all run
 *   their own independent algorithms, and have their own mode, state, and
 *   trigger metadata entries, as listed in the next section.
 *
 * - In USE_SCENE_MODE, the value of the ANDROID_CONTROL_SCENE_MODE entry must
 *   be used to determine the behavior of 3A routines. In SCENE_MODEs other than
 *   FACE_PRIORITY, the HAL must override the values of
 *   ANDROId_CONTROL_AE/AWB/AF_MODE to be the mode it prefers for the selected
 *   SCENE_MODE. For example, the HAL may prefer SCENE_MODE_NIGHT to use
 *   CONTINUOUS_FOCUS AF mode. Any user selection of AE/AWB/AF_MODE when scene
 *   must be ignored for these scene modes.
 *
 * - For SCENE_MODE_FACE_PRIORITY, the AE/AWB/AF_MODE controls work as in
 *   ANDROID_CONTROL_MODE_AUTO, but the 3A routines must bias toward metering
 *   and focusing on any detected faces in the scene.
 *
 * S4.1. Auto-focus settings and result entries:
 *
 *  Main metadata entries:
 *
 *   ANDROID_CONTROL_AF_MODE: Control for selecting the current autofocus
 *      mode. Set by the framework in the request settings.
 *
 *     AF_MODE_OFF: AF is disabled; the framework/app directly controls lens
 *         position.
 *
 *     AF_MODE_AUTO: Single-sweep autofocus. No lens movement unless AF is
 *         triggered.
 *
 *     AF_MODE_MACRO: Single-sweep up-close autofocus. No lens movement unless
 *         AF is triggered.
 *
 *     AF_MODE_CONTINUOUS_VIDEO: Smooth continuous focusing, for recording
 *         video. Triggering immediately locks focus in current
 *         position. Canceling resumes cotinuous focusing.
 *
 *     AF_MODE_CONTINUOUS_PICTURE: Fast continuous focusing, for
 *        zero-shutter-lag still capture. Triggering locks focus once currently
 *        active sweep concludes. Canceling resumes continuous focusing.
 *
 *     AF_MODE_EDOF: Advanced extended depth of field focusing. There is no
 *        autofocus scan, so triggering one or canceling one has no effect.
 *        Images are focused automatically by the HAL.
 *
 *   ANDROID_CONTROL_AF_STATE: Dynamic metadata describing the current AF
 *       algorithm state, reported by the HAL in the result metadata.
 *
 *     AF_STATE_INACTIVE: No focusing has been done, or algorithm was
 *        reset. Lens is not moving. Always the state for MODE_OFF or MODE_EDOF.
 *        When the device is opened, it must start in this state.
 *
 *     AF_STATE_PASSIVE_SCAN: A continuous focus algorithm is currently scanning
 *        for good focus. The lens is moving.
 *
 *     AF_STATE_PASSIVE_FOCUSED: A continuous focus algorithm believes it is
 *        well focused. The lens is not moving. The HAL may spontaneously leave
 *        this state.
 *
 *     AF_STATE_PASSIVE_UNFOCUSED: A continuous focus algorithm believes it is
 *        not well focused. The lens is not moving. The HAL may spontaneously
 *        leave this state.
 *
 *     AF_STATE_ACTIVE_SCAN: A scan triggered by the user is underway.
 *
 *     AF_STATE_FOCUSED_LOCKED: The AF algorithm believes it is focused. The
 *        lens is not moving.
 *
 *     AF_STATE_NOT_FOCUSED_LOCKED: The AF algorithm has been unable to
 *        focus. The lens is not moving.
 *
 *   ANDROID_CONTROL_AF_TRIGGER: Control for starting an autofocus scan, the
 *       meaning of which is mode- and state- dependent. Set by the framework in
 *       the request settings.
 *
 *     AF_TRIGGER_IDLE: No current trigger.
 *
 *     AF_TRIGGER_START: Trigger start of AF scan. Effect is mode and state
 *         dependent.
 *
 *     AF_TRIGGER_CANCEL: Cancel current AF scan if any, and reset algorithm to
 *         default.
 *
 *  Additional metadata entries:
 *
 *   ANDROID_CONTROL_AF_REGIONS: Control for selecting the regions of the FOV
 *       that should be used to determine good focus. This applies to all AF
 *       modes that scan for focus. Set by the framework in the request
 *       settings.
 *
 * S4.2. Auto-exposure settings and result entries:
 *
 *  Main metadata entries:
 *
 *   ANDROID_CONTROL_AE_MODE: Control for selecting the current auto-exposure
 *       mode. Set by the framework in the request settings.
 *
 *     AE_MODE_OFF: Autoexposure is disabled; the user controls exposure, gain,
 *         frame duration, and flash.
 *
 *     AE_MODE_ON: Standard autoexposure, with flash control disabled. User may
 *         set flash to fire or to torch mode.
 *
 *     AE_MODE_ON_AUTO_FLASH: Standard autoexposure, with flash on at HAL's
 *         discretion for precapture and still capture. User control of flash
 *         disabled.
 *
 *     AE_MODE_ON_ALWAYS_FLASH: Standard autoexposure, with flash always fired
 *         for capture, and at HAL's discretion for precapture.. User control of
 *         flash disabled.
 *
 *     AE_MODE_ON_AUTO_FLASH_REDEYE: Standard autoexposure, with flash on at
 *         HAL's discretion for precapture and still capture. Use a flash burst
 *         at end of precapture sequence to reduce redeye in the final
 *         picture. User control of flash disabled.
 *
 *   ANDROID_CONTROL_AE_STATE: Dynamic metadata describing the current AE
 *       algorithm state, reported by the HAL in the result metadata.
 *
 *     AE_STATE_INACTIVE: Initial AE state after mode switch. When the device is
 *         opened, it must start in this state.
 *
 *     AE_STATE_SEARCHING: AE is not converged to a good value, and is adjusting
 *         exposure parameters.
 *
 *     AE_STATE_CONVERGED: AE has found good exposure values for the current
 *         scene, and the exposure parameters are not changing. HAL may
 *         spontaneously leave this state to search for better solution.
 *
 *     AE_STATE_LOCKED: AE has been locked with the AE_LOCK control. Exposure
 *         values are not changing.
 *
 *     AE_STATE_FLASH_REQUIRED: The HAL has converged exposure, but believes
 *         flash is required for a sufficiently bright picture. Used for
 *         determining if a zero-shutter-lag frame can be used.
 *
 *     AE_STATE_PRECAPTURE: The HAL is in the middle of a precapture
 *         sequence. Depending on AE mode, this mode may involve firing the
 *         flash for metering, or a burst of flash pulses for redeye reduction.
 *
 *   ANDROID_CONTROL_AE_PRECAPTURE_TRIGGER: Control for starting a metering
 *       sequence before capturing a high-quality image. Set by the framework in
 *       the request settings.
 *
 *      PRECAPTURE_TRIGGER_IDLE: No current trigger.
 *
 *      PRECAPTURE_TRIGGER_START: Start a precapture sequence. The HAL should
 *         use the subsequent requests to measure good exposure/white balance
 *         for an upcoming high-resolution capture.
 *
 *  Additional metadata entries:
 *
 *   ANDROID_CONTROL_AE_LOCK: Control for locking AE controls to their current
 *       values
 *
 *   ANDROID_CONTROL_AE_EXPOSURE_COMPENSATION: Control for adjusting AE
 *       algorithm target brightness point.
 *
 *   ANDROID_CONTROL_AE_TARGET_FPS_RANGE: Control for selecting the target frame
 *       rate range for the AE algorithm. The AE routine cannot change the frame
 *       rate to be outside these bounds.
 *
 *   ANDROID_CONTROL_AE_REGIONS: Control for selecting the regions of the FOV
 *       that should be used to determine good exposure levels. This applies to
 *       all AE modes besides OFF.
 *
 * S4.3. Auto-whitebalance settings and result entries:
 *
 *  Main metadata entries:
 *
 *   ANDROID_CONTROL_AWB_MODE: Control for selecting the current white-balance
 *       mode.
 *
 *     AWB_MODE_OFF: Auto-whitebalance is disabled. User controls color matrix.
 *
 *     AWB_MODE_AUTO: Automatic white balance is enabled; 3A controls color
 *        transform, possibly using more complex transforms than a simple
 *        matrix.
 *
 *     AWB_MODE_INCANDESCENT: Fixed white balance settings good for indoor
 *        incandescent (tungsten) lighting, roughly 2700K.
 *
 *     AWB_MODE_FLUORESCENT: Fixed white balance settings good for fluorescent
 *        lighting, roughly 5000K.
 *
 *     AWB_MODE_WARM_FLUORESCENT: Fixed white balance settings good for
 *        fluorescent lighting, roughly 3000K.
 *
 *     AWB_MODE_DAYLIGHT: Fixed white balance settings good for daylight,
 *        roughly 5500K.
 *
 *     AWB_MODE_CLOUDY_DAYLIGHT: Fixed white balance settings good for clouded
 *        daylight, roughly 6500K.
 *
 *     AWB_MODE_TWILIGHT: Fixed white balance settings good for
 *        near-sunset/sunrise, roughly 15000K.
 *
 *     AWB_MODE_SHADE: Fixed white balance settings good for areas indirectly
 *        lit by the sun, roughly 7500K.
 *
 *   ANDROID_CONTROL_AWB_STATE: Dynamic metadata describing the current AWB
 *       algorithm state, reported by the HAL in the result metadata.
 *
 *     AWB_STATE_INACTIVE: Initial AWB state after mode switch. When the device
 *         is opened, it must start in this state.
 *
 *     AWB_STATE_SEARCHING: AWB is not converged to a good value, and is
 *         changing color adjustment parameters.
 *
 *     AWB_STATE_CONVERGED: AWB has found good color adjustment values for the
 *         current scene, and the parameters are not changing. HAL may
 *         spontaneously leave this state to search for better solution.
 *
 *     AWB_STATE_LOCKED: AWB has been locked with the AWB_LOCK control. Color
 *         adjustment values are not changing.
 *
 *  Additional metadata entries:
 *
 *   ANDROID_CONTROL_AWB_LOCK: Control for locking AWB color adjustments to
 *       their current values.
 *
 *   ANDROID_CONTROL_AWB_REGIONS: Control for selecting the regions of the FOV
 *       that should be used to determine good color balance. This applies only
 *       to auto-WB mode.
 *
 * S4.4. General state machine transition notes
 *
 *   Switching between AF, AE, or AWB modes always resets the algorithm's state
 *   to INACTIVE.  Similarly, switching between CONTROL_MODE or
 *   CONTROL_SCENE_MODE if CONTROL_MODE == USE_SCENE_MODE resets all the
 *   algorithm states to INACTIVE.
 *
 *   The tables below are per-mode.
 *
 * S4.5. AF state machines
 *
 *                       when enabling AF or changing AF mode
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| Any                | AF mode change| INACTIVE           |                  |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AF_MODE_OFF or AF_MODE_EDOF
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           |               | INACTIVE           | Never changes    |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AF_MODE_AUTO or AF_MODE_MACRO
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | AF_TRIGGER    | ACTIVE_SCAN        | Start AF sweep   |
 *|                    |               |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| ACTIVE_SCAN        | AF sweep done | FOCUSED_LOCKED     | If AF successful |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| ACTIVE_SCAN        | AF sweep done | NOT_FOCUSED_LOCKED | If AF successful |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| ACTIVE_SCAN        | AF_CANCEL     | INACTIVE           | Cancel/reset AF  |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_CANCEL     | INACTIVE           | Cancel/reset AF  |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_TRIGGER    | ACTIVE_SCAN        | Start new sweep  |
 *|                    |               |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_CANCEL     | INACTIVE           | Cancel/reset AF  |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_TRIGGER    | ACTIVE_SCAN        | Start new sweep  |
 *|                    |               |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| All states         | mode change   | INACTIVE           |                  |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AF_MODE_CONTINUOUS_VIDEO
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | AF_TRIGGER    | NOT_FOCUSED_LOCKED | AF state query   |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | HAL completes | PASSIVE_FOCUSED    | End AF scan      |
 *|                    | current scan  |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | HAL fails     | PASSIVE_UNFOCUSED  | End AF scan      |
 *|                    | current scan  |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_TRIGGER    | FOCUSED_LOCKED     | Immediate trans. |
 *|                    |               |                    | if focus is good |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_TRIGGER    | NOT_FOCUSED_LOCKED | Immediate trans. |
 *|                    |               |                    | if focus is bad  |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_CANCEL     | INACTIVE           | Reset lens       |
 *|                    |               |                    | position         |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_FOCUSED    | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_UNFOCUSED  | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_FOCUSED    | AF_TRIGGER    | FOCUSED_LOCKED     | Immediate trans. |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_UNFOCUSED  | AF_TRIGGER    | NOT_FOCUSED_LOCKED | Immediate trans. |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_TRIGGER    | FOCUSED_LOCKED     | No effect        |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_CANCEL     | INACTIVE           | Restart AF scan  |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_TRIGGER    | NOT_FOCUSED_LOCKED | No effect        |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_CANCEL     | INACTIVE           | Restart AF scan  |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AF_MODE_CONTINUOUS_PICTURE
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | AF_TRIGGER    | NOT_FOCUSED_LOCKED | AF state query   |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | HAL completes | PASSIVE_FOCUSED    | End AF scan      |
 *|                    | current scan  |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | HAL fails     | PASSIVE_UNFOCUSED  | End AF scan      |
 *|                    | current scan  |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_TRIGGER    | FOCUSED_LOCKED     | Eventual trans.  |
 *|                    |               |                    | once focus good  |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_TRIGGER    | NOT_FOCUSED_LOCKED | Eventual trans.  |
 *|                    |               |                    | if cannot focus  |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_SCAN       | AF_CANCEL     | INACTIVE           | Reset lens       |
 *|                    |               |                    | position         |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_FOCUSED    | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_UNFOCUSED  | HAL initiates | PASSIVE_SCAN       | Start AF scan    |
 *|                    | new scan      |                    | Lens now moving  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_FOCUSED    | AF_TRIGGER    | FOCUSED_LOCKED     | Immediate trans. |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| PASSIVE_UNFOCUSED  | AF_TRIGGER    | NOT_FOCUSED_LOCKED | Immediate trans. |
 *|                    |               |                    | Lens now locked  |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_TRIGGER    | FOCUSED_LOCKED     | No effect        |
 *+--------------------+---------------+--------------------+------------------+
 *| FOCUSED_LOCKED     | AF_CANCEL     | INACTIVE           | Restart AF scan  |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_TRIGGER    | NOT_FOCUSED_LOCKED | No effect        |
 *+--------------------+---------------+--------------------+------------------+
 *| NOT_FOCUSED_LOCKED | AF_CANCEL     | INACTIVE           | Restart AF scan  |
 *+--------------------+---------------+--------------------+------------------+
 *
 * S4.6. AE and AWB state machines
 *
 *   The AE and AWB state machines are mostly identical. AE has additional
 *   FLASH_REQUIRED and PRECAPTURE states. So rows below that refer to those two
 *   states should be ignored for the AWB state machine.
 *
 *                  when enabling AE/AWB or changing AE/AWB mode
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| Any                |  mode change  | INACTIVE           |                  |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AE_MODE_OFF / AWB mode not AUTO
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           |               | INACTIVE           | AE/AWB disabled  |
 *+--------------------+---------------+--------------------+------------------+
 *
 *                            mode = AE_MODE_ON_* / AWB_MODE_AUTO
 *| state              | trans. cause  | new state          | notes            |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | HAL initiates | SEARCHING          |                  |
 *|                    | AE/AWB scan   |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| INACTIVE           | AE/AWB_LOCK   | LOCKED             | values locked    |
 *|                    | on            |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| SEARCHING          | HAL finishes  | CONVERGED          | good values, not |
 *|                    | AE/AWB scan   |                    | changing         |
 *+--------------------+---------------+--------------------+------------------+
 *| SEARCHING          | HAL finishes  | FLASH_REQUIRED     | converged but too|
 *|                    | AE scan       |                    | dark w/o flash   |
 *+--------------------+---------------+--------------------+------------------+
 *| SEARCHING          | AE/AWB_LOCK   | LOCKED             | values locked    |
 *|                    | on            |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| CONVERGED          | HAL initiates | SEARCHING          | values locked    |
 *|                    | AE/AWB scan   |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| CONVERGED          | AE/AWB_LOCK   | LOCKED             | values locked    |
 *|                    | on            |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| FLASH_REQUIRED     | HAL initiates | SEARCHING          | values locked    |
 *|                    | AE/AWB scan   |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| FLASH_REQUIRED     | AE/AWB_LOCK   | LOCKED             | values locked    |
 *|                    | on            |                    |                  |
 *+--------------------+---------------+--------------------+------------------+
 *| LOCKED             | AE/AWB_LOCK   | SEARCHING          | values not good  |
 *|                    | off           |                    | after unlock     |
 *+--------------------+---------------+--------------------+------------------+
 *| LOCKED             | AE/AWB_LOCK   | CONVERGED          | values good      |
 *|                    | off           |                    | after unlock     |
 *+--------------------+---------------+--------------------+------------------+
 *| LOCKED             | AE_LOCK       | FLASH_REQUIRED     | exposure good,   |
 *|                    | off           |                    | but too dark     |
 *+--------------------+---------------+--------------------+------------------+
 *| All AE states      | PRECAPTURE_   | PRECAPTURE         | Start precapture |
 *|                    | START         |                    | sequence         |
 *+--------------------+---------------+--------------------+------------------+
 *| PRECAPTURE         | Sequence done.| CONVERGED          | Ready for high-  |
 *|                    | AE_LOCK off   |                    | quality capture  |
 *+--------------------+---------------+--------------------+------------------+
 *| PRECAPTURE         | Sequence done.| LOCKED             | Ready for high-  |
 *|                    | AE_LOCK on    |                    | quality capture  |
 *+--------------------+---------------+--------------------+------------------+
 *
 */

/**
 * S5. Cropping:
 *
 * Cropping of the full pixel array (for digital zoom and other use cases where
 * a smaller FOV is desirable) is communicated through the
 * ANDROID_SCALER_CROP_REGION setting. This is a per-request setting, and can
 * change on a per-request basis, which is critical for implementing smooth
 * digital zoom.
 *
 * The region is defined as a rectangle (x, y, width, height), with (x, y)
 * describing the top-left corner of the rectangle. The rectangle is defined on
 * the coordinate system of the sensor active pixel array, with (0,0) being the
 * top-left pixel of the active pixel array. Therefore, the width and height
 * cannot be larger than the dimensions reported in the
 * ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY static info field. The minimum allowed
 * width and height are reported by the HAL through the
 * ANDROID_SCALER_MAX_DIGITAL_ZOOM static info field, which describes the
 * maximum supported zoom factor. Therefore, the minimum crop region width and
 * height are:
 *
 * {width, height} =
 *    { floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[0] /
 *        ANDROID_SCALER_MAX_DIGITAL_ZOOM),
 *      floor(ANDROID_SENSOR_ACTIVE_PIXEL_ARRAY[1] /
 *        ANDROID_SCALER_MAX_DIGITAL_ZOOM) }
 *
 * If the crop region needs to fulfill specific requirements (for example, it
 * needs to start on even coordinates, and its width/height needs to be even),
 * the HAL must do the necessary rounding and write out the final crop region
 * used in the output result metadata. Similarly, if the HAL implements video
 * stabilization, it must adjust the result crop region to describe the region
 * actually included in the output after video stabilization is applied. In
 * general, a camera-using application must be able to determine the field of
 * view it is receiving based on the crop region, the dimensions of the image
 * sensor, and the lens focal length.
 *
 * It is assumed that the cropping is applied after raw to other color space
 * conversion. Raw streams (RAW16 and RAW_OPAQUE) don't have this conversion stage,
 * and are not croppable. Therefore, the crop region must be ignored by the HAL
 * for raw streams.
 *
 * Since the crop region applies to all non-raw streams, which may have different aspect
 * ratios than the crop region, the exact sensor region used for each stream may
 * be smaller than the crop region. Specifically, each stream should maintain
 * square pixels and its aspect ratio by minimally further cropping the defined
 * crop region. If the stream's aspect ratio is wider than the crop region, the
 * stream should be further cropped vertically, and if the stream's aspect ratio
 * is narrower than the crop region, the stream should be further cropped
 * horizontally.
 *
 * In all cases, the stream crop must be centered within the full crop region,
 * and each stream is only either cropped horizontally or vertical relative to
 * the full crop region, never both.
 *
 * For example, if two streams are defined, a 640x480 stream (4:3 aspect), and a
 * 1280x720 stream (16:9 aspect), below demonstrates the expected output regions
 * for each stream for a few sample crop regions, on a hypothetical 3 MP (2000 x
 * 1500 pixel array) sensor.
 *
 * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
 *
 *   640x480 stream crop: (500, 375, 1000, 750) (equal to crop region)
 *   1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
 *
 * 0                   1000               2000
 * +---------+---------+---------+----------+
 * | Active pixel array                     |
 * |                                        |
 * |                                        |
 * +         +-------------------+          + 375
 * |         |                   |          |
 * |         O===================O          |
 * |         I 1280x720 stream   I          |
 * +         I                   I          + 750
 * |         I                   I          |
 * |         O===================O          |
 * |         |                   |          |
 * +         +-------------------+          + 1125
 * |          Crop region, 640x480 stream   |
 * |                                        |
 * |                                        |
 * +---------+---------+---------+----------+ 1500
 *
 * Crop region: (500, 375, 1333, 750) (16:9 aspect ratio)
 *
 *   640x480 stream crop: (666, 375, 1000, 750) (marked with =)
 *   1280x720 stream crop: (500, 375, 1333, 750) (equal to crop region)
 *
 * 0                   1000               2000
 * +---------+---------+---------+----------+
 * | Active pixel array                     |
 * |                                        |
 * |                                        |
 * +         +---O==================O---+   + 375
 * |         |   I 640x480 stream   I   |   |
 * |         |   I                  I   |   |
 * |         |   I                  I   |   |
 * +         |   I                  I   |   + 750
 * |         |   I                  I   |   |
 * |         |   I                  I   |   |
 * |         |   I                  I   |   |
 * +         +---O==================O---+   + 1125
 * |          Crop region, 1280x720 stream  |
 * |                                        |
 * |                                        |
 * +---------+---------+---------+----------+ 1500
 *
 * Crop region: (500, 375, 750, 750) (1:1 aspect ratio)
 *
 *   640x480 stream crop: (500, 469, 750, 562) (marked with =)
 *   1280x720 stream crop: (500, 543, 750, 414) (marged with #)
 *
 * 0                   1000               2000
 * +---------+---------+---------+----------+
 * | Active pixel array                     |
 * |                                        |
 * |                                        |
 * +         +--------------+               + 375
 * |         O==============O               |
 * |         ################               |
 * |         #              #               |
 * +         #              #               + 750
 * |         #              #               |
 * |         ################ 1280x720      |
 * |         O==============O 640x480       |
 * +         +--------------+               + 1125
 * |          Crop region                   |
 * |                                        |
 * |                                        |
 * +---------+---------+---------+----------+ 1500
 *
 * And a final example, a 1024x1024 square aspect ratio stream instead of the
 * 480p stream:
 *
 * Crop region: (500, 375, 1000, 750) (4:3 aspect ratio)
 *
 *   1024x1024 stream crop: (625, 375, 750, 750) (marked with #)
 *   1280x720 stream crop: (500, 469, 1000, 562) (marked with =)
 *
 * 0                   1000               2000
 * +---------+---------+---------+----------+
 * | Active pixel array                     |
 * |                                        |
 * |              1024x1024 stream          |
 * +         +--###############--+          + 375
 * |         |  #             #  |          |
 * |         O===================O          |
 * |         I 1280x720 stream   I          |
 * +         I                   I          + 750
 * |         I                   I          |
 * |         O===================O          |
 * |         |  #             #  |          |
 * +         +--###############--+          + 1125
 * |          Crop region                   |
 * |                                        |
 * |                                        |
 * +---------+---------+---------+----------+ 1500
 *
 */

/**
 * S6. Error management:
 *
 * Camera HAL device ops functions that have a return value will all return
 * -ENODEV / NULL in case of a serious error. This means the device cannot
 * continue operation, and must be closed by the framework. Once this error is
 * returned by some method, or if notify() is called with ERROR_DEVICE, only
 * the close() method can be called successfully. All other methods will return
 * -ENODEV / NULL.
 *
 * If a device op is called in the wrong sequence, for example if the framework
 * calls configure_streams() is called before initialize(), the device must
 * return -ENOSYS from the call, and do nothing.
 *
 * Transient errors in image capture must be reported through notify() as follows:
 *
 * - The failure of an entire capture to occur must be reported by the HAL by
 *   calling notify() with ERROR_REQUEST. Individual errors for the result
 *   metadata or the output buffers must not be reported in this case.
 *
 * - If the metadata for a capture cannot be produced, but some image buffers
 *   were filled, the HAL must call notify() with ERROR_RESULT.
 *
 * - If an output image buffer could not be filled, but either the metadata was
 *   produced or some other buffers were filled, the HAL must call notify() with
 *   ERROR_BUFFER for each failed buffer.
 *
 * In each of these transient failure cases, the HAL must still call
 * process_capture_result, with valid output and input (if an input buffer was
 * submitted) buffer_handle_t. If the result metadata could not be produced, it
 * should be NULL. If some buffers could not be filled, they must be returned with
 * process_capture_result in the error state, their release fences must be set to
 * the acquire fences passed by the framework, or -1 if they have been waited on by
 * the HAL already.
 *
 * Invalid input arguments result in -EINVAL from the appropriate methods. In
 * that case, the framework must act as if that call had never been made.
 *
 */

/**
 * S7. Key Performance Indicator (KPI) glossary:
 *
 * This includes some critical definitions that are used by KPI metrics.
 *
 * Pipeline Latency:
 *  For a given capture request, the duration from the framework calling
 *  process_capture_request to the HAL sending capture result and all buffers
 *  back by process_capture_result call. To make the Pipeline Latency measure
 *  independent of frame rate, it is measured by frame count.
 *
 *  For example, when frame rate is 30 (fps), the frame duration (time interval
 *  between adjacent frame capture time) is 33 (ms).
 *  If it takes 5 frames for framework to get the result and buffers back for
 *  a given request, then the Pipeline Latency is 5 (frames), instead of
 *  5 x 33 = 165 (ms).
 *
 *  The Pipeline Latency is determined by android.request.pipelineDepth and
 *  android.request.pipelineMaxDepth, see their definitions for more details.
 *
 */

/**
 * S8. Sample Use Cases:
 *
 * This includes some typical use case examples the camera HAL may support.
 *
 * S8.1 Zero Shutter Lag (ZSL) with CAMERA3_STREAM_BIDIRECTIONAL stream.
 *
 *   For this use case, the bidirectional stream will be used by the framework as follows:
 *
 *   1. The framework includes a buffer from this stream as output buffer in a
 *      request as normal.
 *
 *   2. Once the HAL device returns a filled output buffer to the framework,
 *      the framework may do one of two things with the filled buffer:
 *
 *   2. a. The framework uses the filled data, and returns the now-used buffer
 *         to the stream queue for reuse. This behavior exactly matches the
 *         OUTPUT type of stream.
 *
 *   2. b. The framework wants to reprocess the filled data, and uses the
 *         buffer as an input buffer for a request. Once the HAL device has
 *         used the reprocessing buffer, it then returns it to the
 *         framework. The framework then returns the now-used buffer to the
 *         stream queue for reuse.
 *
 *   3. The HAL device will be given the buffer again as an output buffer for
 *        a request at some future point.
 *
 *   For ZSL use case, the pixel format for bidirectional stream will be
 *   HAL_PIXEL_FORMAT_RAW_OPAQUE or HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED if it
 *   is listed in android.scaler.availableInputOutputFormatsMap. When
 *   HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED is used, the gralloc
 *   usage flags for the consumer endpoint will be set to GRALLOC_USAGE_HW_CAMERA_ZSL.
 *   A configuration stream list that has BIDIRECTIONAL stream used as input, will
 *   usually also have a distinct OUTPUT stream to get the reprocessing data. For example,
 *   for the ZSL use case, the stream list might be configured with the following:
 *
 *     - A HAL_PIXEL_FORMAT_RAW_OPAQUE bidirectional stream is used
 *       as input.
 *     - And a HAL_PIXEL_FORMAT_BLOB (JPEG) output stream.
 *
 * S8.2 ZSL (OPAQUE) reprocessing with CAMERA3_STREAM_INPUT stream.
 *
 * CAMERA_DEVICE_API_VERSION_3_3:
 *   When OPAQUE_REPROCESSING capability is supported by the camera device, the INPUT stream
 *   can be used for application/framework implemented use case like Zero Shutter Lag (ZSL).
 *   This kind of stream will be used by the framework as follows:
 *
 *   1. Application/framework configures an opaque (RAW or YUV based) format output stream that is
 *      used to produce the ZSL output buffers. The stream pixel format will be
 *      HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
 *
 *   2. Application/framework configures an opaque format input stream that is used to
 *      send the reprocessing ZSL buffers to the HAL. The stream pixel format will
 *      also be HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED.
 *
 *   3. Application/framework configures a YUV/JPEG output stream that is used to receive the
 *      reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
 *
 *   4. Application/framework picks a ZSL buffer from the ZSL output stream when a ZSL capture is
 *      issued by the application, and sends the data back as an input buffer in a
 *      reprocessing request, then sends to the HAL for reprocessing.
 *
 *   5. The HAL sends back the output YUV/JPEG result to framework.
 *
 *   The HAL can select the actual opaque buffer format and configure the ISP pipeline
 *   appropriately based on the HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED format and
 *   the gralloc usage flag GRALLOC_USAGE_HW_CAMERA_ZSL.

 * S8.3 YUV reprocessing with CAMERA3_STREAM_INPUT stream.
 *
 *   When YUV reprocessing is supported by the HAL, the INPUT stream
 *   can be used for the YUV reprocessing use cases like lucky-shot and image fusion.
 *   This kind of stream will be used by the framework as follows:
 *
 *   1. Application/framework configures an YCbCr_420 format output stream that is
 *      used to produce the output buffers.
 *
 *   2. Application/framework configures an YCbCr_420 format input stream that is used to
 *      send the reprocessing YUV buffers to the HAL.
 *
 *   3. Application/framework configures a YUV/JPEG output stream that is used to receive the
 *      reprocessed data. The stream pixel format will be YCbCr_420/HAL_PIXEL_FORMAT_BLOB.
 *
 *   4. Application/framework processes the output buffers (could be as simple as picking
 *      an output buffer directly) from the output stream when a capture is issued, and sends
 *      the data back as an input buffer in a reprocessing request, then sends to the HAL
 *      for reprocessing.
 *
 *   5. The HAL sends back the output YUV/JPEG result to framework.
 *
 */

/**
 *   S9. Notes on Controls and Metadata
 *
 *   This section contains notes about the interpretation and usage of various metadata tags.
 *
 *   S9.1 HIGH_QUALITY and FAST modes.
 *
 *   Many camera post-processing blocks may be listed as having HIGH_QUALITY,
 *   FAST, and OFF operating modes. These blocks will typically also have an
 *   'available modes' tag representing which of these operating modes are
 *   available on a given device. The general policy regarding implementing
 *   these modes is as follows:
 *
 *   1. Operating mode controls of hardware blocks that cannot be disabled
 *      must not list OFF in their corresponding 'available modes' tags.
 *
 *   2. OFF will always be included in their corresponding 'available modes'
 *      tag if it is possible to disable that hardware block.
 *
 *   3. FAST must always be included in the 'available modes' tags for all
 *      post-processing blocks supported on the device.  If a post-processing
 *      block also has a slower and higher quality operating mode that does
 *      not meet the framerate requirements for FAST mode, HIGH_QUALITY should
 *      be included in the 'available modes' tag to represent this operating
 *      mode.
 */

/**
 *   S10. Reprocessing flow and controls
 *
 *   This section describes the OPAQUE and YUV reprocessing flow and controls. OPAQUE reprocessing
 *   uses an opaque format that is not directly application-visible, and the application can
 *   only select some of the output buffers and send back to HAL for reprocessing, while YUV
 *   reprocessing gives the application opportunity to process the buffers before reprocessing.
 *
 *   S8 gives the stream configurations for the typical reprocessing uses cases,
 *   this section specifies the buffer flow and controls in more details.
 *
 *   S10.1 OPAQUE (typically for ZSL use case) reprocessing flow and controls
 *
 *   For OPAQUE reprocessing (e.g. ZSL) use case, after the application creates the specific
 *   output and input streams, runtime buffer flow and controls are specified as below:
 *
 *   1. Application starts output streaming by sending repeating requests for output
 *      opaque buffers and preview. The buffers are held by an application
 *      maintained circular buffer. The requests are based on CAMERA3_TEMPLATE_ZERO_SHUTTER_LAG
 *      capture template, which should have all necessary settings that guarantee output
 *      frame rate is not slowed down relative to sensor output frame rate.
 *
 *   2. When a capture is issued, the application selects one output buffer based
 *      on application buffer selection logic, e.g. good AE and AF statistics etc.
 *      Application then creates an reprocess request based on the capture result associated
 *      with this selected buffer. The selected output buffer is now added to this reprocess
 *      request as an input buffer, the output buffer of this reprocess request should be
 *      either JPEG output buffer or YUV output buffer, or both, depending on the application
 *      choice.
 *
 *   3. Application then alters the reprocess settings to get best image quality. The HAL must
 *      support and only support below controls if the HAL support OPAQUE_REPROCESSING capability:
 *          - android.jpeg.* (if JPEG buffer is included as one of the output)
 *          - android.noiseReduction.mode (change to HIGH_QUALITY if it is supported)
 *          - android.edge.mode (change to HIGH_QUALITY if it is supported)
 *       All other controls must be ignored by the HAL.
 *   4. HAL processed the input buffer and return the output buffers in the capture results
 *      as normal.
 *
 *   S10.2 YUV reprocessing flow and controls
 *
 *   The YUV reprocessing buffer flow is similar as OPAQUE reprocessing, with below difference:
 *
 *   1. Application may want to have finer granularity control of the intermediate YUV images
 *      (before reprocessing). For example, application may choose
 *          - android.noiseReduction.mode == MINIMAL
 *      to make sure the no YUV domain noise reduction has applied to the output YUV buffers,
 *      then it can do its own advanced noise reduction on them. For OPAQUE reprocessing case, this
 *      doesn't matter, as long as the final reprocessed image has the best quality.
 *   2. Application may modify the YUV output buffer data. For example, for image fusion use
 *      case, where multiple output images are merged together to improve the signal-to-noise
 *      ratio (SNR). The input buffer may be generated from multiple buffers by the application.
 *      To avoid excessive amount of noise reduction and insufficient amount of edge enhancement
 *      being applied to the input buffer, the application can hint the HAL  how much effective
 *      exposure time improvement has been done by the application, then the HAL can adjust the
 *      noise reduction and edge enhancement paramters to get best reprocessed image quality.
 *      Below tag can be used for this purpose:
 *          - android.reprocess.effectiveExposureFactor
 *      The value would be exposure time increase factor applied to the original output image,
 *      for example, if there are N image merged, the exposure time increase factor would be up
 *      to sqrt(N). See this tag spec for more details.
 *
 *   S10.3 Reprocessing pipeline characteristics
 *
 *   Reprocessing pipeline has below different characteristics comparing with normal output
 *   pipeline:
 *
 *   1. The reprocessing result can be returned ahead of the pending normal output results. But
 *      the FIFO ordering must be maintained for all reprocessing results. For example, there are
 *      below requests (A stands for output requests, B stands for reprocessing requests)
 *      being processed by the HAL:
 *          A1, A2, A3, A4, B1, A5, B2, A6...
 *      result of B1 can be returned before A1-A4, but result of B2 must be returned after B1.
 *   2. Single input rule: For a given reprocessing request, all output buffers must be from the
 *      input buffer, rather than sensor output. For example, if a reprocess request include both
 *      JPEG and preview buffers, all output buffers must be produced from the input buffer
 *      included by the reprocessing request, rather than sensor. The HAL must not output preview
 *      buffers from sensor, while output JPEG buffer from the input buffer.
 *   3. Input buffer will be from camera output directly (ZSL case) or indirectly(image fusion
 *      case). For the case where buffer is modified, the size will remain same. The HAL can
 *      notify CAMERA3_MSG_ERROR_REQUEST if buffer from unknown source is sent.
 *   4. Result as reprocessing request: The HAL can expect that a reprocessing request is a copy
 *      of one of the output results with minor allowed setting changes. The HAL can notify
 *      CAMERA3_MSG_ERROR_REQUEST if a request from unknown source is issued.
 *   5. Output buffers may not be used as inputs across the configure stream boundary, This is
 *      because an opaque stream like the ZSL output stream may have different actual image size
 *      inside of the ZSL buffer to save power and bandwidth for smaller resolution JPEG capture.
 *      The HAL may notify CAMERA3_MSG_ERROR_REQUEST if this case occurs.
 *   6. HAL Reprocess requests error reporting during flush should follow the same rule specified
 *      by flush() method.
 *
 */

__BEGIN_DECLS

struct camera3_device;

/**********************************************************************
 *
 * Camera3 stream and stream buffer definitions.
 *
 * These structs and enums define the handles and contents of the input and
 * output streams connecting the HAL to various framework and application buffer
 * consumers. Each stream is backed by a gralloc buffer queue.
 *
 */

/**
 * camera3_stream_type_t:
 *
 * The type of the camera stream, which defines whether the camera HAL device is
 * the producer or the consumer for that stream, and how the buffers of the
 * stream relate to the other streams.
 */
typedef enum camera3_stream_type {
    /**
     * This stream is an output stream; the camera HAL device will be
     * responsible for filling buffers from this stream with newly captured or
     * reprocessed image data.
     */
    CAMERA3_STREAM_OUTPUT = 0,

    /**
     * This stream is an input stream; the camera HAL device will be responsible
     * for reading buffers from this stream and sending them through the camera
     * processing pipeline, as if the buffer was a newly captured image from the
     * imager.
     *
     * The pixel format for input stream can be any format reported by
     * android.scaler.availableInputOutputFormatsMap. The pixel format of the
     * output stream that is used to produce the reprocessing data may be any
     * format reported by android.scaler.availableStreamConfigurations. The
     * supported input/output stream combinations depends the camera device
     * capabilities, see android.scaler.availableInputOutputFormatsMap for
     * stream map details.
     *
     * This kind of stream is generally used to reprocess data into higher
     * quality images (that otherwise would cause a frame rate performance
     * loss), or to do off-line reprocessing.
     *
     * CAMERA_DEVICE_API_VERSION_3_3:
     *    The typical use cases are OPAQUE (typically ZSL) and YUV reprocessing,
     *    see S8.2, S8.3 and S10 for more details.
     */
    CAMERA3_STREAM_INPUT = 1,

    /**
     * This stream can be used for input and output. Typically, the stream is
     * used as an output stream, but occasionally one already-filled buffer may
     * be sent back to the HAL device for reprocessing.
     *
     * This kind of stream is meant generally for Zero Shutter Lag (ZSL)
     * features, where copying the captured image from the output buffer to the
     * reprocessing input buffer would be expensive. See S8.1 for more details.
     *
     * Note that the HAL will always be reprocessing data it produced.
     *
     */
    CAMERA3_STREAM_BIDIRECTIONAL = 2,

    /**
     * Total number of framework-defined stream types
     */
    CAMERA3_NUM_STREAM_TYPES

} camera3_stream_type_t;

/**
 * camera3_stream_rotation_t:
 *
 * The required counterclockwise rotation of camera stream.
 */
typedef enum camera3_stream_rotation {
    /* No rotation */
    CAMERA3_STREAM_ROTATION_0 = 0,

    /* Rotate by 90 degree counterclockwise */
    CAMERA3_STREAM_ROTATION_90 = 1,

    /* Rotate by 180 degree counterclockwise */
    CAMERA3_STREAM_ROTATION_180 = 2,

    /* Rotate by 270 degree counterclockwise */
    CAMERA3_STREAM_ROTATION_270 = 3
} camera3_stream_rotation_t;

/**
 * camera3_stream_configuration_mode_t:
 *
 * This defines the general operation mode for the HAL (for a given stream configuration), where
 * modes besides NORMAL have different semantics, and usually limit the generality of the API in
 * exchange for higher performance in some particular area.
 */
typedef enum camera3_stream_configuration_mode {
    /**
     * Normal stream configuration operation mode. This is the default camera operation mode,
     * where all semantics of HAL APIs and metadata controls apply.
     */
    CAMERA3_STREAM_CONFIGURATION_NORMAL_MODE = 0,

    /**
     * Special constrained high speed operation mode for devices that can not support high
     * speed output in NORMAL mode. All streams in this configuration are operating at high speed
     * mode and have different characteristics and limitations to achieve high speed output.
     * The NORMAL mode can still be used for high speed output if the HAL can support high speed
     * output while satisfying all the semantics of HAL APIs and metadata controls. It is
     * recommended for the HAL to support high speed output in NORMAL mode (by advertising the high
     * speed FPS ranges in android.control.aeAvailableTargetFpsRanges) if possible.
     *
     * This mode has below limitations/requirements:
     *
     *   1. The HAL must support up to 2 streams with sizes reported by
     *      android.control.availableHighSpeedVideoConfigurations.
     *   2. In this mode, the HAL is expected to output up to 120fps or higher. This mode must
     *      support the targeted FPS range and size configurations reported by
     *      android.control.availableHighSpeedVideoConfigurations.
     *   3. The HAL must support HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED output stream format.
     *   4. To achieve efficient high speed streaming, the HAL may have to aggregate
     *      multiple frames together and send to camera device for processing where the request
     *      controls are same for all the frames in this batch (batch mode). The HAL must support
     *      max batch size and the max batch size requirements defined by
     *      android.control.availableHighSpeedVideoConfigurations.
     *   5. In this mode, the HAL must override aeMode, awbMode, and afMode to ON, ON, and
     *      CONTINUOUS_VIDEO, respectively. All post-processing block mode controls must be
     *      overridden to be FAST. Therefore, no manual control of capture and post-processing
     *      parameters is possible. All other controls operate the same as when
     *      android.control.mode == AUTO. This means that all other android.control.* fields
     *      must continue to work, such as
     *
     *      android.control.aeTargetFpsRange
     *      android.control.aeExposureCompensation
     *      android.control.aeLock
     *      android.control.awbLock
     *      android.control.effectMode
     *      android.control.aeRegions
     *      android.control.afRegions
     *      android.control.awbRegions
     *      android.control.afTrigger
     *      android.control.aePrecaptureTrigger
     *
     *      Outside of android.control.*, the following controls must work:
     *
     *      android.flash.mode (TORCH mode only, automatic flash for still capture will not work
     *      since aeMode is ON)
     *      android.lens.opticalStabilizationMode (if it is supported)
     *      android.scaler.cropRegion
     *      android.statistics.faceDetectMode (if it is supported)
     *   6. To reduce the amount of data passed across process boundaries at
     *      high frame rate, within one batch, camera framework only propagates
     *      the last shutter notify and the last capture results (including partial
     *      results and final result) to the app. The shutter notifies and capture
     *      results for the other requests in the batch are derived by
     *      the camera framework. As a result, the HAL can return empty metadata
     *      except for the last result in the batch.