Informacje o strukturze camera3_device_ops

configure_streams:

Tylko w przypadku CAMERA_DEVICE_API_VERSION_3_0:

Zresetuj kanał przetwarzania urządzenia z kamerą HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami określonymi w pliku stream_list. Ta metoda zostanie wywołana co najmniej raz po wywołaniu metody initialize() , ale przed przesłaniem żądania za pomocą metody process_capture_request() .

Lista stream_list musi zawierać co najmniej 1 strumień z możliwością wyjścia, ale nie może zawierać więcej niż 1 strumienia z możliwością wejścia.

Lista stream_list może zawierać strumienie, które są też w obecnie aktywnym zbiorze strumieni (z poprzedniego wywołania funkcji configure_stream()). Te strumienie będą już zawierać prawidłowe wartości dla usage, max_buffers i wskaźnika prywatnego.

Jeśli takie dane zostały już zarejestrowane, funkcja register_stream_buffers() nie zostanie ponownie wywołana w przypadku tego strumienia, a bufory z tego strumienia mogą zostać natychmiast uwzględnione w żądaniach wejściowych.

Jeśli HAL musi zmienić konfigurację strumienia z powodu nowej konfiguracji, może przepisać wartości usage lub max_buffers podczas wywołania configure.

Framework wykryje taką zmianę, a następnie ponownie przydzieli bufory strumienia i ponownie wywoła funkcję register_stream_buffers() , zanim użyje buforów z tego strumienia w żądaniu.

Jeśli aktualnie aktywny strumień nie jest uwzględniony w stream_list, HAL może bezpiecznie usunąć wszystkie odwołania do tego strumienia. Nie będzie ona ponownie używana w późniejszym wywołaniu funkcji configure(), a wszystkie jej bufory gralloc zostaną zwolnione po zakończeniu działania wywołania configure_streams() .

Struktura stream_list należy do frameworku i po zakończeniu tego wywołania może nie być dostępna. Adres pojedynczej struktury camera3_stream_t będzie dostępny dla HAL do końca pierwszego wywołania configure_stream(), które nie zawiera już tego obiektu camera3_stream_t w parametry wejściowe stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza prywatnym wskaźnikiem, z wyjątkiem elementów usage i max_buffers podczas wywołania funkcji configure_streams() .

Jeśli strumień jest nowy, pola usage, max_buffer i private pointer w strukturze strumienia będą miały wartość 0. Urządzenie HAL musi ustawić te pola przed powrotem wywołania configure_streams() . Następnie te pola są używane przez framework i moduł gralloc platformy do przydzielania buforów gralloc do poszczególnych strumieni.

Zanim nowy strumień będzie mógł zawierać bufory w prośbie o przechwytywanie, framework wywoła funkcję register_stream_buffers() dla tego strumienia. Nie jest jednak wymagane rejestrowanie buforów dla wszystkich strumieni przed przesłaniem żądania. Umożliwia to szybkie uruchomienie na przykład strumienia podglądu z przydziałem na inne strumienie, które będą realizowane później lub równocześnie.

---

Tylko w przypadku CAMERA_DEVICE_API_VERSION_3_1:

Zresetuj kanał przetwarzania urządzenia z kamerą HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami określonymi w pliku stream_list. Ta metoda zostanie wywołana co najmniej raz po wywołaniu metody initialize() , ale przed przesłaniem żądania za pomocą metody process_capture_request() .

Lista stream_list musi zawierać co najmniej 1 strumień z możliwością wyjścia, ale nie może zawierać więcej niż 1 strumienia z możliwością wejścia.

Lista stream_list może zawierać strumienie, które są też w obecnie aktywnym zbiorze strumieni (z poprzedniego wywołania funkcji configure_stream()). Te strumienie będą już zawierać prawidłowe wartości dla usage, max_buffers i wskaźnika prywatnego.

Jeśli takie dane zostały już zarejestrowane, funkcja register_stream_buffers() nie zostanie ponownie wywołana w przypadku tego strumienia, a bufory z tego strumienia mogą zostać natychmiast uwzględnione w żądaniach wejściowych.

Jeśli HAL musi zmienić konfigurację strumienia z powodu nowej konfiguracji, może przepisać wartości usage lub max_buffers podczas wywołania configure.

Framework wykryje taką zmianę, a następnie ponownie przydzieli bufory strumienia i ponownie wywoła funkcję register_stream_buffers() , zanim użyje buforów z tego strumienia w żądaniu.

Jeśli aktualnie aktywny strumień nie jest uwzględniony w stream_list, HAL może bezpiecznie usunąć wszystkie odwołania do tego strumienia. Nie będzie ona ponownie używana w późniejszym wywołaniu funkcji configure(), a wszystkie jej bufory gralloc zostaną zwolnione po zakończeniu działania wywołania configure_streams() .

Struktura stream_list należy do frameworku i po zakończeniu tego wywołania może nie być dostępna. Adres pojedynczej struktury camera3_stream_t będzie dostępny dla HAL do końca pierwszego wywołania configure_stream(), które nie zawiera już tego obiektu camera3_stream_t w parametry wejściowe stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza prywatnym wskaźnikiem, z wyjątkiem elementów usage i max_buffers podczas wywołania funkcji configure_streams() .

Jeśli strumień jest nowy, pola max_buffer i private pointer w strukturze strumienia będą miały wartość 0. Użycie zostanie ustawione na flagi użycia przez konsumenta. Urządzenie HAL musi ustawić te pola przed powrotem wywołania configure_streams() . Następnie te pola są używane przez framework i moduł gralloc platformy do przydzielania buforów gralloc do poszczególnych strumieni.

Zanim nowy strumień będzie mógł zawierać bufory w prośbie o przechwytywanie, framework wywoła funkcję register_stream_buffers() dla tego strumienia. Nie jest jednak wymagane rejestrowanie buforów dla wszystkich strumieni przed przesłaniem żądania. Umożliwia to szybkie uruchomienie na przykład strumienia podglądu z przydziałem na inne strumienie, które będą realizowane później lub równocześnie.

---

>= CAMERA_DEVICE_API_VERSION_3_2:

Zresetuj kanał przetwarzania urządzenia z kamerą HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami określonymi w pliku stream_list. Ta metoda zostanie wywołana co najmniej raz po wywołaniu metody initialize() , ale przed przesłaniem żądania za pomocą metody process_capture_request() .

Lista stream_list musi zawierać co najmniej 1 strumień z możliwością wyjścia, ale nie może zawierać więcej niż 1 strumienia z możliwością wejścia.

Lista stream_list może zawierać strumienie, które są też w obecnie aktywnym zbiorze strumieni (z poprzedniego wywołania funkcji configure_stream()). Te strumienie będą już zawierać prawidłowe wartości dla usage, max_buffers i wskaźnika prywatnego.

Jeśli HAL musi zmienić konfigurację strumienia z powodu nowej konfiguracji, może przepisać wartości usage lub max_buffers podczas wywołania configure.

Framework wykryje taką zmianę i może przydzielić ponownie bufory strumienia przed użyciem buforów z tego strumienia w żądaniu.

Jeśli aktualnie aktywny strumień nie jest uwzględniony w stream_list, HAL może bezpiecznie usunąć wszystkie odwołania do tego strumienia. Nie będzie ona ponownie używana w późniejszym wywołaniu funkcji configure(), a wszystkie jej bufory gralloc zostaną zwolnione po zakończeniu działania wywołania configure_streams() .

Struktura stream_list należy do frameworku i po zakończeniu tego wywołania może nie być dostępna. Adres pojedynczej struktury camera3_stream_t będzie dostępny dla HAL do końca pierwszego wywołania configure_stream(), które nie zawiera już tego obiektu camera3_stream_t w parametry wejściowe stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza prywatnym wskaźnikiem, z wyjątkiem elementów usage i max_buffers podczas wywołania funkcji configure_streams() .

Jeśli strumień jest nowy, pola max_buffer i private pointer w strukturze strumienia będą miały wartość 0. Użycie zostanie ustawione na flagi użycia przez konsumenta. Urządzenie HAL musi ustawić te pola przed powrotem wywołania configure_streams() . Następnie te pola są używane przez framework i moduł gralloc platformy do przydzielania buforów gralloc do poszczególnych strumieni.

Nowo przydzielone bufory mogą zostać uwzględnione w żądaniu przechwytywania w dowolnym momencie. Gdy bufor gralloc zostanie zwrócony do frameworku za pomocą process_capture_result (i jego odpowiedni sygnał release_fence), framework może go w dowolnym momencie zwolnić lub ponownie użyć.

---

Warunki wstępne:

Framework wywoła tę metodę tylko wtedy, gdy nie są przetwarzane żadne przechwycenia. Oznacza to, że wszystkie wyniki zostały zwrócone do frameworku, a wszystkie bufory wejściowe i wyjściowe w trakcie przetwarzania zostały zwrócone, a ich sygnały synchronizacji zostały zwolnione przez HAL. Framework nie przesyła nowych żądań rejestrowania, gdy trwa wywołanie configure_streams() .

Warunki końcowe:

Urządzenie HAL musi skonfigurować się tak, aby zapewnić maksymalną możliwą częstotliwość klatek wyjścia, biorąc pod uwagę rozmiary i formaty strumieni wyjściowych zgodnie z statycznymi metadanymi urządzenia do rejestrowania obrazu.

Wymagania dotyczące wydajności:

To obciążające wywołanie może potrwać kilkaset milisekund, ponieważ może wymagać zresetowania i ponowniej konfiguracji czujnika obrazu oraz potoku przetwarzania w kamerze. Urządzenie HAL powinno jednak starać się zminimalizować opóźnienie rekonfiguracji, aby zminimalizować widoczne dla użytkownika przerwy podczas zmiany trybu działania aplikacji (np. przełączania z robienia zdjęć na nagrywanie wideo).

Wywołanie HAL powinno zająć 500 ms, a wywołanie HAL z powrotu – 1000 ms.

Zwracane wartości:

0: pomyślnie skonfigurowano strumień

-EINVAL: jeśli żądana konfiguracja strumienia jest nieprawidłowa. Oto kilka przykładów nieprawidłowych konfiguracji strumienia:

• zawiera więcej niż 1 strumień z możliwością przesyłania danych wejściowych (INPUT lub BIDIRECTIONAL);
• Nie obejmuje strumieni z możliwością przesyłania danych wyjściowych (OUT lub BIDIRECTIONAL).
• Obejmuje strumienie w nieobsługiwanych formatach lub w nieobsługiwanych rozmiarach.
• w tym zbyt wiele strumieni wyjściowych w określonym formacie;
• Nieobsługiwana konfiguracja rotacji (dotyczy tylko urządzeń z wersją >= CAMERA_DEVICE_API_VERSION_3_3)
• Rozmiary lub formaty strumienia nie spełniają wymagań camera3_stream_configuration_t->operation_mode w przypadku trybu innego niż NORMAL lub żądany tryb operation_mode nie jest obsługiwany przez komponent HAL. (dotyczy tylko urządzeń z wersją >= CAMERA_DEVICE_API_VERSION_3_3)

Pamiętaj, że przesyłanie nieprawidłowej konfiguracji strumienia nie jest normalnym działaniem, ponieważ konfiguracje strumieni są sprawdzane przed konfiguracją. Nieprawidłowa konfiguracja oznacza, że w kodzie frameworku występuje błąd lub występuje niezgodność między statyczną metadanymi HAL a wymaganiami dotyczącymi strumieni.

-ENODEV: jeśli wystąpił błąd krytyczny i urządzenie nie działa. Po zwróceniu tego błędu framework może wywołać tylko close().

Definicja w wierszu 2769 pliku camera3.h .

construct_default_request_settings:

Utwórz ustawienia rejestrowania zdjęć na potrzeby standardowych zastosowań aparatu.

Urządzenie musi zwrócić bufor ustawień skonfigurowany tak, aby spełniał wymagania dotyczące przypadku użycia, który musi być jednym z wartości wyliczenia CAMERA3_TEMPLATE_ *. Należy uwzględnić wszystkie pola sterujące żądaniem.

HAL zachowuje własność tej struktury, ale wskaźnik do niej musi być prawidłowy do czasu zamknięcia urządzenia. Framework i HAL nie mogą modyfikować bufora po jego zwróceniu przez ten wywołanie. Ten sam bufor może zostać zwrócony w kolejnych wywołaniach tego samego szablonu lub innych szablonów.

Wymagania dotyczące wydajności:

Powinien to być nieblokujący wywołania. Interfejs HAL powinien wrócić z tego wywołania w 1 ms, a musi wrócić w 5 ms.

Zwracane wartości:

Prawidłowe metadane: po utworzeniu bufora domyślnych ustawień.

NULL: w przypadku błędu krytycznego. Po zwróceniu tej wartości framework może wywołać tylko metodę close().

Definicja w wierszu 2859 w pliku camera3.h .

zrzut:

Wydrukuj stan debugowania urządzenia z kamerą. Ta metoda zostanie wywołana przez framework, gdy usługa aparatu otrzyma prośbę o zrzut debugowania. Dzieje się tak, gdy używasz narzędzia dumpsys lub gdy rejestrujesz raport o błędach.

Przekazany deskryptor pliku może służyć do zapisywania tekstu debugowania za pomocą funkcji dprintf() lub write(). Tekst powinien być zapisany tylko w kodowaniu ASCII.

Wymagania dotyczące wydajności:

Musi to być wywołanie nieblokujące. Interfejs HAL powinien zwrócić wynik tego wywołania w 1 ms, a musi to nastąpić w 10 ms. Wywołanie tej metody musi zapobiegać blokadom, ponieważ może być wywoływane w dowolnym momencie podczas działania aparatu. Wszystkie używane obiekty synchronizacji (np. blokady mutex lub semafora) powinny być pozyskiwane z czasem oczekiwania.

Definicja w wierszu 2971 w pliku camera3.h .

flush:

Wyczyść wszystkie obecnie przetwarzane przechwycenia i wszystkie bufory w potoku na danym urządzeniu. Framework użyje tego do jak najszybszego zrzutu wszystkich stanów w celu przygotowania się do wywołania configure_streams() .

Nie trzeba zwracać żadnych buforów, więc każdy bufor przechowywany w momencie wywołania funkcji flush() (niezależnie od tego, czy został wypełniony) może zostać zwrócony z wartością CAMERA3_BUFFER_STATUS_ERROR. Pamiętaj, że komponent HAL może nadal zwracać prawidłowe (CAMERA3_BUFFER_STATUS_OK) bufory podczas tego wywołania, pod warunkiem że są one wypełnione.

Wszystkie żądania obecnie oczekujące w HAL zostaną jak najszybciej rozpatrzone. W przypadku żądań, które nie są w trakcie przetwarzania, błędy powinny być zwracane natychmiast. Wszystkie blokady sprzętowe, które można przerwać, powinny zostać zatrzymane, a blokady, których nie można przerwać, powinny być oczekujące.

flush() może być wywoływany równolegle z  process_capture_request() , z oczekiwaniem, że process_capture_request zwróci szybko i że żądanie przesłane w tym wywołaniu process_capture_request jest traktowane jak wszystkie inne żądania w trakcie przetwarzania. Ze względu na problemy z jednoczestronnością możliwe, że z punktu widzenia HAL wywołanie process_capture_request() może zostać rozpoczęte po wywołaniu flush, ale jeszcze nie zwrócone. Jeśli takie wywołanie nastąpi przed powrotem funkcji flush() , HAL powinien traktować nowe żądanie rejestrowania jak inne oczekujące żądania (patrz punkt 4 poniżej).

W szczególności w różnych przypadkach HAL musi spełniać te wymagania:

1. W przypadku przechwyceń, które HAL nie może anulować ani zatrzymać, HAL wykona je normalnie. Oznacza to, że HAL może wysłać shutter/notify i process_capture_result oraz buforować dane w zwykły sposób.
2. W przypadku oczekujących żądań, które nie zostały jeszcze przetworzone, interfejs HAL musi wywołać funkcję notify CAMERA3_MSG_ERROR_REQUEST i zwrócić wszystkie bufory wyjściowe z wartością process_capture_result w stanie błędu (CAMERA3_BUFFER_STATUS_ERROR). HAL nie może ustawić bariery zwalniającej w stanie błędu. Bariera zwalniająca musi być ustawiona na bariery pozyskiwania przekazane przez framework lub -1, jeśli HAL już na nie czekał. Ta ścieżka jest też odpowiednia w przypadku wszystkich ujęć, dla których interfejs HAL wywołał już funkcję notify() z parametrem CAMERA3_MSG_SHUTTER, ale nie będzie generować metadanych ani prawidłowych buforów. Po wywołaniu CAMERA3_MSG_ERROR_REQUEST w przypadku danego kadru dozwolone są tylko wywołania process_capture_results z buforami w CAMERA3_BUFFER_STATUS_ERROR. Niedozwolone są żadne dodatkowe notifys ani process_capture_result z niepustymi metadanymi.

3. W przypadku częściowo ukończonych oczekujących żądań, które nie będą zawierać wszystkich buforów wyjściowych lub w których brakuje metadanych, HAL powinien wyglądać tak:

   3.1. Zadzwoń z komandom CAMERA3_MSG_ERROR_RESULT, jeśli niektóre oczekiwane metadane (czyli co najmniej 1 częściowy zestaw metadanych) nie będą dostępne do przechwycenia.

   3.2. Wywołaj notify z CAMERA3_MSG_ERROR_BUFFER dla każdego bufora, który nie zostanie wygenerowany w ramach przechwytywania.

   3.3 Wywołaj notify z CAMERA3_MSG_SHUTTER z czasem znacznika czasu przechwycenia przed zwróceniem dowolnych buforów lub metadanych za pomocą process_capture_result.

   3.4 W przypadku przechwyceń, które dają jakiś wynik, interfejs HAL nie może wywoływać metody CAMERA3_MSG_ERROR_REQUEST, ponieważ oznacza to całkowitą porażkę.

   3.5. Do frameworku należy przekazywać prawidłowe bufory i metadane.

   3.6. Nieudane bufory powinny zostać zwrócone do frameworku zgodnie z opisem w przypadku 2. Nieudane bufory nie muszą być uporządkowane zgodnie z ścisłymi zasadami porządkowania prawidłowych buforów i mogą być nieuporządkowane w stosunku do prawidłowych buforów. Jeśli na przykład wysłane zostały bufory A, B, C, D i E, a D i E zakończyły się niepowodzeniem, akceptowalną kolejność odesłania jest A, E, B, D, C.

   3.7. W przypadku braku metadanych wystarczy wywołać CAMERA3_MSG_ERROR_RESULT. Nie trzeba wywoływać process_capture_result z metadanymi NULL ani ich odpowiednikiem.

4. Jeśli wywołanie funkcji flush() jest aktywne, gdy wywołanie funkcji process_capture_request() jest aktywne, wywołanie procesu powinno zwrócić wynik tak szybko, jak to możliwe. Dodatkowo, jeśli wywołanie funkcji process_capture_request() nastąpiło po wywołaniu funkcji flush() ale przed powrotem funkcji flush() , żądanie przechwycenia przekazane przez opóźnione wywołanie funkcji process_capture_request należy traktować jak oczekujące żądanie w przypadku 2 powyżej.

flush() powinna zwracać wartość tylko wtedy, gdy w HAL nie ma już oczekujących buforów ani żądań. Framework może wywołać configure_streams (ponieważ stan HAL jest teraz w stanie spoczynku) lub może wysłać nowe żądania.

Pamiętaj, że wystarczy uwzględnić tylko przypadki, w których wszystkie testy zakończyły się sukcesem lub niepowodzeniem. Zalecamy jednak, aby obsługiwać również przypadki częściowego niepowodzenia, ponieważ może to pomóc w zwiększeniu ogólnej skuteczności wywołania czyszczenia.

Wymagania dotyczące wydajności:

Wywołanie HAL powinno zająć 100 ms, a wywołanie zwrotne powinno zająć 1000 ms. Wywołanie nie może być zablokowane dłużej niż czas oczekiwania na odpowiedź (patrz definicja w sekcji 7).

Informacje o wersji:

dostępne tylko wtedy, gdy wersja urządzenia >= CAMERA_DEVICE_API_VERSION_3_1.

Zwracane wartości:

0: po pomyślnym opróżnieniu bufora HAL aparatu.

-EINVAL: jeśli dane wejściowe są nieprawidłowe (urządzenie jest nieprawidłowe).

-ENODEV: jeśli wystąpił poważny błąd w kamerze. Po zwróceniu tego błędu framework może wywołać tylko metodę close().

Definicja w wierszu 3077 pliku camera3.h .

get_metadata_vendor_tag_ops:

Poznaj metody uzyskiwania informacji o metadanych tagów rozszerzeń dostawcy. HAL powinien wypełnić wszystkie metody operacji tagu dostawcy lub pozostawić opcje bez zmian, jeśli nie zdefiniowano żadnych tagów dostawcy.

Definicję vendor_tag_query_ops_t znajdziesz w pliku system/media/camera/include/system/camera_metadata.h.

>= CAMERA_DEVICE_API_VERSION_3_2: DEPRECATED. Ta funkcja została wycofana i powinna być ustawiona przez HAL na NULL. Zamiast tego użyj funkcji get_vendor_tag_ops w pliku camera_common.h .

Definicja w wierszu 2950 w pliku camera3.h .

initialize:

Jednorazowa inicjalizacja służąca do przekazywania do HAL wskaźników funkcji wywołania zwrotnego frameworka. Jest wywoływany raz po pomyślnym wywołaniu open(), zanim zostaną wywołane inne funkcje w strukturze camera3_device_ops .

Wymagania dotyczące wydajności:

Powinien to być wywołanie nieblokujące. Interfejs HAL powinien wrócić z tego wywołania w 5 ms, a musi wrócić w 10 ms.

Zwracane wartości:

0: po pomyślnej inicjalizowaniu

-ENODEV: błąd inicjowania. Od tego momentu framework może wywołać tylko close().

Definicja w wierszu 2530 pliku camera3.h .

process_capture_request:

Wyślij nowe żądanie rejestrowania do HAL. Interfejs HAL nie powinien wracać z tego wywołania, dopóki nie będzie gotowy do przyjęcia kolejnego żądania do przetworzenia. Framework wykona tylko jedno wywołanie funkcji process_capture_request() w danym momencie, a wszystkie wywołania będą pochodzić z tego samego wątku. Następne wywołanie funkcji process_capture_request() zostanie wykonane, gdy tylko pojawi się nowe żądanie i powiązane z nim bufory. W normalnym scenariuszu podglądu oznacza to, że framework wywoła funkcję ponownie niemal natychmiast.

Przetwarzanie żądania jest asynchroniczne, a wyniki przechwycenia są zwracane przez HAL za pomocą wywołania process_capture_result(). To wywołanie wymaga dostępu do metadanych wyniku, ale bufory wyjściowe mogą po prostu udostępniać bariery synchronizacji, na które należy poczekać. Oczekuje się, że wiele żądań będzie wysyłanych jednocześnie, aby utrzymać pełną częstotliwość klatek wyjściowych.

Struktura pozostaje własnością frameworka. Gwarantujemy, że będzie ona ważna tylko w trakcie tego połączenia. Urządzenie HAL musi tworzyć kopie informacji, które musi zachować na potrzeby przetwarzania danych. HAL odpowiada za oczekiwanie na zamknięcie buforów i zwrot uchwytów buforów do frameworku.

HAL musi zapisać deskryptor pliku dla ogrodzenia synchronizacji uwalniania dla bufora wejściowego do input_buffer->release_fence, jeśli input_buffer nie jest NULL. Jeśli interfejs HAL zwróci wartość -1 dla ogrodzenia synchronizacji uwalniania bufora wejściowego, framework może od razu ponownie użyć bufora wejściowego. W przeciwnym razie framework będzie czekać na synchronizację przed uzupełnieniem i ponownym użyciem bufora danych wejściowych.

>= CAMERA_DEVICE_API_VERSION_3_2:

Bufory wejścia/wyjścia udostępniane przez framework w każdej prośbie mogą być zupełnie nowe (czyli nieznane HAL).

---

Uwagi dotyczące wydajności:

Obsługa nowego bufora powinna być bardzo lekka i nie powinno dojść do pogorszenia liczby klatek na sekundę ani do wprowadzania zniekształceń.

Ten wywołanie musi być wykonywane wystarczająco szybko, aby można było utrzymać wymaganą częstotliwość klatek, zwłaszcza w przypadku strumieniowego przesyłania danych (ustawienia jakości postprodukcji ustawione na FAST). Interfejs HAL powinien zwracać to wywołanie w odstępie 1 ramki, a z niego w odstępie 4 ramek.

Zwracane wartości:

0: pomyślnie rozpocząć przetwarzanie żądania przechwycenia

-EINVAL: jeśli dane wejściowe są nieprawidłowe (ustawienia są NULL, gdy nie jest to dozwolone, jest 0 buforów wyjściowych itp.), a przetwarzanie nie może się rozpocząć. Błędy występujące podczas przetwarzania żądania należy obsługiwać, wywołując funkcję camera3_callback_ops_t.notify() . W przypadku tego błędu framework będzie nadal odpowiedzialny za bariery i uchwyty buforów buforów strumienia. HAL nie powinien zamykać barier ani zwracać tych buforów za pomocą funkcji process_capture_result.

-ENODEV: jeśli wystąpił poważny błąd w kamerze. Po zwróceniu tego błędu framework może wywołać tylko metodę close().

Definicja w wierszu 2928 pliku camera3.h .

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

WYCOFANY. Nie będzie on wywoływany i musi mieć wartość NULL.

<= CAMERA_DEVICE_API_VERSION_3_1:

Rejestrowanie buforów dla danego strumienia w urządzeniu HAL. Ta metoda jest wywoływana przez framework po zdefiniowaniu nowej strumienia przez configure_streams i przed uwzględnieniem buforów z tego strumienia w żądaniu rejestrowania. Jeśli ten sam strumień jest wymieniony w kolejnym wywołaniu funkcji configure_streams() , funkcja register_stream_buffers nie zostanie wywołana ponownie dla tego strumienia.

Zanim framework prześle pierwsze żądanie przechwytywania, nie musi rejestrować buforów dla wszystkich skonfigurowanych strumieni. Umożliwia to szybkie uruchamianie podglądu (lub podobnych przypadków użycia) podczas przydzielania innych strumieni.

Ta metoda ma umożliwić urządzeniu HAL mapowanie lub przygotowanie buforów na potrzeby późniejszego użycia. Przekazane bufory będą już zablokowane do użycia. Na koniec połączenia wszystkie bufory muszą być gotowe do przekazania do strumienia. Argument buffer_set jest prawidłowy tylko przez czas trwania tego wywołania.

Jeśli format strumienia został ustawiony na HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, interfejs HAL aparatu powinien sprawdzić przekazane bufory, aby określić informacje o formatach pikseli prywatnych dla danej platformy.

Wymagania dotyczące wydajności:

Powinien to być nieblokujący wywołania. Interfejs HAL powinien wrócić z tego wywołania w 1 ms, a musi wrócić w 5 ms.

Zwracane wartości:

0: po pomyślnym zarejestrowaniu nowych buforów strumieni danych

-EINVAL: jeśli stream_buffer_set nie odnosi się do aktywnego strumienia lub tablica buffers jest nieprawidłowa.

-ENOMEM: jeśli wystąpił błąd podczas rejestrowania buforów. Framework musi uznać wszystkie bufory strumieni za niezarejestrowane i może spróbować zarejestrować je ponownie później.

-ENODEV: jeśli wystąpił błąd krytyczny i urządzenie nie działa. Po zwróceniu tego błędu framework może wywołać tylko close().

Definicja w wierszu 2823 pliku camera3.h .

Definicja w wierszu 3080 w pliku camera3.h .