Dokumentacja struktury camera3_callback_ops

notify:

Asynchroniczne wywołanie zwrotne powiadomienia z HAL, wywoływane z różnych powodów. Tylko w przypadku informacji niezależnych od przechwytywania klatek lub wymagających określonego czasu. Własność struktury wiadomości pozostaje przy HAL, a wiadomość musi być ważna tylko przez czas trwania tego wywołania.

Wiele wątków może jednocześnie wywoływać metodę notify() .

<= CAMERA_DEVICE_API_VERSION_3_1:

Powiadomienie o rozpoczęciu ekspozycji w przypadku danego żądania musi zostać wysłane przez HAL przed pierwszym wywołaniem funkcji process_capture_result() dla tego żądania.

>= CAMERA_DEVICE_API_VERSION_3_2:

Bufory dostarczone do platformy nie będą wysyłane do warstwy aplikacji, dopóki nie zostanie odebrany znacznik czasu rozpoczęcia ekspozycji (lub znacznik czasu rozpoczęcia ekspozycji obrazu wejściowego w przypadku żądania ponownego przetwarzania) za pomocą wywołania SHUTTER notify() . Zdecydowanie zalecamy jak najszybsze wysłanie tego wywołania.

Wymagania dotyczące skuteczności:

Jest to wywołanie nieblokujące. Framework zwróci to wywołanie za 5 ms.

Definicja w wierszu 2499 w pliku camera3.h .

process_capture_result:

Przesyłanie wyników zakończonego przechwytywania do platformy. process_capture_result() może być wywoływana wielokrotnie przez HAL w odpowiedzi na pojedyncze żądanie przechwytywania. Dzięki temu np. metadane i bufory o niskiej rozdzielczości mogą być zwracane w jednym wywołaniu, a przetworzone bufory JPEG w późniejszym wywołaniu, gdy będą dostępne. Każde wywołanie musi zawierać numer klatki żądania, dla którego zwracane są metadane lub bufory.

Komponent (bufor lub metadane) pełnego wyniku może być uwzględniony tylko w jednym wywołaniu funkcji process_capture_result. Bufor dla każdego strumienia i metadane wyniku muszą być zwracane przez HAL w przypadku każdego żądania w jednym z wywołań funkcji process_capture_result, nawet w przypadku błędów powodujących powstanie niektórych danych wyjściowych. Wywołanie funkcji process_capture_result() bez buforów wyjściowych lub metadanych wyniku jest niedozwolone.

Kolejność zwracania metadanych i buforów dla pojedynczego wyniku nie ma znaczenia, ale bufory dla danego strumienia muszą być zwracane w kolejności FIFO. Bufor dla żądania 5 w przypadku strumienia A musi być zawsze zwracany przed buforem dla żądania 6 w przypadku strumienia A. Dotyczy to również metadanych wyników. Metadane żądania 5 muszą zostać zwrócone przed metadanymi żądania 6.

Poszczególne strumienie są jednak od siebie niezależne, więc jest dopuszczalne i oczekiwane, że bufor żądania 5 w strumieniu A może zostać zwrócony po buforze żądania 6 w strumieniu B. Dopuszczalne jest też, że metadane wyniku żądania 6 w strumieniu B zostaną zwrócone przed buforem żądania 5 w strumieniu A.

HAL zachowuje własność struktury wyniku, która musi być prawidłowa tylko podczas tego połączenia. Framework skopiuje wszystko, czego potrzebuje, zanim ta funkcja zwróci wartość.

Bufory wyjściowe nie muszą być jeszcze wypełnione. Framework będzie czekać na synchronizację zwolnienia bufora strumienia, zanim odczyta dane bufora. Dlatego ta metoda powinna być wywoływana przez HAL jak najszybciej, nawet jeśli niektóre lub wszystkie bufory wyjściowe są nadal wypełniane. HAL musi zawierać w każdym wpisie bufora strumienia output_buffers prawidłowe bariery synchronizacji wydania lub wartość -1, jeśli bufor strumienia jest już wypełniony.

Jeśli nie można utworzyć bufora wyników dla żądania, HAL powinien zwrócić pusty bufor metadanych, ale nadal udostępniać bufor wyjściowy i jego bariery synchronizacji. Dodatkowo należy wywołać funkcję notify() z komunikatem ERROR_RESULT.

Jeśli bufora wyjściowego nie można wypełnić, w jego polu stanu musi być ustawiona wartość STATUS_ERROR. Dodatkowo funkcja notify() musi być wywoływana z komunikatem ERROR_BUFFER.

Jeśli całe przechwytywanie się nie powiodło, tę metodę nadal trzeba wywołać, aby zwrócić bufory wyjściowe do platformy. Wszystkie stany bufora powinny mieć wartość STATUS_ERROR, a metadane wyniku powinny być pustym buforem. Dodatkowo należy wywołać funkcję notify() z komunikatem ERROR_REQUEST. W takim przypadku nie należy wysyłać poszczególnych komunikatów ERROR_RESULT/ERROR_BUFFER.

Wymagania dotyczące skuteczności:

Jest to wywołanie nieblokujące. Framework zwróci to wywołanie za 5 ms.

Opóźnienie potoku (definicja w sekcji S7) powinno być mniejsze lub równe 4 interwałom klatek i nie może przekraczać 8 interwałów klatek.

Definicja w wierszu 2466 w pliku camera3.h .