Android Hardware Abstraction Layer
|void(*||process_capture_result )(const struct camera3_callback_ops *, const camera3_capture_result_t *result)|
|void(*||notify )(const struct camera3_callback_ops *, const camera3_notify_msg_t *msg)|
Asynchronous notification callback from the HAL, fired for various reasons. Only for information independent of frame capture, or that require specific timing. The ownership of the message structure remains with the HAL, and the msg only needs to be valid for the duration of this call.
The notification for the start of exposure for a given request must be sent by the HAL before the first call to process_capture_result() for that request is made.
Multiple threads may call notify() simultaneously.
|void(* process_capture_result)(const struct camera3_callback_ops *, const camera3_capture_result_t *result)|
Send results from a completed capture to the framework. process_capture_result() may be invoked multiple times by the HAL in response to a single capture request. This allows, for example, the metadata and low-resolution buffers to be returned in one call, and post-processed JPEG buffers in a later call, once it is available. Each call must include the frame number of the request it is returning metadata or buffers for.
A component (buffer or metadata) of the complete result may only be included in one process_capture_result call. A buffer for each stream, and the result metadata, must be returned by the HAL for each request in one of the process_capture_result calls, even in case of errors producing some of the output. A call to process_capture_result() with neither output buffers or result metadata is not allowed.
The order of returning metadata and buffers for a single result does not matter, but buffers for a given stream must be returned in FIFO order. So the buffer for request 5 for stream A must always be returned before the buffer for request 6 for stream A. This also applies to the result metadata; the metadata for request 5 must be returned before the metadata for request 6.
However, different streams are independent of each other, so it is acceptable and expected that the buffer for request 5 for stream A may be returned after the buffer for request 6 for stream B is. And it is acceptable that the result metadata for request 6 for stream B is returned before the buffer for request 5 for stream A is.
The HAL retains ownership of result structure, which only needs to be valid to access during this call. The framework will copy whatever it needs before this call returns.
The output buffers do not need to be filled yet; the framework will wait on the stream buffer release sync fence before reading the buffer data. Therefore, this method should be called by the HAL as soon as possible, even if some or all of the output buffers are still in being filled. The HAL must include valid release sync fences into each output_buffers stream buffer entry, or -1 if that stream buffer is already filled.
If the result buffer cannot be constructed for a request, the HAL should return an empty metadata buffer, but still provide the output buffers and their sync fences. In addition, notify() must be called with an ERROR_RESULT message.
If an output buffer cannot be filled, its status field must be set to STATUS_ERROR. In addition, notify() must be called with a ERROR_BUFFER message.
If the entire capture has failed, then this method still needs to be called to return the output buffers to the framework. All the buffer statuses should be STATUS_ERROR, and the result metadata should be an empty buffer. In addition, notify() must be called with a ERROR_REQUEST message. In this case, individual ERROR_RESULT/ERROR_BUFFER messages should not be sent.