tham chiếu cấu trúc camera3_device_ops
#include < camera3.h >
Trường dữ liệu | |
| int(* | khởi tạo )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
| int(* | configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
| int(* | register_stream_buffers )(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
| const camera_metadata_t *(* | constructor_default_request_settings )(const struct camera3_device *, kiểu int) |
| int(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| khoảng trống(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, nhà cung cấp_tag_query_ops_t *ops) |
| khoảng trống(* | dump )(const struct camera3_device *, int fd) |
| int(* | tuôn ra )(const struct camera3_device *) |
| trống * | dành riêng [8] |
miêu tả cụ thể
Tài liệu hiện trường
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams:
Chỉ CAMERA_DEVICE_API_VERSION_3_0:
Đặt lại quy trình xử lý thiết bị camera HAL và thiết lập luồng đầu vào và đầu ra mới. Cuộc gọi này thay thế mọi cấu hình luồng hiện có bằng các luồng được xác định trong streaming_list. Phương thức này sẽ được gọi ít nhất một lần sau khởi tạo() trước khi yêu cầu được gửi với process_capture_request() .
Stream_list phải chứa ít nhất một luồng có khả năng đầu ra và không được chứa nhiều hơn một luồng có khả năng đầu vào.
Stream_list có thể chứa các luồng cũng nằm trong nhóm luồng hiện đang hoạt động (từ lệnh gọi trước đó tới configure_stream()). Các luồng này sẽ có các giá trị hợp lệ cho mức sử dụng, max_buffers và con trỏ riêng.
Nếu luồng như vậy đã đăng ký bộ đệm, register_stream_buffers() sẽ không được gọi lại cho luồng đó và bộ đệm từ luồng có thể được đưa ngay vào yêu cầu đầu vào.
Nếu HAL cần thay đổi cấu hình luồng cho luồng hiện có do cấu hình mới, nó có thể ghi lại các giá trị sử dụng và/hoặc max_buffers trong lệnh gọi cấu hình.
Khung này sẽ phát hiện sự thay đổi như vậy, sau đó sẽ phân bổ lại bộ đệm luồng và gọi lại register_stream_buffers() trước khi sử dụng bộ đệm từ luồng đó trong một yêu cầu.
Nếu luồng hiện đang hoạt động không được đưa vào luồng_list, HAL có thể xóa mọi tham chiếu đến luồng đó một cách an toàn. Nó sẽ không được khung công tác sử dụng lại trong lệnh gọi configure() sau này và tất cả bộ đệm gralloc cho nó sẽ được giải phóng sau khi lệnh gọi configure_streams() trả về.
Cấu trúc streaming_list thuộc sở hữu của khung và không thể truy cập được sau khi lệnh gọi này hoàn tất. Địa chỉ của cấu trúc camera3_stream_t riêng lẻ sẽ vẫn hợp lệ để HAL truy cập cho đến khi kết thúc lệnh gọi configure_stream() đầu tiên không còn bao gồm camera3_stream_t đó trong đối số streaming_list nữa. HAL không được thay đổi các giá trị trong cấu trúc luồng bên ngoài con trỏ riêng, ngoại trừ các thành viên use và max_buffers trong chính lệnh gọi configure_streams() .
Nếu luồng mới, tất cả các trường sử dụng, max_buffer và con trỏ riêng của cấu trúc luồng sẽ được đặt thành 0. Thiết bị HAL phải đặt các trường này trước khi lệnh gọi configure_streams() trả về. Sau đó, các trường này được khung và mô-đun gralloc của nền tảng sử dụng để phân bổ bộ đệm gralloc cho mỗi luồng.
Trước khi một luồng mới như vậy có thể đưa bộ đệm vào yêu cầu chụp, khung sẽ gọi register_stream_buffers() với luồng đó. Tuy nhiên, khung không bắt buộc phải đăng ký bộ đệm cho tất cả các luồng trước khi gửi yêu cầu. Điều này cho phép khởi động nhanh (ví dụ) luồng xem trước, với việc phân bổ cho các luồng khác diễn ra sau hoặc đồng thời.
Chỉ CAMERA_DEVICE_API_VERSION_3_1:
Đặt lại quy trình xử lý thiết bị camera HAL và thiết lập luồng đầu vào và đầu ra mới. Cuộc gọi này thay thế mọi cấu hình luồng hiện có bằng các luồng được xác định trong streaming_list. Phương thức này sẽ được gọi ít nhất một lần sau khởi tạo() trước khi yêu cầu được gửi với process_capture_request() .
Stream_list phải chứa ít nhất một luồng có khả năng đầu ra và không được chứa nhiều hơn một luồng có khả năng đầu vào.
Stream_list có thể chứa các luồng cũng nằm trong nhóm luồng hiện đang hoạt động (từ lệnh gọi trước đó tới configure_stream()). Các luồng này sẽ có các giá trị hợp lệ cho mức sử dụng, max_buffers và con trỏ riêng.
Nếu luồng như vậy đã đăng ký bộ đệm, register_stream_buffers() sẽ không được gọi lại cho luồng đó và bộ đệm từ luồng có thể được đưa ngay vào yêu cầu đầu vào.
Nếu HAL cần thay đổi cấu hình luồng cho luồng hiện có do cấu hình mới, nó có thể ghi lại các giá trị sử dụng và/hoặc max_buffers trong lệnh gọi cấu hình.
Khung này sẽ phát hiện sự thay đổi như vậy, sau đó sẽ phân bổ lại bộ đệm luồng và gọi lại register_stream_buffers() trước khi sử dụng bộ đệm từ luồng đó trong một yêu cầu.
Nếu luồng hiện đang hoạt động không được đưa vào luồng_list, HAL có thể xóa mọi tham chiếu đến luồng đó một cách an toàn. Nó sẽ không được khung công tác sử dụng lại trong lệnh gọi configure() sau này và tất cả bộ đệm gralloc cho nó sẽ được giải phóng sau khi lệnh gọi configure_streams() trả về.
Cấu trúc streaming_list thuộc sở hữu của khung và không thể truy cập được sau khi lệnh gọi này hoàn tất. Địa chỉ của cấu trúc camera3_stream_t riêng lẻ sẽ vẫn hợp lệ để HAL truy cập cho đến khi kết thúc lệnh gọi configure_stream() đầu tiên không còn bao gồm camera3_stream_t đó trong đối số streaming_list nữa. HAL không được thay đổi các giá trị trong cấu trúc luồng bên ngoài con trỏ riêng, ngoại trừ các thành viên use và max_buffers trong chính lệnh gọi configure_streams() .
Nếu luồng là mới, max_buffer và các trường con trỏ riêng của cấu trúc luồng sẽ được đặt thành 0. Mức sử dụng sẽ được đặt thành cờ sử dụng của người tiêu dùng. Thiết bị HAL phải đặt các trường này trước khi lệnh gọi configure_streams() trả về. Sau đó, các trường này được khung và mô-đun gralloc của nền tảng sử dụng để phân bổ bộ đệm gralloc cho mỗi luồng.
Trước khi một luồng mới như vậy có thể đưa bộ đệm vào yêu cầu chụp, khung sẽ gọi register_stream_buffers() với luồng đó. Tuy nhiên, khung không bắt buộc phải đăng ký bộ đệm cho tất cả các luồng trước khi gửi yêu cầu. Điều này cho phép khởi động nhanh (ví dụ) luồng xem trước, với việc phân bổ cho các luồng khác diễn ra sau hoặc đồng thời.
>= CAMERA_DEVICE_API_VERSION_3_2:
Đặt lại quy trình xử lý thiết bị camera HAL và thiết lập luồng đầu vào và đầu ra mới. Cuộc gọi này thay thế mọi cấu hình luồng hiện có bằng các luồng được xác định trong streaming_list. Phương thức này sẽ được gọi ít nhất một lần sau khởi tạo() trước khi yêu cầu được gửi với process_capture_request() .
Stream_list phải chứa ít nhất một luồng có khả năng đầu ra và không được chứa nhiều hơn một luồng có khả năng đầu vào.
Stream_list có thể chứa các luồng cũng nằm trong nhóm luồng hiện đang hoạt động (từ lệnh gọi trước đó tới configure_stream()). Các luồng này sẽ có các giá trị hợp lệ cho mức sử dụng, max_buffers và con trỏ riêng.
Nếu HAL cần thay đổi cấu hình luồng cho luồng hiện có do cấu hình mới, nó có thể ghi lại các giá trị sử dụng và/hoặc max_buffers trong lệnh gọi cấu hình.
Khung này sẽ phát hiện sự thay đổi như vậy và sau đó có thể phân bổ lại bộ đệm luồng trước khi sử dụng bộ đệm từ luồng đó trong một yêu cầu.
Nếu luồng hiện đang hoạt động không được đưa vào luồng_list, HAL có thể xóa mọi tham chiếu đến luồng đó một cách an toàn. Nó sẽ không được khung công tác sử dụng lại trong lệnh gọi configure() sau này và tất cả bộ đệm gralloc cho nó sẽ được giải phóng sau khi lệnh gọi configure_streams() trả về.
Cấu trúc streaming_list thuộc sở hữu của khung và không thể truy cập được sau khi lệnh gọi này hoàn tất. Địa chỉ của cấu trúc camera3_stream_t riêng lẻ sẽ vẫn hợp lệ để HAL truy cập cho đến khi kết thúc lệnh gọi configure_stream() đầu tiên không còn bao gồm camera3_stream_t đó trong đối số streaming_list nữa. HAL không được thay đổi các giá trị trong cấu trúc luồng bên ngoài con trỏ riêng, ngoại trừ các thành viên use và max_buffers trong chính lệnh gọi configure_streams() .
Nếu luồng là mới, max_buffer và các trường con trỏ riêng của cấu trúc luồng sẽ được đặt thành 0. Mức sử dụng sẽ được đặt thành cờ sử dụng của người tiêu dùng. Thiết bị HAL phải đặt các trường này trước khi lệnh gọi configure_streams() trả về. Sau đó, các trường này được khung và mô-đun gralloc của nền tảng sử dụng để phân bổ bộ đệm gralloc cho mỗi luồng.
Bộ đệm mới được phân bổ có thể được đưa vào yêu cầu chụp bất kỳ lúc nào theo khung. Khi bộ đệm gralloc được trả về khung với process_capture_result (và bản phát hành_fence tương ứng của nó đã được báo hiệu), khung có thể giải phóng hoặc sử dụng lại nó bất kỳ lúc nào.
Điều kiện tiên quyết:
Khung sẽ chỉ gọi phương thức này khi không có ảnh chụp nào được xử lý. Nghĩa là, tất cả các kết quả đã được trả về khung và tất cả các bộ đệm đầu vào và đầu ra đang hoạt động đã được trả về và hàng rào đồng bộ hóa phát hành của chúng đã được HAL báo hiệu. Khung sẽ không gửi yêu cầu chụp mới trong khi lệnh gọi configure_streams() đang được thực hiện.
Hậu điều kiện:
Thiết bị HAL phải tự cấu hình để cung cấp tốc độ khung hình đầu ra tối đa có thể dựa trên kích thước và định dạng của luồng đầu ra, như được ghi trong siêu dữ liệu tĩnh của thiết bị máy ảnh.
Các yêu cầu thực hiện:
Cuộc gọi này dự kiến sẽ có dung lượng lớn và có thể mất vài trăm mili giây để hoàn thành vì nó có thể yêu cầu đặt lại và cấu hình lại cảm biến hình ảnh cũng như quy trình xử lý máy ảnh. Tuy nhiên, thiết bị HAL nên cố gắng giảm thiểu độ trễ cấu hình lại để giảm thiểu các khoảng dừng mà người dùng có thể nhìn thấy trong khi thay đổi chế độ vận hành ứng dụng (chẳng hạn như chuyển từ chụp ảnh tĩnh sang quay video).
HAL sẽ quay lại từ cuộc gọi này sau 500 mili giây và phải quay lại từ cuộc gọi này sau 1000 mili giây.
Giá trị trả về:
0: Khi cấu hình luồng thành công
-EINVAL: Nếu cấu hình luồng được yêu cầu không hợp lệ. Một số ví dụ về cấu hình luồng không hợp lệ bao gồm:
- Bao gồm nhiều hơn 1 luồng có khả năng đầu vào (INPUT hoặc BIDIRECTIONAL)
- Không bao gồm bất kỳ luồng có khả năng đầu ra nào (OUTPUT hoặc BIDIRECTIONAL)
- Bao gồm các luồng có định dạng không được hỗ trợ hoặc kích thước không được hỗ trợ cho định dạng đó.
- Bao gồm quá nhiều luồng đầu ra có định dạng nhất định.
- Cấu hình xoay không được hỗ trợ (chỉ áp dụng cho các thiết bị có phiên bản >= CAMERA_DEVICE_API_VERSION_3_3)
- Kích thước/định dạng luồng không đáp ứng các yêu cầu của camera3_stream_configuration_t->Operation_mode đối với chế độ không BÌNH THƯỜNG hoặc Operation_mode được yêu cầu không được HAL hỗ trợ. (chỉ áp dụng cho các thiết bị có phiên bản >= CAMERA_DEVICE_API_VERSION_3_3)
Lưu ý rằng khung gửi cấu hình luồng không hợp lệ không hoạt động bình thường vì cấu hình luồng được kiểm tra trước khi định cấu hình. Cấu hình không hợp lệ có nghĩa là có lỗi trong mã khung hoặc có sự không khớp giữa siêu dữ liệu tĩnh của HAL và các yêu cầu trên luồng.
-ENODEV: Nếu xảy ra lỗi nghiêm trọng và thiết bị không còn hoạt động. Chỉ close() mới có thể được gọi thành công bởi khung sau khi lỗi này được trả về.
| const camera_metadata_t *(* build_default_request_settings)(const struct camera3_device *, kiểu int) |
cấu trúc_default_request_settings:
Tạo cài đặt chụp cho các trường hợp sử dụng máy ảnh tiêu chuẩn.
Thiết bị phải trả về bộ đệm cài đặt được định cấu hình để đáp ứng trường hợp sử dụng được yêu cầu, bộ đệm này phải là một trong các enum CAMERA3_TEMPLATE_*. Tất cả các trường kiểm soát yêu cầu phải được bao gồm.
HAL giữ quyền sở hữu cấu trúc này, nhưng con trỏ tới cấu trúc phải hợp lệ cho đến khi thiết bị được đóng lại. Khung và HAL không được sửa đổi bộ đệm khi nó được lệnh gọi này trả về. Bộ đệm tương tự có thể được trả về cho các cuộc gọi tiếp theo cho cùng một mẫu hoặc cho các mẫu khác.
Các yêu cầu thực hiện:
Đây phải là cuộc gọi không chặn. HAL sẽ quay lại từ cuộc gọi này sau 1 mili giây và phải quay lại từ cuộc gọi này sau 5 mili giây.
Giá trị trả về:
Siêu dữ liệu hợp lệ: Khi tạo thành công bộ đệm cài đặt mặc định.
NULL: Trong trường hợp có lỗi nghiêm trọng. Sau khi giá trị này được trả về, chỉ có phương thức close() mới có thể được gọi thành công bởi framework.
| void(* dump)(const struct camera3_device *, int fd) |
bãi rác:
In ra trạng thái gỡ lỗi cho thiết bị camera. Điều này sẽ được khung gọi khi dịch vụ camera được yêu cầu kết xuất gỡ lỗi, điều này xảy ra khi sử dụng công cụ dumpsys hoặc khi ghi lại một báo cáo lỗi.
Bộ mô tả tệp được truyền vào có thể được sử dụng để viết văn bản gỡ lỗi bằng cách sử dụng dprintf() hoặc write(). Văn bản chỉ được ở dạng mã hóa ASCII.
Các yêu cầu thực hiện:
Đây phải là cuộc gọi không chặn. HAL sẽ quay lại từ cuộc gọi này sau 1 mili giây, phải quay lại từ cuộc gọi này sau 10 mili giây. Cuộc gọi này phải tránh tình trạng bế tắc vì nó có thể được gọi bất kỳ lúc nào trong quá trình hoạt động của camera. Bất kỳ nguyên tắc đồng bộ hóa nào được sử dụng (chẳng hạn như khóa mutex hoặc ngữ nghĩa) phải được lấy lại khi hết thời gian chờ.
| int(* tuôn ra)(const struct camera3_device *) |
tuôn ra:
Xóa tất cả các ảnh chụp hiện đang được xử lý và tất cả các bộ đệm trong đường dẫn trên thiết bị nhất định. Khung này sẽ sử dụng điều này để kết xuất tất cả trạng thái nhanh nhất có thể nhằm chuẩn bị cho lệnh gọi configure_streams() .
Không có bộ đệm nào được yêu cầu để được trả về thành công, vì vậy mọi bộ đệm được giữ tại thời điểm tuôn ra() (dù được điền thành công hay không) đều có thể được trả về bằng CAMERA3_BUFFER_STATUS_ERROR. Lưu ý rằng HAL vẫn được phép trả về bộ đệm hợp lệ (CAMERA3_BUFFER_STATUS_OK) trong cuộc gọi này, miễn là chúng được điền thành công.
Tất cả các yêu cầu hiện có trong HAL dự kiến sẽ được trả lại sớm nhất có thể. Các yêu cầu không được xử lý sẽ trả về lỗi ngay lập tức. Mọi khối phần cứng có thể bị gián đoạn phải được dừng lại và mọi khối không bị gián đoạn phải được chờ đợi.
Flush() có thể được gọi đồng thời tới process_capture_request() , với kỳ vọng rằng process_capture_request sẽ nhanh chóng quay trở lại và yêu cầu được gửi trong lệnh gọi process_capture_request đó được xử lý giống như tất cả các yêu cầu đang thực hiện khác. Do các vấn đề về tính tương tranh, có thể theo quan điểm của HAL, lệnh gọi process_capture_request() có thể được bắt đầu sau khi lệnh tuôn ra được gọi nhưng chưa được trả về. Nếu lệnh gọi như vậy xảy ra trước khi tuôn ra() trả về, HAL sẽ xử lý yêu cầu chụp mới giống như các yêu cầu đang chờ xử lý khác (xem # 4 bên dưới).
Cụ thể hơn, HAL phải tuân theo các yêu cầu dưới đây đối với nhiều trường hợp khác nhau:
- Đối với các lần chụp quá muộn để HAL có thể hủy/dừng và sẽ được HAL hoàn thành bình thường; tức là HAL có thể gửi màn trập/thông báo và process_capture_result và bộ đệm như bình thường.
- Đối với các yêu cầu đang chờ xử lý chưa thực hiện bất kỳ quá trình xử lý nào, HAL phải gọi thông báo CAMERA3_MSG_ERROR_REQUEST và trả về tất cả bộ đệm đầu ra có process_capture_result ở trạng thái lỗi (CAMERA3_BUFFER_STATUS_ERROR). HAL không được đặt hàng rào phát hành vào trạng thái lỗi, thay vào đó, hàng rào phát hành phải được đặt thành hàng rào thu được đã được khung thông qua hoặc -1 nếu chúng đã được HAL chờ đợi. Đây cũng là con đường cần tuân theo đối với bất kỳ ảnh chụp nào mà HAL đã gọi thông báo() bằng CAMERA3_MSG_SHUTTER nhưng sẽ không tạo ra bất kỳ siêu dữ liệu/bộ đệm hợp lệ nào cho chúng. Sau CAMERA3_MSG_ERROR_REQUEST, đối với một khung nhất định, chỉ cho phép process_capture_results có bộ đệm trong CAMERA3_BUFFER_STATUS_ERROR. Không được phép thông báo thêm hoặc process_capture_result có siêu dữ liệu khác null.
Đối với các yêu cầu đang chờ xử lý đã hoàn thành một phần sẽ không có tất cả bộ đệm đầu ra hoặc có thể bị thiếu siêu dữ liệu, HAL nên tuân theo bên dưới:
3.1. Hãy gọi thông báo bằng CAMERA3_MSG_ERROR_RESULT nếu một số siêu dữ liệu kết quả mong đợi (tức là một hoặc nhiều siêu dữ liệu một phần) không có sẵn để chụp.
3.2. Gọi thông báo bằng CAMERA3_MSG_ERROR_BUFFER cho mọi bộ đệm sẽ không được tạo để chụp.
3.3 Gọi thông báo bằng CAMERA3_MSG_SHUTTER kèm theo dấu thời gian chụp trước khi bất kỳ bộ đệm/siêu dữ liệu nào được trả về bằng process_capture_result.
3.4 Đối với các lần chụp sẽ tạo ra một số kết quả, HAL không được gọi CAMERA3_MSG_ERROR_REQUEST, vì điều đó cho thấy lỗi hoàn toàn.
3.5. Bộ đệm/siêu dữ liệu hợp lệ phải được chuyển vào khung như bình thường.
3.6. Bộ đệm bị lỗi phải được trả về khung như mô tả cho trường hợp 2. Nhưng bộ đệm bị lỗi không phải tuân theo thứ tự nghiêm ngặt của bộ đệm hợp lệ và có thể không đúng thứ tự đối với bộ đệm hợp lệ. Ví dụ: nếu bộ đệm A, B, C, D, E được gửi, D và E bị lỗi thì A, E, B, D, C là thứ tự trả lại được chấp nhận.
3.7. Đối với siêu dữ liệu bị thiếu hoàn toàn, gọi CAMERA3_MSG_ERROR_RESULT là đủ, không cần gọi process_capture_result với siêu dữ liệu NULL hoặc tương đương.
- Nếu lệnh tuôn ra() được gọi trong khi lệnh gọi tiến trình_capture_request() đang hoạt động, thì lệnh gọi tiến trình đó sẽ quay lại càng sớm càng tốt. Ngoài ra, nếu lệnh gọi Process_capture_request() được thực hiện sau khi lệnh Flush() được gọi nhưng trước khi lệnh Flush() quay trở lại, thì yêu cầu chụp được cung cấp bởi lệnh gọi Process_capture_request muộn sẽ được xử lý giống như một yêu cầu đang chờ xử lý trong trường hợp #2 ở trên.
Flush() chỉ nên quay lại khi không còn bộ đệm hoặc yêu cầu nào còn sót lại trong HAL. Khung có thể gọi configure_streams (vì trạng thái HAL hiện không hoạt động) hoặc có thể đưa ra các yêu cầu mới.
Lưu ý rằng chỉ cần hỗ trợ các trường hợp kết quả thành công hoàn toàn và thất bại hoàn toàn. Tuy nhiên, chúng tôi rất mong muốn hỗ trợ các trường hợp lỗi một phần vì nó có thể giúp cải thiện hiệu suất tổng thể của cuộc gọi tuôn ra.
Các yêu cầu thực hiện:
HAL sẽ quay lại từ cuộc gọi này sau 100 mili giây và phải quay lại từ cuộc gọi này sau 1000 mili giây. Và cuộc gọi này không được bị chặn lâu hơn độ trễ đường ống (xem S7 để biết định nghĩa).
Thông tin phiên bản:
chỉ khả dụng nếu phiên bản thiết bị >= CAMERA_DEVICE_API_VERSION_3_1.
Giá trị trả về:
0: Khi khởi động thành công camera HAL.
-EINVAL: Nếu đầu vào không đúng định dạng (thiết bị không hợp lệ).
-ENODEV: Nếu thiết bị camera gặp lỗi nghiêm trọng. Sau khi lỗi này được trả về, chỉ có phương thức close() mới có thể được gọi thành công bởi framework.
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, nhà cung cấp_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops:
Nhận các phương thức để truy vấn thông tin thẻ siêu dữ liệu của tiện ích mở rộng nhà cung cấp. HAL phải điền vào tất cả các phương thức hoạt động của thẻ nhà cung cấp hoặc giữ nguyên các hoạt động nếu không có thẻ nhà cung cấp nào được xác định.
Định nghĩa của nhà cung cấp_tag_query_ops_t có thể được tìm thấy trong system/media/Camera/include/system/Camera_metadata.h.
>= CAMERA_DEVICE_API_VERSION_3_2: KHÔNG DÙNG. Hàm này không được dùng nữa và phải được HAL đặt thành NULL. Thay vào đó, vui lòng triển khai get_vendor_tag_ops trong camera_common.h .
| int(* khởi tạo)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
khởi tạo:
Khởi tạo một lần để chuyển các con trỏ hàm gọi lại khung tới HAL. Sẽ được gọi một lần sau lệnh gọi open() thành công, trước khi bất kỳ chức năng nào khác được gọi trên cấu trúc camera3_device_ops .
Các yêu cầu thực hiện:
Đây phải là cuộc gọi không chặn. HAL sẽ quay lại từ cuộc gọi này sau 5 mili giây và phải quay lại từ cuộc gọi này sau 10 mili giây.
Giá trị trả về:
0: Khi khởi tạo thành công
-ENODEV: Nếu khởi tạo thất bại. Chỉ close() mới có thể được gọi thành công bởi framework sau này.
| int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request) |
process_capture_request:
Gửi yêu cầu chụp mới tới HAL. HAL sẽ không quay lại từ cuộc gọi này cho đến khi nó sẵn sàng chấp nhận yêu cầu xử lý tiếp theo. Mỗi lần khung chỉ thực hiện một lệnh gọi tới process_capture_request() và tất cả các lệnh gọi sẽ từ cùng một luồng. Cuộc gọi tiếp theo tới process_capture_request() sẽ được thực hiện ngay khi có yêu cầu mới và bộ đệm liên quan của nó. Trong kịch bản xem trước thông thường, điều này có nghĩa là hàm sẽ được khung gọi lại gần như ngay lập tức.
Quá trình xử lý yêu cầu thực tế không đồng bộ, với kết quả thu thập được HAL trả về thông qua lệnh gọi process_capture_result(). Cuộc gọi này yêu cầu phải có sẵn siêu dữ liệu kết quả, nhưng bộ đệm đầu ra có thể chỉ cung cấp hàng rào đồng bộ hóa để chờ đợi. Nhiều yêu cầu dự kiến sẽ được thực hiện cùng lúc để duy trì tốc độ khung hình đầu ra đầy đủ.
Khung này giữ quyền sở hữu cấu trúc yêu cầu. Nó chỉ được đảm bảo có hiệu lực trong cuộc gọi này. Thiết bị HAL phải tạo bản sao của thông tin cần lưu giữ để xử lý chụp. HAL chịu trách nhiệm chờ đợi và đóng hàng rào của bộ đệm và trả lại các tay cầm bộ đệm cho khung.
HAL phải ghi bộ mô tả tệp cho hàng rào đồng bộ hóa phát hành của bộ đệm đầu vào vào input_buffer->release_fence, nếu input_buffer không phải là NULL. Nếu HAL trả về -1 cho hàng rào đồng bộ hóa giải phóng bộ đệm đầu vào, khung có thể tự do sử dụng lại bộ đệm đầu vào ngay lập tức. Nếu không, khung sẽ đợi trên hàng rào đồng bộ hóa trước khi nạp lại và sử dụng lại bộ đệm đầu vào.
>= CAMERA_DEVICE_API_VERSION_3_2:
Bộ đệm đầu vào/đầu ra do khung cung cấp trong mỗi yêu cầu có thể hoàn toàn mới (HAL chưa từng thấy trước đây).
Cân nhắc về hiệu suất:
Việc xử lý bộ đệm mới phải cực kỳ nhẹ và không gây ra tình trạng suy giảm tốc độ khung hình hoặc hiện tượng jitter khung hình.
Cuộc gọi này phải quay lại đủ nhanh để đảm bảo tốc độ khung hình được yêu cầu có thể được duy trì, đặc biệt đối với các trường hợp phát trực tuyến (cài đặt chất lượng xử lý hậu kỳ được đặt thành NHANH CHÓNG). HAL sẽ trả lại cuộc gọi này sau 1 khoảng thời gian khung hình và phải quay lại từ cuộc gọi này sau 4 khoảng thời gian khung hình.
Giá trị trả về:
0: Khi bắt đầu xử lý yêu cầu chụp thành công
-EINVAL: Nếu đầu vào không đúng định dạng (cài đặt là NULL khi không được phép, có 0 bộ đệm đầu ra, v.v.) và quá trình chụp không thể bắt đầu. Các lỗi trong quá trình xử lý yêu cầu phải được xử lý bằng cách gọi camera3_callback_ops_t.notify() . Trong trường hợp xảy ra lỗi này, khung sẽ chịu trách nhiệm về hàng rào của bộ đệm luồng và bộ điều khiển bộ đệm; HAL không nên đóng hàng rào hoặc trả lại các bộ đệm này bằng process_capture_result.
-ENODEV: Nếu thiết bị camera gặp lỗi nghiêm trọng. Sau khi lỗi này được trả về, chỉ có phương thức close() mới có thể được gọi thành công bởi framework.
| int(* register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
register_stream_buffers:
>= CAMERA_DEVICE_API_VERSION_3_2:
KHÔNG ĐƯỢC DÙNG. Điều này sẽ không được gọi và phải được đặt thành NULL.
<= CAMERA_DEVICE_API_VERSION_3_1:
Đăng ký bộ đệm cho một luồng nhất định với thiết bị HAL. Phương thức này được khung gọi sau khi một luồng mới được xác định bởi configure_streams và trước khi bộ đệm từ luồng đó được đưa vào yêu cầu chụp. Nếu cùng một luồng được liệt kê trong lệnh gọi configure_streams() tiếp theo, register_stream_buffers sẽ không được gọi lại cho luồng đó.
Khung không cần phải đăng ký bộ đệm cho tất cả các luồng được định cấu hình trước khi gửi yêu cầu chụp đầu tiên. Điều này cho phép khởi động nhanh để xem trước (hoặc các trường hợp sử dụng tương tự) trong khi các luồng khác vẫn đang được phân bổ.
Phương pháp này nhằm mục đích cho phép thiết bị HAL ánh xạ hoặc chuẩn bị bộ đệm để sử dụng sau. Bộ đệm được chuyển vào sẽ bị khóa để sử dụng. Khi kết thúc cuộc gọi, tất cả bộ đệm phải sẵn sàng để được đưa trở lại luồng. Đối số buffer_set chỉ hợp lệ trong suốt thời gian của lệnh gọi này.
Nếu định dạng luồng được đặt thành HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED thì HAL của máy ảnh sẽ kiểm tra bộ đệm được chuyển vào đây để xác định mọi thông tin định dạng pixel riêng tư của nền tảng.
Các yêu cầu thực hiện:
Đây phải là cuộc gọi không chặn. HAL sẽ quay lại từ cuộc gọi này sau 1 mili giây và phải quay lại từ cuộc gọi này sau 5 mili giây.
Giá trị trả về:
0: Khi đăng ký thành công bộ đệm luồng mới
-EINVAL: Nếu luồng_buffer_set không đề cập đến luồng hoạt động hợp lệ hoặc nếu mảng bộ đệm không hợp lệ.
-ENOMEM: Nếu có lỗi trong việc đăng ký bộ đệm. Khung phải coi tất cả các bộ đệm luồng chưa được đăng ký và có thể thử đăng ký lại sau.
-ENODEV: Nếu xảy ra lỗi nghiêm trọng và thiết bị không còn hoạt động. Chỉ close() mới có thể được gọi thành công bởi khung sau khi lỗi này được trả về.
Tài liệu cho cấu trúc này được tạo từ tệp sau:
- phần cứng/libhardware/bao gồm/phần cứng/ camera3.h