camera3_device_ops Strukturreferenz
#include < camera3.h >
Datenfelder | |
| int(* | initialisieren )(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 *(* | construction_default_request_settings )(const struct camera3_device *, int type) |
| int(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| Leere(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, seller_tag_query_ops_t *ops) |
| Leere(* | dump )(const struct camera3_device *, int fd) |
| int(* | bündig )(const struct camera3_device *) |
| Leere * | reserviert [8] |
detaillierte Beschreibung
Felddokumentation
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams:
Nur CAMERA_DEVICE_API_VERSION_3_0:
Setzen Sie die Verarbeitungspipeline des HAL-Kamerageräts zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Dieser Aufruf ersetzt jede vorhandene Stream-Konfiguration durch die in der stream_list definierten Streams. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() übermittelt wird.
Die stream_list muss mindestens einen ausgabefähigen Stream enthalten und darf nicht mehr als einen eingabefähigen Stream enthalten.
Die stream_list kann Streams enthalten, die sich auch im aktuell aktiven Satz von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams verfügen bereits über gültige Werte für die Nutzung, max_buffers und den privaten Zeiger.
Wenn die Puffer eines solchen Streams bereits registriert wurden, wird register_stream_buffers() für den Stream nicht erneut aufgerufen und Puffer aus dem Stream können sofort in Eingabeanforderungen einbezogen werden.
Wenn die HAL aufgrund der neuen Konfiguration die Stream-Konfiguration für einen vorhandenen Stream ändern muss, schreibt sie möglicherweise die Werte von „usage“ und/oder „max_buffers“ während des configure-Aufrufs neu.
Das Framework erkennt eine solche Änderung, weist dann die Stream-Puffer neu zu und ruft erneut register_stream_buffers() auf, bevor Puffer aus diesem Stream in einer Anfrage verwendet werden.
Wenn ein aktuell aktiver Stream nicht in stream_list enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Es wird in einem späteren Aufruf von configure() durch das Framework nicht wiederverwendet und alle Gralloc-Puffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückkehrt.
Die stream_list-Struktur ist Eigentum des Frameworks und nach Abschluss dieses Aufrufs darf nicht mehr darauf zugegriffen werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten configure_stream()-Aufrufs gültig, der diesen camera3_stream_t nicht mehr im Argument stream_list enthält. Die HAL darf keine Werte in der Stream-Struktur außerhalb des privaten Zeigers ändern, mit Ausnahme der Usage- und max_buffers-Mitglieder während des configure_streams() -Aufrufs selbst.
Wenn der Stream neu ist, werden die Felder „Usage“, „max_buffer“ und „Private Pointer“ der Stream-Struktur alle auf 0 gesetzt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf „configure_streams()“ zurückkehrt. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Puffer für jeden Stream zuzuweisen.
Bevor die Puffer eines solchen neuen Streams in eine Erfassungsanforderung einbezogen werden können, ruft das Framework register_stream_buffers() mit diesem Stream auf. Das Framework ist jedoch nicht verpflichtet, Puffer für alle Streams zu registrieren, bevor eine Anfrage gesendet wird. Dies ermöglicht den schnellen Start (zum Beispiel) eines Vorschau-Streams, wobei die Zuweisung für andere Streams später oder gleichzeitig erfolgt.
Nur CAMERA_DEVICE_API_VERSION_3_1:
Setzen Sie die Verarbeitungspipeline des HAL-Kamerageräts zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Dieser Aufruf ersetzt jede vorhandene Stream-Konfiguration durch die in der stream_list definierten Streams. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() übermittelt wird.
Die stream_list muss mindestens einen ausgabefähigen Stream enthalten und darf nicht mehr als einen eingabefähigen Stream enthalten.
Die stream_list kann Streams enthalten, die sich auch im aktuell aktiven Satz von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams verfügen bereits über gültige Werte für die Nutzung, max_buffers und den privaten Zeiger.
Wenn die Puffer eines solchen Streams bereits registriert wurden, wird register_stream_buffers() für den Stream nicht erneut aufgerufen und Puffer aus dem Stream können sofort in Eingabeanforderungen einbezogen werden.
Wenn die HAL aufgrund der neuen Konfiguration die Stream-Konfiguration für einen vorhandenen Stream ändern muss, schreibt sie möglicherweise die Werte von „usage“ und/oder „max_buffers“ während des configure-Aufrufs neu.
Das Framework erkennt eine solche Änderung, weist dann die Stream-Puffer neu zu und ruft erneut register_stream_buffers() auf, bevor Puffer aus diesem Stream in einer Anfrage verwendet werden.
Wenn ein aktuell aktiver Stream nicht in stream_list enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Es wird in einem späteren Aufruf von configure() durch das Framework nicht wiederverwendet und alle Gralloc-Puffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückkehrt.
Die stream_list-Struktur ist Eigentum des Frameworks und nach Abschluss dieses Aufrufs darf nicht mehr darauf zugegriffen werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten configure_stream()-Aufrufs gültig, der diesen camera3_stream_t nicht mehr im Argument stream_list enthält. Die HAL darf keine Werte in der Stream-Struktur außerhalb des privaten Zeigers ändern, mit Ausnahme der Usage- und max_buffers-Mitglieder während des configure_streams() -Aufrufs selbst.
Wenn der Stream neu ist, werden die Felder „max_buffer“ und „Private Pointer“ der Stream-Struktur alle auf 0 gesetzt. Die Nutzung wird auf die Verbrauchernutzungsflags gesetzt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf configure_streams() zurückkehrt. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Puffer für jeden Stream zuzuweisen.
Bevor die Puffer eines solchen neuen Streams in eine Erfassungsanforderung einbezogen werden können, ruft das Framework register_stream_buffers() mit diesem Stream auf. Das Framework ist jedoch nicht verpflichtet, Puffer für alle Streams zu registrieren, bevor eine Anfrage gesendet wird. Dies ermöglicht den schnellen Start (zum Beispiel) eines Vorschau-Streams, wobei die Zuweisung für andere Streams später oder gleichzeitig erfolgt.
>= CAMERA_DEVICE_API_VERSION_3_2:
Setzen Sie die Verarbeitungspipeline des HAL-Kamerageräts zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Dieser Aufruf ersetzt jede vorhandene Stream-Konfiguration durch die in der stream_list definierten Streams. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() übermittelt wird.
Die stream_list muss mindestens einen ausgabefähigen Stream enthalten und darf nicht mehr als einen eingabefähigen Stream enthalten.
Die stream_list kann Streams enthalten, die sich auch im aktuell aktiven Satz von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams verfügen bereits über gültige Werte für die Nutzung, max_buffers und den privaten Zeiger.
Wenn die HAL aufgrund der neuen Konfiguration die Stream-Konfiguration für einen vorhandenen Stream ändern muss, schreibt sie möglicherweise die Werte von „usage“ und/oder „max_buffers“ während des configure-Aufrufs neu.
Das Framework erkennt eine solche Änderung und kann dann die Stream-Puffer neu zuweisen, bevor Puffer aus diesem Stream in einer Anfrage verwendet werden.
Wenn ein aktuell aktiver Stream nicht in stream_list enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Es wird in einem späteren Aufruf von configure() durch das Framework nicht wiederverwendet und alle Gralloc-Puffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückkehrt.
Die stream_list-Struktur ist Eigentum des Frameworks und nach Abschluss dieses Aufrufs darf nicht mehr darauf zugegriffen werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten configure_stream()-Aufrufs gültig, der diesen camera3_stream_t nicht mehr im Argument stream_list enthält. Die HAL darf keine Werte in der Stream-Struktur außerhalb des privaten Zeigers ändern, mit Ausnahme der Usage- und max_buffers-Mitglieder während des configure_streams() -Aufrufs selbst.
Wenn der Stream neu ist, werden die Felder „max_buffer“ und „Private Pointer“ der Stream-Struktur alle auf 0 gesetzt. Die Nutzung wird auf die Verbrauchernutzungsflags gesetzt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf configure_streams() zurückkehrt. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Puffer für jeden Stream zuzuweisen.
Neu zugewiesene Puffer können vom Framework jederzeit in eine Erfassungsanforderung einbezogen werden. Sobald ein Gralloc-Puffer mit „process_capture_result“ an das Framework zurückgegeben wird (und sein jeweiliger „release_fence“ signalisiert wurde), kann das Framework ihn jederzeit freigeben oder wiederverwenden.
Voraussetzungen:
Das Framework ruft diese Methode nur auf, wenn keine Erfassungen verarbeitet werden. Das heißt, alle Ergebnisse wurden an das Framework zurückgegeben, und alle laufenden Eingabe- und Ausgabepuffer wurden zurückgegeben und ihre Freigabe-Synchronisierungsgrenzen wurden von der HAL signalisiert. Während der Aufruf von configure_streams() ausgeführt wird, sendet das Framework keine neuen Anforderungen zur Erfassung.
Nachbedingungen:
Das HAL-Gerät muss sich selbst so konfigurieren, dass es angesichts der Größen und Formate der Ausgabeströme, wie in den statischen Metadaten des Kamerageräts dokumentiert, die maximal mögliche Ausgabebildrate bietet.
Leistungsanforderungen:
Es wird erwartet, dass dieser Aufruf umfangreich ist und möglicherweise mehrere hundert Millisekunden in Anspruch nimmt, da er möglicherweise ein Zurücksetzen und Neukonfigurieren des Bildsensors und der Kameraverarbeitungspipeline erfordert. Dennoch sollte das HAL-Gerät versuchen, die Neukonfigurationsverzögerung zu minimieren, um die für den Benutzer sichtbaren Pausen während Änderungen des Anwendungsbetriebsmodus (z. B. beim Wechsel von der Standbildaufnahme zur Videoaufzeichnung) zu minimieren.
Der HAL sollte von diesem Aufruf in 500 ms zurückkehren und muss von diesem Aufruf in 1.000 ms zurückkehren.
Rückgabewerte:
0: Bei erfolgreicher Stream-Konfiguration
-EINVAL: Wenn die angeforderte Stream-Konfiguration ungültig ist. Einige Beispiele für ungültige Stream-Konfigurationen sind:
- Einschließlich mehr als 1 eingabefähigen Stream (INPUT oder BIDIRECTIONAL)
- Ohne ausgabefähige Streams (OUTPUT oder BIDIRECTIONAL)
- Einschließlich Streams mit nicht unterstützten Formaten oder einer für dieses Format nicht unterstützten Größe.
- Einschließlich zu vieler Ausgabestreams eines bestimmten Formats.
- Nicht unterstützte Rotationskonfiguration (gilt nur für Geräte mit Version >= CAMERA_DEVICE_API_VERSION_3_3)
- Streamgrößen/-formate erfüllen nicht die camera3_stream_configuration_t->operation_mode-Anforderungen für den nicht NORMALEN Modus, oder der angeforderte operation_mode wird von der HAL nicht unterstützt. (gilt nur für Geräte mit Version >= CAMERA_DEVICE_API_VERSION_3_3)
Beachten Sie, dass das Senden einer ungültigen Stream-Konfiguration durch das Framework kein normaler Vorgang ist, da Stream-Konfigurationen vor der Konfiguration überprüft werden. Eine ungültige Konfiguration bedeutet, dass ein Fehler im Framework-Code vorliegt oder dass eine Diskrepanz zwischen den statischen Metadaten der HAL und den Anforderungen an Streams besteht.
-ENODEV: Wenn ein schwerwiegender Fehler aufgetreten ist und das Gerät nicht mehr betriebsbereit ist. Nachdem dieser Fehler zurückgegeben wurde, kann nur close() vom Framework erfolgreich aufgerufen werden.
| const camera_metadata_t *(* construction_default_request_settings)(const struct camera3_device *, int type) |
construction_default_request_settings:
Erstellen Sie Aufnahmeeinstellungen für Standard-Kameraanwendungsfälle.
Das Gerät muss einen Einstellungspuffer zurückgeben, der für den angeforderten Anwendungsfall konfiguriert ist. Dabei muss es sich um eine der Enumerationen CAMERA3_TEMPLATE_* handeln. Alle Felder zur Anforderungssteuerung müssen enthalten sein.
Der HAL behält den Besitz dieser Struktur, der Zeiger auf die Struktur muss jedoch gültig sein, bis das Gerät geschlossen wird. Das Framework und die HAL dürfen den Puffer nicht mehr ändern, sobald er durch diesen Aufruf zurückgegeben wird. Derselbe Puffer kann für nachfolgende Aufrufe für dieselbe Vorlage oder für andere Vorlagen zurückgegeben werden.
Leistungsanforderungen:
Dies sollte ein nicht blockierender Anruf sein. Der HAL sollte von diesem Aufruf in 1 ms zurückkehren und muss von diesem Aufruf in 5 ms zurückkehren.
Rückgabewerte:
Gültige Metadaten: Bei erfolgreicher Erstellung eines Standardeinstellungspuffers.
NULL: Im Falle eines schwerwiegenden Fehlers. Nachdem dies zurückgegeben wurde, kann nur die Methode close() vom Framework erfolgreich aufgerufen werden.
| void(* dump)(const struct camera3_device *, int fd) |
entsorgen:
Drucken Sie den Debugstatus für das Kameragerät aus. Dies wird vom Framework aufgerufen, wenn der Kameradienst nach einem Debug-Dump gefragt wird, was bei Verwendung des dumpsys-Tools oder bei der Erfassung eines Fehlerberichts der Fall ist.
Der übergebene Dateideskriptor kann zum Schreiben von Debugging-Text mit dprintf() oder write() verwendet werden. Der Text sollte nur in ASCII-Kodierung vorliegen.
Leistungsanforderungen:
Dies muss ein nicht blockierender Anruf sein. Der HAL sollte von diesem Aufruf in 1 ms zurückkehren, muss von diesem Aufruf in 10 ms zurückkehren. Dieser Aufruf muss Deadlocks vermeiden, da er jederzeit während des Kamerabetriebs aufgerufen werden kann. Alle verwendeten Synchronisierungsprimitive (z. B. Mutex-Sperren oder Semaphoren) sollten mit einem Timeout erfasst werden.
| int(* bündig)(const struct camera3_device *) |
spülen:
Leeren Sie alle derzeit in Bearbeitung befindlichen Erfassungen und alle Puffer in der Pipeline auf dem angegebenen Gerät. Das Framework verwendet dies, um den gesamten Status so schnell wie möglich zu sichern und sich auf einen Aufruf von configure_streams() vorzubereiten.
Für die erfolgreiche Rückgabe sind keine Puffer erforderlich, daher kann jeder Puffer, der zum Zeitpunkt von „flush()“ gehalten wurde (ob erfolgreich gefüllt oder nicht), mit CAMERA3_BUFFER_STATUS_ERROR zurückgegeben werden. Beachten Sie, dass die HAL während dieses Aufrufs weiterhin gültige Puffer (CAMERA3_BUFFER_STATUS_OK) zurückgeben darf, sofern diese erfolgreich gefüllt werden.
Es wird erwartet, dass alle Anfragen, die sich derzeit im HAL befinden, so schnell wie möglich zurückgesendet werden. Nicht in Bearbeitung befindliche Anfragen sollten sofort Fehler zurückgeben. Alle unterbrechbaren Hardwareblöcke sollten gestoppt werden und auf alle nicht unterbrechbaren Blöcke sollte gewartet werden.
„flush()“ kann gleichzeitig mit „process_capture_request()“ aufgerufen werden, mit der Erwartung, dass „process_capture_request“ schnell zurückkehrt und die in diesem „process_capture_request“-Aufruf übermittelte Anfrage wie alle anderen laufenden Anfragen behandelt wird. Aufgrund von Parallelitätsproblemen ist es aus Sicht der HAL möglich, dass ein Aufruf von „process_capture_request()“ gestartet wird, nachdem Flush aufgerufen wurde, aber noch nicht zurückgegeben wurde. Wenn ein solcher Aufruf erfolgt, bevor „flush()“ zurückkehrt, sollte die HAL die neue Erfassungsanforderung wie andere ausstehende Anforderungen im Flug behandeln (siehe Nr. 4 unten).
Genauer gesagt muss die HAL in verschiedenen Fällen die folgenden Anforderungen erfüllen:
- Für Erfassungen, die zu spät sind, als dass die HAL sie abbrechen/stoppen könnte, und die von der HAL normal abgeschlossen werden; Das heißt, der HAL kann wie gewohnt Shutter/Notify und Process_Capture_Result sowie Puffer senden.
- Für ausstehende Anforderungen, die noch nicht verarbeitet wurden, muss die HAL notify CAMERA3_MSG_ERROR_REQUEST aufrufen und alle Ausgabepuffer mit process_capture_result im Fehlerstatus (CAMERA3_BUFFER_STATUS_ERROR) zurückgeben. Der HAL darf den Release-Fence nicht in einen Fehlerzustand versetzen. Stattdessen müssen die Release-Fences auf die vom Framework übergebenen Acquire-Fences oder auf -1 gesetzt werden, wenn der HAL bereits auf sie gewartet hat. Dies ist auch der Pfad, der für alle Aufnahmen zu befolgen ist, für die die HAL bereits notify() mit CAMERA3_MSG_SHUTTER aufgerufen hat, für die jedoch keine Metadaten/gültigen Puffer erzeugt werden. Nach CAMERA3_MSG_ERROR_REQUEST sind für einen bestimmten Frame nur „process_capture_results“ mit Puffern in CAMERA3_BUFFER_STATUS_ERROR zulässig. Es sind keine weiteren Benachrichtigungen oder „process_capture_result“ mit Metadaten ungleich Null zulässig.
Für teilweise abgeschlossene ausstehende Anforderungen, die nicht über alle Ausgabepuffer oder möglicherweise fehlende Metadaten verfügen, sollte die HAL wie folgt sein:
3.1. Rufen Sie notify mit CAMERA3_MSG_ERROR_RESULT auf, wenn einige der erwarteten Ergebnismetadaten (dh ein oder mehrere Teilmetadaten) für die Erfassung nicht verfügbar sind.
3.2. Rufen Sie notify mit CAMERA3_MSG_ERROR_BUFFER für jeden Puffer auf, der nicht für die Erfassung erstellt wird.
3.3 Rufen Sie „Notify“ mit CAMERA3_MSG_SHUTTER mit dem Erfassungszeitstempel auf, bevor Puffer/Metadaten mit „process_capture_result“ zurückgegeben werden.
3.4 Für Aufnahmen, die einige Ergebnisse liefern, darf die HAL nicht CAMERA3_MSG_ERROR_REQUEST aufrufen, da dies auf einen vollständigen Fehler hinweist.
3.5. Gültige Puffer/Metadaten sollten wie gewohnt an das Framework übergeben werden.
3.6. Ausgefallene Puffer sollten wie für Fall 2 beschrieben an das Framework zurückgegeben werden. Ausgefallene Puffer müssen jedoch nicht der strengen Reihenfolge gültiger Puffer folgen und können in Bezug auf gültige Puffer nicht in der richtigen Reihenfolge sein. Wenn beispielsweise die Puffer A, B, C, D, E gesendet werden, D und E ausfallen, dann ist A, E, B, D, C eine akzeptable Rückgabereihenfolge.
3.7. Für vollständig fehlende Metadaten ist der Aufruf von CAMERA3_MSG_ERROR_RESULT ausreichend, es ist nicht erforderlich, „process_capture_result“ mit NULL-Metadaten oder einem Äquivalent aufzurufen.
- Wenn ein Flush() aufgerufen wird, während ein Aufruf von „process_capture_request()“ aktiv ist, sollte dieser Prozessaufruf so schnell wie möglich zurückkehren. Wenn außerdem ein Aufruf von „process_capture_request()“ erfolgt, nachdem „flush()“ aufgerufen wurde, aber bevor „flush()“ zurückgekehrt ist, sollte die durch den späten Aufruf von „process_capture_request“ bereitgestellte Erfassungsanforderung in Fall Nr. 2 oben wie eine ausstehende Anforderung behandelt werden.
„flush()“ sollte nur dann zurückkehren, wenn im HAL keine ausstehenden Puffer oder Anforderungen mehr vorhanden sind. Das Framework kann configure_streams aufrufen (da der HAL-Status jetzt stillgelegt ist) oder neue Anforderungen ausgeben.
Beachten Sie, dass es ausreicht, nur vollständig erfolgreiche und vollständig fehlgeschlagene Ergebnisfälle zu unterstützen. Es ist jedoch äußerst wünschenswert, auch die Fälle von Teilfehlern zu unterstützen, da dies dazu beitragen könnte, die Gesamtleistung des Flush-Aufrufs zu verbessern.
Leistungsanforderungen:
Der HAL sollte von diesem Aufruf in 100 ms zurückkehren und muss von diesem Aufruf in 1000 ms zurückkehren. Und dieser Aufruf darf nicht länger als die Pipeline-Latenz blockiert werden (Definition siehe S7).
Versionsinformation:
Nur verfügbar, wenn Geräteversion >= CAMERA_DEVICE_API_VERSION_3_1.
Rückgabewerte:
0: Bei einer erfolgreichen Spülung der Kamera-HAL.
-EINVAL: Wenn die Eingabe fehlerhaft ist (das Gerät ist ungültig).
-ENODEV: Wenn beim Kameragerät ein schwerwiegender Fehler aufgetreten ist. Nachdem dieser Fehler zurückgegeben wurde, kann nur die Methode close () vom Framework erfolgreich aufgerufen werden.
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, seller_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops:
Rufen Sie Methoden zum Abfragen von Metadaten-Tag-Informationen zur Anbietererweiterung ab. Die HAL sollte alle Betriebsmethoden für Anbieter-Tags ausfüllen oder die Operationen unverändert lassen, wenn keine Anbieter-Tags definiert sind.
Die Definition von seller_tag_query_ops_t finden Sie in system/media/camera/include/system/camera_metadata.h.
>= CAMERA_DEVICE_API_VERSION_3_2: VERALTET. Diese Funktion ist veraltet und sollte von der HAL auf NULL gesetzt werden. Bitte implementieren Sie stattdessen get_vendor_tag_ops in camera_common.h .
| int(* initialize)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
initialisieren:
Einmalige Initialisierung zur Übergabe von Framework-Callback-Funktionszeigern an die HAL. Wird nach einem erfolgreichen open()-Aufruf einmal aufgerufen, bevor andere Funktionen für die Struktur camera3_device_ops aufgerufen werden.
Leistungsanforderungen:
Dies sollte ein nicht blockierender Anruf sein. Der HAL sollte von diesem Aufruf in 5 ms zurückkehren und muss von diesem Aufruf in 10 ms zurückkehren.
Rückgabewerte:
0: Bei erfolgreicher Initialisierung
-ENODEV: Wenn die Initialisierung fehlschlägt. Danach kann nur noch close() vom Framework erfolgreich aufgerufen werden.
| int(*process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request) |
Process_Capture_Request:
Senden Sie eine neue Erfassungsanforderung an den HAL. Der HAL sollte von diesem Aufruf erst zurückkehren, wenn er bereit ist, die nächste zu verarbeitende Anforderung anzunehmen. Das Framework führt jeweils nur einen Aufruf von „process_capture_request()“ durch, und die Aufrufe erfolgen alle aus demselben Thread. Der nächste Aufruf von process_capture_request() erfolgt, sobald eine neue Anfrage und die zugehörigen Puffer verfügbar sind. In einem normalen Vorschauszenario bedeutet dies, dass die Funktion fast sofort erneut vom Framework aufgerufen wird.
Die eigentliche Anforderungsverarbeitung erfolgt asynchron, wobei die Ergebnisse der Erfassung von der HAL über den Aufruf „process_capture_result()“ zurückgegeben werden. Für diesen Aufruf müssen die Ergebnismetadaten verfügbar sein, Ausgabepuffer stellen jedoch möglicherweise lediglich Synchronisierungsgrenzen bereit, auf die gewartet werden kann. Es wird erwartet, dass mehrere Anfragen gleichzeitig ausgeführt werden, um die volle Ausgabebildrate aufrechtzuerhalten.
Das Framework behält den Besitz der Anforderungsstruktur. Die Gültigkeit ist nur während dieses Anrufs garantiert. Das HAL-Gerät muss Kopien der Informationen erstellen, die es für die Erfassungsverarbeitung aufbewahren muss. Der HAL ist dafür verantwortlich, auf die Pufferzäune zu warten und sie zu schließen und die Pufferhandles an das Framework zurückzugeben.
Die HAL muss den Dateideskriptor für den Release-Sync-Fence des Eingabepuffers in input_buffer->release_fence schreiben, wenn input_buffer nicht NULL ist. Wenn die HAL -1 für den Synchronisierungszaun für die Freigabe des Eingabepuffers zurückgibt, steht es dem Framework frei, den Eingabepuffer sofort wiederzuverwenden. Andernfalls wartet das Framework auf dem Synchronisierungszaun, bevor es den Eingabepuffer wieder auffüllt und wiederverwendet.
>= CAMERA_DEVICE_API_VERSION_3_2:
Die vom Framework in jeder Anfrage bereitgestellten Eingabe-/Ausgabepuffer sind möglicherweise brandneu (die HAL hat sie noch nie zuvor gesehen).
Überlegungen zur Leistung:
Die Handhabung eines neuen Puffers sollte äußerst einfach sein und es sollte keine Verschlechterung der Bildrate oder Bildjitter auftreten.
Dieser Aufruf muss schnell genug zurückkehren, um sicherzustellen, dass die angeforderte Bildrate aufrechterhalten werden kann, insbesondere bei Streaming-Fällen (Einstellungen für die Nachbearbeitungsqualität sind auf FAST eingestellt). Der HAL sollte diesen Aufruf in 1-Frame-Intervallen zurückgeben und muss von diesem Aufruf in 4-Frame-Intervallen zurückkehren.
Rückgabewerte:
0: Bei erfolgreichem Start der Verarbeitung der Erfassungsanforderung
-EINVAL: Wenn die Eingabe fehlerhaft ist (die Einstellungen sind NULL, wenn sie nicht zulässig sind, es gibt 0 Ausgabepuffer usw.) und die Erfassungsverarbeitung nicht gestartet werden kann. Fehler während der Anforderungsverarbeitung sollten durch Aufrufen von camera3_callback_ops_t.notify() behandelt werden. Im Falle dieses Fehlers behält das Framework die Verantwortung für die Zäune und Pufferhandles der Stream-Puffer. Die HAL sollte die Zäune nicht schließen oder diese Puffer mit „process_capture_result“ zurückgeben.
-ENODEV: Wenn beim Kameragerät ein schwerwiegender Fehler aufgetreten ist. Nachdem dieser Fehler zurückgegeben wurde, kann nur die Methode close () vom Framework erfolgreich aufgerufen werden.
| 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:
VERALTET. Dies wird nicht aufgerufen und muss auf NULL gesetzt werden.
<= CAMERA_DEVICE_API_VERSION_3_1:
Registrieren Sie Puffer für einen bestimmten Stream beim HAL-Gerät. Diese Methode wird vom Framework aufgerufen, nachdem durch configure_streams ein neuer Stream definiert wurde und bevor Puffer aus diesem Stream in eine Erfassungsanforderung einbezogen werden. Wenn derselbe Stream in einem nachfolgenden Aufruf von configure_streams() aufgeführt wird, wird register_stream_buffers für diesen Stream nicht erneut aufgerufen.
Das Framework muss nicht Puffer für alle konfigurierten Streams registrieren, bevor es die erste Erfassungsanforderung sendet. Dies ermöglicht einen schnellen Start für die Vorschau (oder ähnliche Anwendungsfälle), während andere Streams noch zugewiesen werden.
Diese Methode soll es dem HAL-Gerät ermöglichen, die Puffer zuzuordnen oder anderweitig für die spätere Verwendung vorzubereiten. Die übergebenen Puffer sind bereits für die Verwendung gesperrt. Am Ende des Aufrufs müssen alle Puffer bereit sein, an den Stream zurückgegeben zu werden. Das Argument buffer_set ist nur für die Dauer dieses Aufrufs gültig.
Wenn das Stream-Format auf HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED eingestellt wurde, sollte die Kamera-HAL die hier übergebenen Puffer überprüfen, um etwaige plattformprivate Pixelformatinformationen zu ermitteln.
Leistungsanforderungen:
Dies sollte ein nicht blockierender Anruf sein. Der HAL sollte von diesem Aufruf in 1 ms zurückkehren und muss von diesem Aufruf in 5 ms zurückkehren.
Rückgabewerte:
0: Bei erfolgreicher Registrierung der neuen Stream-Puffer
-EINVAL: Wenn stream_buffer_set nicht auf einen gültigen aktiven Stream verweist oder wenn das Pufferarray ungültig ist.
-ENOMEM: Wenn beim Registrieren der Puffer ein Fehler aufgetreten ist. Das Framework muss alle Stream-Puffer als nicht registriert betrachten und kann später versuchen, sich erneut zu registrieren.
-ENODEV: Wenn ein schwerwiegender Fehler vorliegt und das Gerät nicht mehr betriebsbereit ist. Nachdem dieser Fehler zurückgegeben wurde, kann nur close() vom Framework erfolgreich aufgerufen werden.
Die Dokumentation für diese Struktur wurde aus der folgenden Datei generiert:
- hardware/libhardware/include/hardware/ camera3.h