Camera3_device_ops Odniesienie do struktury
#include < camera3.h >
Pola danych | |
| int(* | zainicjuj ) (const struct kamera3_device *, const kamera3_callback_ops_t *callback_ops) |
| int(* | configure_streams )(stała struktura kamera3_urządzenie *, kamera3_stream_configuration_t *stream_list) |
| int(* | Register_stream_buffers )(const struct kamera3_device *, const kamera3_stream_buffer_set_t *buffer_set) |
| stała kamera_metadane_t *(* | const struct_default_request_settings )(const struct kamera3_device *, typ int) |
| int(* | Process_capture_request )(stała struktura kamera3_device *, kamera3_capture_request_t *request) |
| próżnia(* | get_metadata_vendor_tag_ops )(stała struktura kamera3_device *, sprzedawca_tag_query_ops_t *ops) |
| próżnia(* | zrzut )(const struct kamera3_device *, int fd) |
| int(* | równo )(stała struktura kamery3_device *) |
| próżnia * | zarezerwowane [8] |
szczegółowy opis
Dokumentacja terenowa
| int(*configure_streams)(stała struktura kamera3_device *, kamera3_stream_configuration_t *stream_list) |
skonfiguruj_strumienie:
Tylko CAMERA_DEVICE_API_VERSION_3_0:
Zresetuj potok przetwarzania urządzenia kamery HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami zdefiniowanymi w strumieniu_list. Ta metoda zostanie wywołana co najmniej raz po inicjalizacji() przed przesłaniem żądania za pomocą metody Process_capture_request() .
Lista_strumieni musi zawierać co najmniej jeden strumień z możliwością wyjścia i nie może zawierać więcej niż jednego strumienia z możliwością wejścia.
Lista strumieni może zawierać strumienie, które znajdują się również w aktualnie aktywnym zestawie strumieni (z poprzedniego wywołania konfiguracji_stream()). Te strumienie będą już miały prawidłowe wartości użycia, max_buffers i prywatny wskaźnik.
Jeżeli taki strumień ma już zarejestrowane bufory, funkcja Register_stream_buffers() nie zostanie ponownie wywołana dla strumienia, a bufory ze strumienia będą mogły zostać natychmiast uwzględnione w żądaniach wejściowych.
Jeśli warstwa HAL musi zmienić konfigurację istniejącego strumienia ze względu na nową konfigurację, może przepisać wartości użycia i/lub max_buffers podczas wywołania konfiguracyjnego.
Struktura wykryje taką zmianę, a następnie ponownie przydzieli bufory strumienia i ponownie wywoła funkcję Register_stream_buffers() przed użyciem buforów z tego strumienia w żądaniu.
Jeśli aktualnie aktywny strumień nie jest uwzględniony w liście strumieni, warstwa HAL może bezpiecznie usunąć wszelkie odniesienia do tego strumienia. Nie zostanie on ponownie użyty w późniejszym wywołaniu funkcjiconfig() przez platformę, a wszystkie bufory gralloc dla niego zostaną zwolnione po powrocie wywołania konfiguracji_streams() .
Struktura stream_list jest własnością platformy i nie można uzyskać do niej dostępu po zakończeniu tego wywołania. Adres pojedynczej struktury Camera3_stream_t pozostanie ważny dla dostępu HAL do końca pierwszego wywołania konfiguracji_stream(), które nie będzie już zawierać tej kamery3_stream_t w argumencie stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza wskaźnikiem prywatnym, z wyjątkiem elementów use i max_buffers podczas samego wywołania konfiguracji_streams() .
Jeśli strumień jest nowy, pola użycia, max_buffer i wskaźnik prywatny struktury strumienia zostaną ustawione na 0. Urządzenie HAL musi ustawić te pola, zanim wywołanie konfiguracji_streams() powróci. Pola te są następnie wykorzystywane przez platformę i moduł gralloc platformy do przydzielania buforów gralloc dla każdego strumienia.
Zanim taki nowy strumień będzie mógł uwzględnić swoje bufory w żądaniu przechwytywania, platforma wywoła metodę Register_stream_buffers() z tym strumieniem. Jednak struktura nie jest wymagana do rejestrowania buforów dla wszystkich strumieni przed przesłaniem żądania. Pozwala to na szybkie uruchomienie (na przykład) strumienia podglądu, a przydział dla innych strumieni następuje później lub jednocześnie.
Tylko CAMERA_DEVICE_API_VERSION_3_1:
Zresetuj potok przetwarzania urządzenia kamery HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami zdefiniowanymi w strumieniu_list. Ta metoda zostanie wywołana co najmniej raz po inicjalizacji() przed przesłaniem żądania za pomocą metody Process_capture_request() .
Lista_strumieni musi zawierać co najmniej jeden strumień z możliwością wyjścia i nie może zawierać więcej niż jednego strumienia z możliwością wejścia.
Lista strumieni może zawierać strumienie, które znajdują się również w aktualnie aktywnym zestawie strumieni (z poprzedniego wywołania konfiguracji_stream()). Te strumienie będą już miały prawidłowe wartości użycia, max_buffers i prywatny wskaźnik.
Jeżeli taki strumień ma już zarejestrowane bufory, funkcja Register_stream_buffers() nie zostanie ponownie wywołana dla strumienia, a bufory ze strumienia będą mogły zostać natychmiast uwzględnione w żądaniach wejściowych.
Jeśli warstwa HAL musi zmienić konfigurację istniejącego strumienia ze względu na nową konfigurację, może przepisać wartości użycia i/lub max_buffers podczas wywołania konfiguracyjnego.
Struktura wykryje taką zmianę, a następnie ponownie przydzieli bufory strumienia i ponownie wywoła funkcję Register_stream_buffers() przed użyciem buforów z tego strumienia w żądaniu.
Jeśli aktualnie aktywny strumień nie jest uwzględniony w liście strumieni, warstwa HAL może bezpiecznie usunąć wszelkie odniesienia do tego strumienia. Nie zostanie on ponownie użyty w późniejszym wywołaniu funkcjiconfig() przez platformę, a wszystkie bufory gralloc dla niego zostaną zwolnione po powrocie wywołania konfiguracji_streams() .
Struktura stream_list jest własnością platformy i nie można uzyskać do niej dostępu po zakończeniu tego wywołania. Adres pojedynczej struktury Camera3_stream_t pozostanie ważny dla dostępu HAL do końca pierwszego wywołania konfiguracji_stream(), które nie będzie już zawierać tej kamery3_stream_t w argumencie stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza wskaźnikiem prywatnym, z wyjątkiem elementów use i max_buffers podczas samego wywołania konfiguracji_streams() .
Jeśli strumień jest nowy, pola max_buffer i prywatny wskaźnik struktury strumienia zostaną ustawione na 0. Użycie zostanie ustawione na flagi użytkowania konsumenckiego. Urządzenie HAL musi ustawić te pola, zanim wywołanie konfiguracji_streams() powróci. Pola te są następnie wykorzystywane przez platformę i moduł gralloc platformy do przydzielania buforów gralloc dla każdego strumienia.
Zanim taki nowy strumień będzie mógł uwzględnić swoje bufory w żądaniu przechwytywania, platforma wywoła metodę Register_stream_buffers() z tym strumieniem. Jednak struktura nie jest wymagana do rejestrowania buforów dla wszystkich strumieni przed przesłaniem żądania. Pozwala to na szybkie uruchomienie (na przykład) strumienia podglądu, a przydział dla innych strumieni następuje później lub jednocześnie.
>= CAMERA_DEVICE_API_VERSION_3_2:
Zresetuj potok przetwarzania urządzenia kamery HAL i skonfiguruj nowe strumienie wejściowe i wyjściowe. To wywołanie zastępuje dowolną istniejącą konfigurację strumienia strumieniami zdefiniowanymi w strumieniu_list. Ta metoda zostanie wywołana co najmniej raz po inicjalizacji() przed przesłaniem żądania za pomocą metody Process_capture_request() .
Lista_strumieni musi zawierać co najmniej jeden strumień z możliwością wyjścia i nie może zawierać więcej niż jednego strumienia z możliwością wejścia.
Lista strumieni może zawierać strumienie, które znajdują się również w aktualnie aktywnym zestawie strumieni (z poprzedniego wywołania konfiguracji_stream()). Te strumienie będą już miały prawidłowe wartości użycia, max_buffers i prywatny wskaźnik.
Jeśli warstwa HAL musi zmienić konfigurację istniejącego strumienia ze względu na nową konfigurację, może przepisać wartości użycia i/lub max_buffers podczas wywołania konfiguracyjnego.
Struktura wykryje taką zmianę i może następnie ponownie przydzielić bufory strumienia przed użyciem buforów z tego strumienia w żądaniu.
Jeśli aktualnie aktywny strumień nie jest uwzględniony w liście strumieni, warstwa HAL może bezpiecznie usunąć wszelkie odniesienia do tego strumienia. Nie zostanie on ponownie użyty w późniejszym wywołaniu funkcjiconfig() przez platformę, a wszystkie bufory gralloc dla niego zostaną zwolnione po powrocie wywołania konfiguracji_streams() .
Struktura stream_list jest własnością platformy i nie można uzyskać do niej dostępu po zakończeniu tego wywołania. Adres pojedynczej struktury Camera3_stream_t pozostanie ważny dla dostępu HAL do końca pierwszego wywołania konfiguracji_stream(), które nie będzie już zawierać tej kamery3_stream_t w argumencie stream_list. HAL nie może zmieniać wartości w strukturze strumienia poza wskaźnikiem prywatnym, z wyjątkiem elementów use i max_buffers podczas samego wywołania konfiguracji_streams() .
Jeśli strumień jest nowy, pola max_buffer i prywatny wskaźnik struktury strumienia zostaną ustawione na 0. Użycie zostanie ustawione na flagi użytkowania konsumenckiego. Urządzenie HAL musi ustawić te pola, zanim wywołanie konfiguracji_streams() powróci. Pola te są następnie wykorzystywane przez platformę i moduł gralloc platformy do przydzielania buforów gralloc dla każdego strumienia.
Nowo przydzielone bufory mogą zostać uwzględnione w żądaniu przechwytywania w dowolnym momencie przez platformę. Po zwróceniu bufora gralloc do frameworka za pomocą Process_capture_result (i zasygnalizowaniu odpowiedniego release_fence), framework może go zwolnić lub ponownie wykorzystać w dowolnym momencie.
Warunki wstępne:
Struktura wywoła tę metodę tylko wtedy, gdy nie są przetwarzane żadne przechwytywania. Oznacza to, że wszystkie wyniki zostały zwrócone do struktury, wszystkie bufory wejściowe i wyjściowe w locie zostały zwrócone, a warstwy HAL zasygnalizowały bariery synchronizacji wydania. Struktura nie będzie przesyłać nowych żądań przechwytywania, gdy trwa wywołanie konfiguracji_streams() .
Warunki końcowe:
Urządzenie HAL musi się skonfigurować tak, aby zapewnić maksymalną możliwą wyjściową liczbę klatek na sekundę, biorąc pod uwagę rozmiary i formaty strumieni wyjściowych, jak udokumentowano w statycznych metadanych urządzenia kamery.
Wymagania dotyczące wydajności:
Oczekuje się, że to połączenie będzie poważne i prawdopodobnie zajmie kilkaset milisekund, ponieważ może wymagać zresetowania i ponownej konfiguracji czujnika obrazu i potoku przetwarzania kamery. Niemniej jednak urządzenie HAL powinno próbować zminimalizować opóźnienie rekonfiguracji, aby zminimalizować widoczne dla użytkownika przerwy podczas zmian trybu działania aplikacji (takich jak przełączanie z przechwytywania zdjęć na nagrywanie wideo).
HAL powinien powrócić z tego połączenia za 500 ms i musi powrócić z tego połączenia za 1000 ms.
Zwracane wartości:
0: po pomyślnej konfiguracji strumienia
-EINVAL: Jeśli żądana konfiguracja strumienia jest nieprawidłowa. Oto kilka przykładów nieprawidłowych konfiguracji strumieni:
- Zawiera więcej niż 1 strumień z możliwością wejścia (INPUT lub BIDIRECTIONAL)
- Nie obejmuje żadnych strumieni obsługujących dane wyjściowe (WYJŚCIE lub DWUKIERUNKOWE)
- Obejmuje strumienie w nieobsługiwanych formatach lub w nieobsługiwanym rozmiarze dla tego formatu.
- Uwzględniono zbyt wiele strumieni wyjściowych w określonym formacie.
- Nieobsługiwana konfiguracja rotacji (dotyczy tylko urządzeń w wersji >= CAMERA_DEVICE_API_VERSION_3_3)
- Rozmiary/formaty strumieni nie spełniają wymagań kamery3_strumienia_konfiguracji_t->trybu_operacji dla trybu innego niż NORMALNY lub żądany tryb_operacji nie jest obsługiwany przez warstwę HAL. (dotyczy tylko urządzeń w wersji >= CAMERA_DEVICE_API_VERSION_3_3)
Należy pamiętać, że struktura przesyłająca nieprawidłową konfigurację strumienia nie jest normalnym działaniem, ponieważ konfiguracje strumieni są sprawdzane przed konfiguracją. Nieprawidłowa konfiguracja oznacza, że w kodzie struktury istnieje błąd lub istnieje rozbieżność między statycznymi metadanymi warstwy 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 struktura może pomyślnie wywołać tylko funkcję Close().
| const kamera_metadata_t *(* konstrukt_default_request_settings)(const struktura kamera3_device *, typ int) |
konstruktyw_default_request_settings:
Utwórz ustawienia przechwytywania dla standardowych przypadków użycia aparatu.
Urządzenie musi zwrócić bufor ustawień skonfigurowany tak, aby spełniał żądany przypadek użycia, którym musi być jedno z wyliczeń CAMERA3_TEMPLATE_*. Wszystkie pola kontroli żądania muszą być uwzględnione.
HAL zachowuje własność tej struktury, ale wskaźnik do struktury musi być ważny do momentu zamknięcia urządzenia. Struktura i warstwa HAL nie mogą modyfikować buforu po zwróceniu go przez to wywołanie. Ten sam bufor może zostać zwrócony przy kolejnych wywołaniach tego samego szablonu lub innych szablonów.
Wymagania dotyczące wydajności:
To powinno być połączenie nieblokujące. HAL powinien powrócić z tego połączenia w ciągu 1 ms i musi powrócić z tego połączenia w ciągu 5 ms.
Zwracane wartości:
Prawidłowe metadane: Po pomyślnym utworzeniu bufora ustawień domyślnych.
NULL: W przypadku błędu krytycznego. Po zwróceniu tej wartości przez platformę można pomyślnie wywołać jedynie metodę close().
| void(* dump)(const struct kamera3_device *, int fd) |
wysypisko:
Wydrukuj stan debugowania aparatu. Zostanie to wywołane przez framework, gdy usługa kamery zostanie poproszony o zrzut debugowania, co ma miejsce podczas korzystania z narzędzia dumpsys lub podczas przechwytywania raportu o błędzie.
Przekazany deskryptor pliku może zostać użyty do zapisania tekstu debugowania za pomocą funkcji dprintf() lub write(). Tekst powinien być zapisany wyłącznie w kodowaniu ASCII.
Wymagania dotyczące wydajności:
To musi być połączenie nieblokujące. HAL powinien powrócić z tego połączenia za 1 ms, musi wrócić z tego połączenia za 10 ms. To wywołanie musi unikać zakleszczeń, ponieważ może zostać wywołane w dowolnym momencie działania kamery. Wszelkie użyte prymitywy synchronizacji (takie jak blokady muteksów lub semafory) powinny zostać uzyskane z limitem czasu.
| int(* Flush)(stała struktura kamery3_device *) |
spłukać:
Opróżnij wszystkie aktualnie trwające przechwytywania i wszystkie bufory w potoku na danym urządzeniu. Struktura użyje tego do jak najszybszego zrzucenia całego stanu w celu przygotowania wywołania konfiguracji_streams() .
Do pomyślnego zwrócenia nie są wymagane żadne bufory, więc każdy bufor przechowywany w czasie funkcji Flush() (niezależnie od tego, czy został pomyślnie wypełniony, czy nie) może zostać zwrócony z komunikatem CAMERA3_BUFFER_STATUS_ERROR. Należy zauważyć, że warstwa HAL nadal może zwracać prawidłowe bufory (CAMERA3_BUFFER_STATUS_OK) podczas tego wywołania, pod warunkiem, że zostaną pomyślnie wypełnione.
Oczekuje się, że wszystkie żądania znajdujące się obecnie w warstwie HAL zostaną zwrócone tak szybko, jak to możliwe. Żądania niebędące w procesie powinny natychmiast zwracać błędy. Należy zatrzymać wszelkie bloki sprzętowe, które można przerwać, a na bloki nieprzerywalne należy poczekać.
funkcja Flush() może być wywoływana jednocześnie z Process_capture_request() , przy założeniu, że Process_capture_request szybko powróci, a żądanie przesłane w tym wywołaniu Process_capture_request będzie traktowane jak wszystkie inne żądania w locie. Ze względu na problemy ze współbieżnością możliwe jest, że z punktu widzenia warstwy HAL wywołanie metody Process_capture_request() może zostać uruchomione po wywołaniu funkcji Flush, która jeszcze nie została zwrócona. Jeśli takie wywołanie nastąpi przed powrotem funkcji Flush() , warstwa HAL powinna potraktować nowe żądanie przechwytywania jak inne oczekujące żądania w locie (patrz punkt 4 poniżej).
Mówiąc dokładniej, HAL musi spełniać poniższe wymagania w różnych przypadkach:
- W przypadku przechwytywania, które jest już za późno na anulowanie/zatrzymanie HAL i które zostaną normalnie zakończone przez HAL; tj. HAL może normalnie wysyłać migawki/powiadomienia i Process_capture_result oraz bufory.
- W przypadku żądań oczekujących, które nie zostały przetworzone, warstwa HAL musi wywołać funkcję notify CAMERA3_MSG_ERROR_REQUEST i zwrócić wszystkie bufory wyjściowe z Process_capture_result w stanie błędu (CAMERA3_BUFFER_STATUS_ERROR). HAL nie może wprowadzać bariery zwolnienia w stan błędu, zamiast tego bariery zwolnienia muszą być ustawione na bariery nabycia przekazywane przez platformę lub -1, jeśli HAL już na nie czekał. Jest to również ścieżka, którą należy podążać w przypadku wszelkich przechwytów, dla których warstwa HAL wywołała już notify() z CAMERA3_MSG_SHUTTER, ale nie będzie generować żadnych metadanych/poprawnych buforów. Po CAMERA3_MSG_ERROR_REQUEST dla danej ramki dozwolone są tylko Process_capture_results z buforami w CAMERA3_BUFFER_STATUS_ERROR. Żadne dalsze powiadomienia ani Process_capture_result z metadanymi innymi niż null nie są dozwolone.
W przypadku częściowo ukończonych żądań oczekujących, które nie będą miały wszystkich buforów wyjściowych lub być może brakujących metadanych, warstwa HAL powinna postępować zgodnie z poniższymi wskazówkami:
3.1. Wywołaj powiadomienie za pomocą CAMERA3_MSG_ERROR_RESULT, jeśli niektóre z oczekiwanych metadanych wyników (tj. jedna lub więcej częściowych metadanych) nie będą dostępne do przechwycenia.
3.2. Wywołaj powiadomienie za pomocą CAMERA3_MSG_ERROR_BUFFER dla każdego bufora, który nie zostanie utworzony do przechwytywania.
3.3 Wywołaj powiadomienie za pomocą CAMERA3_MSG_SHUTTER ze znacznikiem czasu przechwytywania, zanim zostaną zwrócone jakiekolwiek bufory/metadane z Process_capture_result.
3.4 W przypadku przechwytywania, które przyniesie pewne rezultaty, HAL nie może wywoływać CAMERA3_MSG_ERROR_REQUEST, ponieważ oznacza to całkowitą awarię.
3.5. Prawidłowe bufory/metadane powinny być normalnie przekazywane do platformy.
3.6. Bufory, które uległy awarii, powinny zostać zwrócone do struktury zgodnie z opisem w przypadku 2. Bufory, które uległy awarii, nie muszą jednak przestrzegać ścisłej kolejności, jaką obowiązują w przypadku prawidłowych buforów i mogą być niewłaściwie uporządkowane w odniesieniu do prawidłowych buforów. Na przykład, jeśli wysłane zostaną bufory A, B, C, D, E, D i E zawiodą, wówczas A, E, B, D, C jest akceptowalnym poleceniem zwrotu.
3.7. W przypadku całkowicie brakujących metadanych wystarczy wywołać CAMERA3_MSG_ERROR_RESULT, nie ma potrzeby wywoływania Process_capture_result z metadanymi NULL lub równoważnymi.
- Jeśli funkcja Flush() zostanie wywołana, gdy wywołanie Process_capture_request() jest aktywne, to wywołanie procesu powinno powrócić tak szybko, jak to możliwe. Ponadto, jeśli wywołanie Process_capture_request() zostanie wykonane po wywołaniu funkcji Flush(), ale przed zwróceniem funkcji Flush() , żądanie przechwytywania dostarczone przez późne wywołanie Process_capture_request powinno być traktowane jak żądanie oczekujące w przypadku #2 powyżej.
funkcja Flush() powinna zostać zwrócona tylko wtedy, gdy w warstwie HAL nie ma już zaległych buforów ani żądań. Struktura może wywołaćconfigure_streams (ponieważ stan HAL jest teraz wygaszony) lub może wysyłać nowe żądania.
Należy pamiętać, że wystarczy obsługiwać tylko przypadki z wynikami, które zakończyły się pełnym sukcesem i całkowicie niepowodzeniem. Jednakże wysoce pożądane jest wspieranie również przypadków częściowych niepowodzeń, ponieważ może to pomóc w poprawie ogólnej wydajności wywołania spłukiwania.
Wymagania dotyczące wydajności:
HAL powinien powrócić z tego połączenia za 100 ms i musi powrócić z tego połączenia za 1000 ms. A to wywołanie nie może być blokowane dłużej niż opóźnienie potoku (definicja znajduje się w S7).
Informacje o wersji:
dostępne tylko w przypadku wersji urządzenia >= CAMERA_DEVICE_API_VERSION_3_1.
Zwracane wartości:
0: Po pomyślnym przepłukaniu kamery HAL.
-EINVAL: Jeśli wejście jest zniekształcone (urządzenie jest nieprawidłowe).
-ENODEV: Jeśli kamera napotkała poważny błąd. Po zwróceniu tego błędu framework może pomyślnie wywołać jedynie metodę close().
| void(* get_metadata_vendor_tag_ops)(stała struktura kamera3_device *, sprzedawca_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops:
Uzyskaj metody wysyłania zapytań o informacje o znacznikach metadanych rozszerzenia dostawcy. HAL powinna wypełnić wszystkie metody działania tagów dostawcy lub pozostawić operacje bez zmian, jeśli nie zdefiniowano żadnych tagów dostawcy.
Definicję tagu dostawcy_query_ops_t można znaleźć w pliku system/media/camera/include/system/camera_metadata.h.
>= CAMERA_DEVICE_API_VERSION_3_2: WYCOFANE. Ta funkcja jest przestarzała i powinna być ustawiona na NULL przez HAL. Zamiast tego zaimplementuj get_vendor_tag_ops w Camera_common.h .
| int(* inicjalizuj)(const struktura kamera3_device *, const kamera3_callback_ops_t *callback_ops) |
zainicjuj:
Jednorazowa inicjalizacja w celu przekazania wskaźników funkcji wywołania zwrotnego platformy do warstwy HAL. Zostanie wywołane raz po udanym wywołaniu open(), zanim zostaną wywołane jakiekolwiek inne funkcje w strukturze Camera3_device_ops .
Wymagania dotyczące wydajności:
To powinno być połączenie nieblokujące. HAL powinien powrócić z tego połączenia w ciągu 5 ms i musi powrócić z tego połączenia w ciągu 10 ms.
Zwracane wartości:
0: Po pomyślnej inicjalizacji
-ENODEV: Jeśli inicjalizacja nie powiedzie się. Dopiero po tym framework może pomyślnie wywołać funkcję Close().
| int(* Process_capture_request)(stała struktura kamera3_device *, kamera3_capture_request_t *request) |
Process_capture_request:
Wyślij nowe żądanie przechwytywania do warstwy HAL. HAL nie powinien wracać z tego wywołania, dopóki nie będzie gotowy do przyjęcia kolejnego żądania do przetworzenia. W danym momencie platforma wykona tylko jedno wywołanie metody Process_capture_request() , a wszystkie wywołania będą pochodzić z tego samego wątku. Następne wywołanie metody Process_capture_request() zostanie wykonane, gdy tylko dostępne będzie nowe żądanie i powiązane z nim bufory. W normalnym scenariuszu podglądu oznacza to, że funkcja zostanie ponownie wywołana przez platformę niemal natychmiast.
Rzeczywiste przetwarzanie żądania jest asynchroniczne, a wyniki przechwytywania są zwracane przez warstwę HAL za pośrednictwem wywołania Process_capture_result(). To wywołanie wymaga dostępności metadanych wyników, ale bufory wyjściowe mogą po prostu zapewniać bariery synchronizacji, na które należy czekać. Oczekuje się, że wiele żądań będzie przesyłanych jednocześnie, aby zachować pełną wyjściową liczbę klatek na sekundę.
Struktura zachowuje własność struktury żądań. Gwarantujemy, że będzie on ważny tylko podczas tej rozmowy. Urządzenie HAL musi wykonać kopie informacji, które musi zachować do przetwarzania przechwytywania. HAL jest odpowiedzialny za oczekiwanie i zamykanie ogrodzeń buforów oraz za powrót uchwytów buforów do szkieletu.
HAL musi zapisać deskryptor pliku dla ograniczenia synchronizacji zwolnienia bufora wejściowego w input_buffer->release_fence, jeśli input_buffer nie ma wartości NULL. Jeśli warstwa HAL zwróci -1 dla ograniczenia synchronizacji zwolnienia bufora wejściowego, platforma może natychmiast ponownie użyć bufora wejściowego. W przeciwnym razie struktura będzie czekać na ogrodzeniu synchronizacji przed ponownym wypełnieniem i ponownym użyciem bufora wejściowego.
>= CAMERA_DEVICE_API_VERSION_3_2:
Bufory wejściowe/wyjściowe zapewniane przez platformę w każdym żądaniu mogą być zupełnie nowe (nigdy wcześniej nie widziane przez warstwę HAL).
Uwagi dotyczące wydajności:
Obsługa nowego bufora powinna być wyjątkowo lekka i nie powinno wystąpić żadne pogorszenie szybkości klatek ani drgania klatek.
To wywołanie musi powrócić wystarczająco szybko, aby zapewnić utrzymanie żądanej liczby klatek na sekundę, szczególnie w przypadku przesyłania strumieniowego (ustawienia jakości przetwarzania końcowego ustawione na FAST). HAL powinien zwrócić to wywołanie w odstępie 1 ramki i musi powrócić z tego wywołania w 4 interwałach ramki.
Zwracane wartości:
0: Po pomyślnym rozpoczęciu przetwarzania żądania przechwytywania
-EINVAL: Jeśli dane wejściowe są zniekształcone (ustawienia mają wartość NULL, gdy są niedozwolone, jest 0 buforów wyjściowych itp.) i nie można rozpocząć przetwarzania przechwytywania. Błędy podczas przetwarzania żądania powinny być obsługiwane poprzez wywołanie kamery3_callback_ops_t.notify() . W przypadku tego błędu framework zachowa odpowiedzialność za ogrodzenia buforów strumienia i uchwyty buforów; warstwa HAL nie powinna zamykać ogrodzeń ani zwracać tych buforów za pomocą Process_capture_result.
-ENODEV: Jeśli kamera napotkała poważny błąd. Po zwróceniu tego błędu framework może pomyślnie wywołać jedynie metodę close().
| int(* Register_stream_buffers)(const struktura kamera3_device *, const kamera3_stream_buffer_set_t *buffer_set) |
Bufory_rejestru_streamu:
>= CAMERA_DEVICE_API_VERSION_3_2:
WYCOFANE. Nie zostanie to wywołane i musi mieć wartość NULL.
<= CAMERA_DEVICE_API_VERSION_3_1:
Zarejestruj bufory dla danego strumienia za pomocą urządzenia HAL. Ta metoda jest wywoływana przez platformę po zdefiniowaniu nowego strumienia przezconfig_streams i zanim bufory z tego strumienia zostaną uwzględnione w żądaniu przechwytywania. Jeśli ten sam strumień zostanie wymieniony w kolejnym wywołaniu funkcjiconfigure_streams() , funkcja Register_stream_buffers nie zostanie ponownie wywołana dla tego strumienia.
Struktura nie musi rejestrować buforów dla wszystkich skonfigurowanych strumieni przed przesłaniem pierwszego żądania przechwytywania. Umożliwia to szybkie uruchomienie w celu uzyskania podglądu (lub podobnych przypadków użycia), podczas gdy inne strumienie są nadal przydzielane.
Ta metoda ma na celu umożliwienie urządzeniu HAL mapowania lub innego przygotowania buforów do późniejszego użycia. Przekazane bufory będą już zablokowane do użycia. Po zakończeniu wywołania wszystkie bufory muszą być gotowe do zwrócenia do strumienia. Argument bufor_zestaw jest ważny tylko przez czas trwania tego wywołania.
Jeśli format strumienia ustawiono na HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, warstwa HAL kamery powinna sprawdzić przekazane tutaj bufory, aby określić wszelkie informacje o formacie pikseli prywatnych platformy.
Wymagania dotyczące wydajności:
To powinno być połączenie nieblokujące. HAL powinien powrócić z tego połączenia w ciągu 1 ms i musi powrócić z tego połączenia w ciągu 5 ms.
Zwracane wartości:
0: Po pomyślnej rejestracji nowych buforów strumienia
-EINVAL: Jeśli zestaw_buforów strumienia nie odnosi się do prawidłowego aktywnego strumienia lub jeśli tablica buforów jest nieprawidłowa.
-ENOMEM: Jeśli wystąpił błąd podczas rejestracji buforów. Struktura musi uznać wszystkie bufory strumieni za niezarejestrowane i może spróbować zarejestrować się ponownie później.
-ENODEV: Jeśli wystąpi błąd krytyczny i urządzenie nie będzie już działać. Po zwróceniu tego błędu struktura może pomyślnie wywołać tylko funkcję Close().
Dokumentacja tej struktury została wygenerowana z następującego pliku:
- hardware/libhardware/include/hardware/ camera3.h