camera3_callback_ops Odniesienie do struktury

notyfikować:

Asynchroniczne wywołanie zwrotne powiadomienia z warstwy HAL, uruchamiane z różnych powodów. Tylko dla informacji niezależnych od przechwytywania klatek lub wymagających określonego czasu. Struktura wiadomości pozostaje własnością warstwy HAL, a komunikat musi być ważny tylko na czas trwania tego wywołania.

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

<= CAMERA_DEVICE_API_VERSION_3_1:

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

> = CAMERA_DEVICE_API_VERSION_3_2:

Bufory dostarczone do frameworka nie zostaną wysłane do warstwy aplikacji, dopóki znacznik czasu początku ekspozycji (lub znacznik czasu początku ekspozycji obrazu wejściowego dla żądania ponownego przetwarzania) nie zostanie odebrany za pośrednictwem wywołania SHUTTER notify () . Zdecydowanie zalecamy jak najszybsze wysłanie tego wezwania.

Wymagania dotyczące wydajności:

To jest połączenie bez blokowania. Framework zwróci to wezwanie w ciągu 5 ms.

Definicja w linii 2499 pliku camera3.h .

process_capture_result:

Wyślij wyniki z ukończonego przechwytywania do platformy. process_capture_result () może być wywoływana wielokrotnie przez warstwę HAL w odpowiedzi na pojedyncze żądanie przechwytywania. Pozwala to na przykład na zwrócenie metadanych i buforów o niskiej rozdzielczości w jednym wywołaniu, a po przetworzeniu buforów JPEG w późniejszym wywołaniu, gdy będą dostępne. Każde wywołanie musi zawierać numer ramki żądania, dla którego zwraca metadane lub bufory.

Składnik (bufor lub metadane) pełnego wyniku może być zawarty tylko w jednym wywołaniu process_capture_result. Bufor dla każdego strumienia i metadane wyników muszą zostać zwrócone przez warstwę HAL dla każdego żądania w jednym z wywołań process_capture_result, nawet w przypadku błędów generujących część wyników. Wywołanie 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. Zatem bufor dla żądania 5 dla strumienia A musi zawsze być zwrócony przed buforem dla żądania 6 dla strumienia A. Dotyczy to również metadanych wyniku; metadane żądania 5 muszą zostać zwrócone przed metadanymi żądania 6.

Jednak różne strumienie są od siebie niezależne, więc jest dopuszczalne i oczekuje się, że bufor dla żądania 5 dla strumienia A może zostać zwrócony za buforem dla żądania 6 dla strumienia B. Dopuszczalne jest, aby metadane wyniku dla żądania 6 dla strumienia B były zwracane przed buforem dla żądania 5 dla strumienia A.

Warstwa HAL zachowuje własność struktury wyników, która musi być ważna tylko w celu uzyskania dostępu podczas tego wywołania. Framework skopiuje wszystko, czego potrzebuje, zanim to wywołanie powróci.

Bufory wyjściowe nie muszą być jeszcze wypełnione; Framework będzie czekał na ogrodzenie synchronizacji zwalniania bufora strumienia przed odczytaniem danych bufora. Dlatego ta metoda powinna zostać wywołana przez warstwę HAL tak szybko, jak to możliwe, nawet jeśli niektóre lub wszystkie bufory wyjściowe są nadal zapełniane. Warstwa HAL musi zawierać prawidłowe ogrodzenia synchronizacji wydania do każdego wpisu buforu strumienia output_buffers lub wartość -1, jeśli ten bufor strumienia jest już wypełniony.

Jeśli nie można skonstruować buforu wynikowego dla żądania, warstwa HAL powinna zwrócić pusty bufor metadanych, ale nadal zapewniać bufory wyjściowe i ich ogrodzenia synchronizacji. Dodatkowo funkcja notify () musi zostać wywołana z komunikatem ERROR_RESULT.

Jeśli nie można zapełnić bufora wyjściowego, jego pole statusu musi mieć wartość STATUS_ERROR. Dodatkowo funkcja notify () musi zostać wywołana z komunikatem ERROR_BUFFER.

Jeśli całe przechwytywanie nie powiodło się, ta metoda nadal musi zostać wywołana, aby zwrócić bufory wyjściowe do struktury. Wszystkie statusy buforów powinny mieć wartość STATUS_ERROR, a metadane wyników powinny być pustym buforem. Dodatkowo funkcja notify () musi zostać wywołana z komunikatem ERROR_REQUEST. W takim przypadku pojedyncze komunikaty ERROR_RESULT / ERROR_BUFFER nie powinny być wysyłane.

Wymagania dotyczące wydajności:

To jest połączenie bez blokowania. Framework zwróci to wezwanie w ciągu 5 ms.

Opóźnienie potoku (patrz definicja S7) powinno być mniejsze lub równe 4 interwałom ramek i musi być mniejsze lub równe 8 interwałom ramek.

Definicja w wierszu 2466 pliku camera3.h .