Articles offering insights into Qualcomm's CamX architecture are relatively limited. This chapter aims to provide a comprehensive exploration of the architecture and its components in a clear and general manner. The primary topics covered in this article include:

1. Overview of the CamX architecture diagram.
2. Fundamental building blocks of CamX and their definitions.
3. Directory structure of CamX code.

I. Overview of the CamX Architecture

Modern Android devices utilizing Qualcomm chipsets employ the CamX architecture for their camera systems. Previously, the "mm-camera" architecture was used, but the main difference with CamX lies in changes to the code location—interface layer code wass moved from hardware/qcom to vendor/qcom/proprietary/.

Architecture Overview

The CamX architecture serves as an integration layer between Qualcomm's camera hardware and the HAL (Hardware Abstraction Layer). The detailed flow of camera data within CamX is visualized below:

1. Data originates from the camera sensors, enters the Image Front End (IFE), and diverges based on functionality.
   • For preview or video: The data is processed by the Image Processing Engine (IPE) before being displayed.
   • For capturing photos: The data passes through the Bayer Processing Section (BPS), followed by compression in the JPEG encoder, and finally saved.

Hardware Components:

• IFE (Image Front End): Handles the initial image processing tasks.
• IPE (Image Processing Engine): Applies transformations for preview or video output.
• BPS (Bayer Processing Section): Processes Bayer format images prior to further operations.
• JPEG Encoder: Handles compression of images during photo capture.

II. Core Elements of CamX Architecture

The CamX architecture comprises several essential components, which are outlined below:

1) UseCase

A "UseCase" combines a set of streams configured by the user with static properties dictating the processing of those streams. For reference, see the createCaptureSession method in Android's CameraDevice API. This method demonstrates how Usecase are formed.

Example:

// Example of configuring UseCase: Preview + Video
List<Surface> surfaceList = new ArrayList<>();

if (previewSurface != null && previewSurface.isValid()) {
    surfaceList.add(previewSurface);
    previewBuilder.addTarget(previewSurface);
}

if (mediaRecorderSurface != null && mediaRecorderSurface.isValid()) {
    surfaceList.add(mediaRecorderSurface);
    previewBuilder.addTarget(mediaRecorderSurface);
}

cameraDevice.createCaptureSession(surfaceList, sessionCallback, null);

Different UseCase objects handle streams for preview, video, photos, etc., creating pipelines and sessions to manage processing.

2) Feature

"Feature" represents specific camera functionalities, such as HDR, Super Night Mode, and Multi-Frame Noise Reduction (MFNR). UseCases select Features and associate corrresponding pipelines based on functional requests.

3) Node

A "Node" is an independent module with specialized processing capabilities. Nodes can represent hardware or software components and are fundamental in managing camera data pipelines.

4) Pipeline

A "Pipeline" is a sequence of interconnected Noddes that together manage resources required for specific functionalities and facilitate the flow of data.

5) Session

A "Session" contains multiple linked pipelines, serving as a control unit to oversee hardware resources, data flow, and pipeline interactions.

6) Link

"Links" define how different ports connect, specifying input and output connections between Nodes.

7) Port

Ports represent entry and exit points for data within Nodes. They are defined using XML via structures like SrcPort and DstPort.

8) Topology

"Topology" is the directed acyclic graph (DAG) representation of a camera UseCase. For CamX, the topology connects processing Nodes (hardware, software, and third-party components) into a set structure.

Component Relationships

At a higher level, UseCases manage streams and Features, which are tied to pipelines consisting of specific Nodes. These Nodes process the configured streams according to the user's requirements.

III. CamX Code Directory Structure

The CamX code resides in the vendor/qcom/proprietary/ directory and can be divided into two main sections: CamX and chi-cdk.

1) CamX Directory Overview

core/       - Contains HAL and CHI core module implementations.
hal/        - Implements HAL3 interfaces.
chi/        - Responsible for CHI-layer interactions.
hwl/        - Houses hardware-dependent algorithms managed by CSL.
swl/        - Includes software nodes reliant on CPU processing.
csl/        - Facilitates communication between CamX and camera drivers.

2) CHI-CDK Directory Overview

core/                - Implements CHI core modules and business processing.
oem/qcom/topology/   - Stores user-provided UseCase XML configuration.
oem/qcom/node/       - Contains definitions for user-specific functional Nodes.
oem/qcom/module/     - Includes sensor-specific initialization files.
oem/qcom/tuning/     - Holds configuration for scene-based effect parameters.
oem/qcom/sensor/     - Defines sensor-specific data such as registers.
oem/qcom/actuator/   - Provides focus module configuration.
oem/qcom/ois/        - Contains anti-shake module settings.
oem/qcom/flash/      - Includes flash-related configurations.
oem/qcom/eeprom/     - Stores external memory configurations.
oem/qcom/fd/         - Defines face recognition module settings.

By understanding the CamX directory structure, developers can navigate and manipulate different layers of the camera architecture effectively.