camera3_device_ops-Strukturreferenz

configure_streams:

Nur CAMERA_DEVICE_API_VERSION_3_0:

Setzen Sie die HAL-Kamerageräteverarbeitungspipeline zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Mit diesem Aufruf werden alle vorhandenen Streamkonfigurationen durch die in der stream_list definierten Streams ersetzt. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() gesendet wird.

Die stream_list muss mindestens einen ausgabefähigen Stream und darf höchstens einen eingabefähigen Stream enthalten.

Die stream_list kann Streams enthalten, die sich auch in der aktuell aktiven Gruppe von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams haben bereits gültige Werte für „usage“, „max_buffers“ und den privaten Pointer.

Wenn die Puffer eines solchen Streams bereits registriert wurden, wird register_stream_buffers() für den Stream nicht noch einmal aufgerufen und Puffer aus dem Stream können sofort in Eingabeanfragen eingeschlossen werden.

Wenn die HAL die Streamkonfiguration für einen vorhandenen Stream aufgrund der neuen Konfiguration ändern muss, werden die Werte für „Nutzung“ und/oder „max_buffers“ möglicherweise während des Konfigurationsaufrufs neu geschrieben.

Das Framework erkennt eine solche Änderung und weist die Stream-Buffer neu zu. Anschließend wird register_stream_buffers() noch einmal aufgerufen, bevor Buffers aus diesem Stream in einer Anfrage verwendet werden.

Wenn ein derzeit aktiver Stream nicht in „stream_list“ enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Sie wird nicht in einem späteren Aufruf von „configure()“ durch das Framework wiederverwendet und alle Gralloc-Buffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückgegeben wurde.

Die Struktur „stream_list“ gehört zum Framework und kann nach Abschluss dieses Aufrufs nicht mehr verwendet werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten Aufrufs von „configure_stream()“ gültig, der diese camera3_stream_t nicht mehr im Argument „stream_list“ enthält. Die HAL darf Werte in der Streamstruktur außerhalb des privaten Zeigers nicht ändern, mit Ausnahme der Mitglieder „usage“ und „max_buffers“ während des Aufrufs von configure_streams() .

Wenn der Stream neu ist, werden die Felder „usage“, „max_buffer“ und „private pointer“ der Streamstruktur auf „0“ gesetzt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf configure_streams() zurückgegeben wird. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Buffer für jeden Stream zuzuweisen.

Bevor die Puffer eines solchen neuen Streams in eine Aufnahmeanfrage aufgenommen werden können, ruft das Framework register_stream_buffers() mit diesem Stream auf. Das Framework muss jedoch nicht vor dem Senden einer Anfrage Puffer für alle Streams registrieren. So kann beispielsweise ein Vorschaustream schnell gestartet werden, während andere Streams später oder gleichzeitig zugewiesen werden.

---

Nur CAMERA_DEVICE_API_VERSION_3_1:

Setzen Sie die HAL-Kamerageräteverarbeitungspipeline zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Mit diesem Aufruf werden alle vorhandenen Streamkonfigurationen durch die in der stream_list definierten Streams ersetzt. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() gesendet wird.

Die stream_list muss mindestens einen ausgabefähigen Stream und darf höchstens einen eingabefähigen Stream enthalten.

Die stream_list kann Streams enthalten, die sich auch in der aktuell aktiven Gruppe von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams haben bereits gültige Werte für „usage“, „max_buffers“ und den privaten Pointer.

Wenn die Puffer eines solchen Streams bereits registriert wurden, wird register_stream_buffers() für den Stream nicht noch einmal aufgerufen und Puffer aus dem Stream können sofort in Eingabeanfragen eingeschlossen werden.

Wenn die HAL die Streamkonfiguration für einen vorhandenen Stream aufgrund der neuen Konfiguration ändern muss, werden die Werte für „Nutzung“ und/oder „max_buffers“ möglicherweise während des Konfigurationsaufrufs neu geschrieben.

Das Framework erkennt eine solche Änderung und weist die Stream-Buffer neu zu. Anschließend wird register_stream_buffers() noch einmal aufgerufen, bevor Buffers aus diesem Stream in einer Anfrage verwendet werden.

Wenn ein derzeit aktiver Stream nicht in „stream_list“ enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Sie wird nicht in einem späteren Aufruf von „configure()“ durch das Framework wiederverwendet und alle Gralloc-Buffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückgegeben wurde.

Die Struktur „stream_list“ gehört zum Framework und kann nach Abschluss dieses Aufrufs nicht mehr verwendet werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten Aufrufs von „configure_stream()“ gültig, der diese camera3_stream_t nicht mehr im Argument „stream_list“ enthält. Die HAL darf Werte in der Streamstruktur außerhalb des privaten Zeigers nicht ändern, mit Ausnahme der Mitglieder „usage“ und „max_buffers“ während des Aufrufs von configure_streams() .

Wenn der Stream neu ist, werden die Felder „max_buffer“ und „private pointer“ der Streamstruktur auf „0“ gesetzt. Die Nutzung wird auf die Flags für die Nutzung durch Verbraucher festgelegt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf configure_streams() zurückgegeben wird. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Buffer für jeden Stream zuzuweisen.

Bevor die Puffer eines solchen neuen Streams in eine Aufnahmeanfrage aufgenommen werden können, ruft das Framework register_stream_buffers() mit diesem Stream auf. Das Framework muss jedoch nicht vor dem Senden einer Anfrage Puffer für alle Streams registrieren. So kann beispielsweise ein Vorschaustream schnell gestartet werden, während andere Streams später oder gleichzeitig zugewiesen werden.

---

>= CAMERA_DEVICE_API_VERSION_3_2:

Setzen Sie die HAL-Kamerageräteverarbeitungspipeline zurück und richten Sie neue Eingabe- und Ausgabestreams ein. Mit diesem Aufruf werden alle vorhandenen Streamkonfigurationen durch die in der stream_list definierten Streams ersetzt. Diese Methode wird mindestens einmal nach initialize() aufgerufen, bevor eine Anfrage mit process_capture_request() gesendet wird.

Die stream_list muss mindestens einen ausgabefähigen Stream und darf höchstens einen eingabefähigen Stream enthalten.

Die stream_list kann Streams enthalten, die sich auch in der aktuell aktiven Gruppe von Streams befinden (aus dem vorherigen Aufruf von configure_stream()). Diese Streams haben bereits gültige Werte für „usage“, „max_buffers“ und den privaten Pointer.

Wenn die HAL die Streamkonfiguration für einen vorhandenen Stream aufgrund der neuen Konfiguration ändern muss, werden die Werte für „Nutzung“ und/oder „max_buffers“ möglicherweise während des Konfigurationsaufrufs neu geschrieben.

Das Framework erkennt eine solche Änderung und kann die Stream-Buffer dann neu zuweisen, bevor Buffers aus diesem Stream in einer Anfrage verwendet werden.

Wenn ein derzeit aktiver Stream nicht in „stream_list“ enthalten ist, kann die HAL alle Verweise auf diesen Stream sicher entfernen. Sie wird nicht in einem späteren Aufruf von „configure()“ durch das Framework wiederverwendet und alle Gralloc-Buffer dafür werden freigegeben, nachdem der Aufruf von configure_streams() zurückgegeben wurde.

Die Struktur „stream_list“ gehört zum Framework und kann nach Abschluss dieses Aufrufs nicht mehr verwendet werden. Die Adresse einer einzelnen camera3_stream_t-Struktur bleibt für den Zugriff durch die HAL bis zum Ende des ersten Aufrufs von „configure_stream()“ gültig, der diese camera3_stream_t nicht mehr im Argument „stream_list“ enthält. Die HAL darf Werte in der Streamstruktur außerhalb des privaten Zeigers nicht ändern, mit Ausnahme der Mitglieder „usage“ und „max_buffers“ während des Aufrufs von configure_streams() .

Wenn der Stream neu ist, werden die Felder „max_buffer“ und „private pointer“ der Streamstruktur auf „0“ gesetzt. Die Nutzung wird auf die Flags für die Nutzung durch Verbraucher festgelegt. Das HAL-Gerät muss diese Felder festlegen, bevor der Aufruf configure_streams() zurückgegeben wird. Diese Felder werden dann vom Framework und dem Gralloc-Modul der Plattform verwendet, um die Gralloc-Buffer für jeden Stream zuzuweisen.

Neu zugewiesene Puffer können vom Framework jederzeit in eine Aufnahmeanfrage aufgenommen werden. Sobald ein gralloc-Puffer mit „process_capture_result“ an das Framework zurückgegeben wurde (und seine entsprechende „release_fence“-Signalisierung erfolgt ist), kann das Framework ihn jederzeit freigeben oder wiederverwenden.

---

Voraussetzungen:

Das Framework ruft diese Methode nur auf, wenn keine Aufnahmen verarbeitet werden. Das bedeutet, dass alle Ergebnisse an das Framework zurückgegeben wurden und alle laufenden Eingabe- und Ausgabe-Buffer zurückgegeben wurden und ihre Release-Synchronisationsschranken von der HAL signalisiert wurden. Solange der Aufruf von configure_streams() läuft, werden keine neuen Anfragen zur Erfassung gesendet.

Nachbedingungen:

Das HAL-Gerät muss sich so konfigurieren, dass die maximale mögliche Ausgabeframerate bei den Größen und Formaten der Ausgabestreams bereitgestellt wird, wie in den statischen Metadaten des Kamerageräts dokumentiert.

Leistungsanforderungen:

Dieser Aufruf ist voraussichtlich leistungsintensiv und kann mehrere hundert Millisekunden dauern, da der Bildsensor und die Kameraverarbeitungspipeline möglicherweise zurückgesetzt und neu konfiguriert werden müssen. Dennoch sollte das HAL-Gerät versuchen, die Verzögerung bei der Neukonfiguration zu minimieren, um die für den Nutzer sichtbaren Pausen bei Änderungen des Betriebsmodus der Anwendung zu minimieren, z. B. beim Wechsel von der Aufnahme von Standbildern zur Videoaufzeichnung.

Die HAL sollte nach 500 ms von diesem Aufruf zurückkehren und nach 1.000 ms muss sie von diesem Aufruf zurückkehren.

Rückgabewerte:

0: Nach erfolgreicher Streamkonfiguration

-EINVAL: Die angeforderte Streamkonfiguration ist ungültig. Beispiele für ungültige Streamkonfigurationen:

• Mehr als ein Eingabestream (INPUT oder BIDIRECTIONAL)
• Ohne streams, die eine Ausgabe ermöglichen (OUTPUT oder BIDIRECTIONAL)
• Streams mit nicht unterstützten Formaten oder einer nicht unterstützten Größe für dieses Format
• Zu viele Ausgabestreams eines bestimmten Formats
• Nicht unterstützte Drehungskonfiguration (gilt nur für Geräte mit Version >= CAMERA_DEVICE_API_VERSION_3_3)
• Die Streamgrößen/-formate erfüllen nicht die Anforderungen von camera3_stream_configuration_t->operation_mode für einen anderen Modus als NORMAL 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)

Das Einreichen einer ungültigen Streamkonfiguration durch das Framework ist kein normaler Vorgang, da Streamkonfigurationen vor der Konfiguration geprüft werden. Eine ungültige Konfiguration bedeutet, dass ein Fehler im Framework-Code vorliegt oder dass die statischen Metadaten der HAL nicht mit den Anforderungen an Streams übereinstimmen.

-ENODEV: Ein schwerwiegender Fehler ist aufgetreten und das Gerät funktioniert nicht mehr. Nach der Rückgabe dieses Fehlers kann nur noch close() vom Framework erfolgreich aufgerufen werden.

Definition in Zeile 2769 der Datei camera3.h .

construct_default_request_settings:

Erstellen Sie Aufnahmeeinstellungen für Standardkameraanwendungsfälle.

Das Gerät muss einen Einstellungsbuffer zurückgeben, der für den angeforderten Anwendungsfall konfiguriert ist. Dieser muss zu einem der CAMERA3_TEMPLATE_*-Enum-Werte gehören. Alle Felder zur Anfragesteuerung müssen enthalten sein.

Die HAL behält die Inhaberschaft an dieser Struktur, aber der Zeiger auf die Struktur muss gültig sein, bis das Gerät geschlossen wird. Das Framework und die HAL dürfen den Puffer nicht ändern, nachdem er durch diesen Aufruf zurückgegeben wurde. Derselbe Puffer kann für nachfolgende Aufrufe derselben Vorlage oder anderer Vorlagen zurückgegeben werden.

Leistungsanforderungen:

Dies sollte ein nicht blockierender Aufruf sein. Der HAL sollte nach 1 ms von diesem Aufruf zurückkehren und muss nach 5 ms von diesem Aufruf zurückkehren.

Rückgabewerte:

Gültige Metadaten: Nach dem erfolgreichen Erstellen eines Buffers mit Standardeinstellungen.

NULL: Bei einem schwerwiegenden Fehler. Danach kann nur noch die Methode „close()“ vom Framework erfolgreich aufgerufen werden.

Definition in Zeile 2859 der Datei camera3.h .

dump:

Den Debugging-Status für das Kameragerät ausdrucken. Diese Funktion wird vom Framework aufgerufen, wenn der Kameradienst um einen Debug-Dump gebeten wird. Dies geschieht bei Verwendung des Dumpsys-Tools oder beim Erfassen eines Fehlerberichts.

Der übergebene Dateideskriptor kann verwendet werden, um mit dprintf() oder write() Debug-Text zu schreiben. Der Text sollte nur in ASCII-Codierung vorliegen.

Leistungsanforderungen:

Dies muss ein nicht blockierender Aufruf sein. Die HAL sollte nach 1 ms von diesem Aufruf zurückkehren, muss aber nach 10 ms von diesem Aufruf zurückkehren. Bei diesem Aufruf dürfen keine Deadlocks auftreten, da er jederzeit während des Kamerabetriebs aufgerufen werden kann. Alle verwendeten Synchronisierungsprimitive (z. B. Mutex-Sperren oder Semaphoren) sollten mit einem Zeitlimit erworben werden.

Definition in Zeile 2971 der Datei camera3.h .

flush:

Alle derzeit in Bearbeitung befindlichen Aufnahmen und alle Puffer in der Pipeline auf dem angegebenen Gerät werden geleert. Das Framework verwendet diese Informationen, um den gesamten Status so schnell wie möglich zu erfassen und sich auf einen configure_streams() -Aufruf vorzubereiten.

Es müssen keine Buffers erfolgreich zurückgegeben werden. Daher kann jeder Buffer, der zum Zeitpunkt von flush() gehalten wird (unabhängig davon, ob er erfolgreich gefüllt wurde oder nicht), mit CAMERA3_BUFFER_STATUS_ERROR zurückgegeben werden. Hinweis: Der HAL darf während dieses Aufrufs weiterhin gültige Buffers (CAMERA3_BUFFER_STATUS_OK) zurückgeben, sofern sie erfolgreich gefüllt wurden.

Alle Anfragen, die sich derzeit im HAL befinden, werden voraussichtlich so bald wie möglich zurückgegeben. Bei Anfragen, die nicht in Bearbeitung sind, sollten sofort Fehler zurückgegeben werden. Alle unterbrechbaren Hardwareblöcke sollten angehalten und alle nicht unterbrechbaren Blöcke sollten gewartet werden.

flush() kann gleichzeitig mit process_capture_request() aufgerufen werden. Dabei wird davon ausgegangen, dass process_capture_request schnell zurückgegeben wird und die in diesem process_capture_request-Aufruf eingereichte Anfrage wie alle anderen laufenden Anfragen behandelt wird. Aufgrund von Problemen mit der Parallelität kann es sein, dass aus Sicht der HAL ein process_capture_request() Aufruf gestartet wird, nachdem „flush“ aufgerufen wurde, aber noch nicht zurückgegeben wurde. Wenn ein solcher Aufruf erfolgt, bevor flush() zurückgegeben wird, sollte die HAL die neue Aufnahmeanfrage wie andere ausstehende Anfragen behandeln (siehe Punkt 4 unten).

Im Detail muss die HAL für verschiedene Fälle die folgenden Anforderungen erfüllen:

1. Für Aufnahmen, die zu spät sind, um vom HAL abgebrochen oder angehalten zu werden, und vom HAL normal abgeschlossen werden. Das bedeutet, dass der HAL shutter/notify und process_capture_result und Puffer wie gewohnt senden kann.
2. Bei ausstehenden Anfragen, die noch nicht verarbeitet wurden, muss die HAL CAMERA3_MSG_ERROR_REQUEST benachrichtigen und alle Ausgabebuffer mit process_capture_result im Fehlerstatus (CAMERA3_BUFFER_STATUS_ERROR) zurückgeben. Die HAL darf den Release-Fence nicht in einen Fehlerstatus versetzen. Stattdessen müssen die Release-Fences auf die vom Framework übergebenen Acquire-Fences gesetzt werden oder auf -1, wenn sie bereits von der HAL gewartet wurden. Dieser Pfad ist auch für alle Aufnahmen zu verwenden, für die der HAL bereits notify() mit CAMERA3_MSG_SHUTTER aufgerufen hat, für die jedoch keine Metadaten/gültigen Puffer erstellt werden. Nach CAMERA3_MSG_ERROR_REQUEST sind für einen bestimmten Frame nur process_capture_results mit Buffers in CAMERA3_BUFFER_STATUS_ERROR zulässig. Es sind keine weiteren „notifys“ oder „process_capture_result“-Nachrichten mit nicht nullwertigen Metadaten zulässig.

3. Bei teilweise abgeschlossenen ausstehenden Anfragen, die nicht alle Ausgabebuffer enthalten oder möglicherweise Metadaten fehlen, sollte die HAL unten aufgeführten Anforderungen entsprechen:

   3.1. Rufen Sie „notify“ mit CAMERA3_MSG_ERROR_RESULT auf, wenn einige der erwarteten Ergebnismetadaten (d.h. eine oder mehrere Teilmetadaten) für die Aufnahme nicht verfügbar sind.

   3.2 Rufen Sie notify mit CAMERA3_MSG_ERROR_BUFFER für jeden Puffer auf, der nicht für die Aufnahme erstellt wird.

   3.3 Rufen Sie „notify“ mit CAMERA3_MSG_SHUTTER und dem Zeitstempel der Aufnahme auf, bevor Buffers/Metadaten mit „process_capture_result“ zurückgegeben werden.

   3.4 Bei Aufnahmen, die einige Ergebnisse liefern, darf der HAL nicht CAMERA3_MSG_ERROR_REQUEST aufrufen, da dies einen vollständigen Fehler bedeutet.

   3.5. Gültige Buffers/Metadaten sollten wie gewohnt an das Framework übergeben werden.

   3.6. Fehlgeschlagene Puffer sollten wie in Fall 2 beschrieben an das Framework zurückgegeben werden. Fehlerhafte Puffer müssen jedoch nicht der strengen Reihenfolge gültiger Puffer folgen und können im Vergleich zu gültigen Puffern nicht in der richtigen Reihenfolge sein. Wenn beispielsweise die Puffer A, B, C, D und E gesendet werden und D und E fehlschlagen, ist A, E, B, D, C eine zulässige Rückgabereihenfolge.

   3.7. Wenn Metadaten vollständig fehlen, reicht der Aufruf von CAMERA3_MSG_ERROR_RESULT aus. Es ist nicht erforderlich, process_capture_result mit NULL-Metadaten oder einem ähnlichen Wert aufzurufen.

4. Wenn 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 process_capture_request() Aufruf nach flush() erfolgt, aber bevor flush() zurückgegeben wurde, sollte die Erfassungsanfrage, die durch den späten Aufruf von process_capture_request bereitgestellt wird, wie eine ausstehende Anfrage in Fall 2 oben behandelt werden.

flush() sollte nur zurückgegeben werden, wenn keine ausstehenden Puffer oder Anfragen mehr in der HAL vorhanden sind. Das Framework ruft möglicherweise „configure_streams“ auf, da der HAL-Status jetzt inaktiv ist, oder sendet neue Anfragen.

Es reicht aus, nur Fälle mit vollständig erfolgreichen und vollständig fehlgeschlagenen Ergebnissen zu unterstützen. Es ist jedoch sehr wünschenswert, auch die Fälle mit teilweisen Fehlern zu unterstützen, da dies die Gesamtleistung des Flush-Aufrufs verbessern kann.

Leistungsanforderungen:

Die HAL sollte nach 100 ms von diesem Aufruf zurückkehren und muss nach 1.000 ms von diesem Aufruf zurückkehren. Außerdem darf dieser Aufruf nicht länger als die Pipelinelatenz blockiert werden (Definition siehe S7).

Versionsinformationen:

Nur verfügbar, wenn die Geräteversion >= CAMERA_DEVICE_API_VERSION_3_1 ist.

Rückgabewerte:

0: Bei einem erfolgreichen Leeren des HAL der Kamera.

-EINVAL: Wenn die Eingabe fehlerhaft ist (das Gerät nicht gültig ist).

-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.

Definition in Zeile 3077 der Datei camera3.h .

get_metadata_vendor_tag_ops:

Methoden zum Abrufen von Informationen zu Metadaten-Tags von Anbietererweiterungen Die HAL sollte alle Methoden für den Vorgang mit Anbieter-Tags ausfüllen oder „ops“ unverändert lassen, wenn keine Anbieter-Tags definiert sind.

Die Definition von „vendor_tag_query_ops_t“ finden Sie unter „system/media/camera/include/system/camera_metadata.h“.

>= CAMERA_DEVICE_API_VERSION_3_2: VERALTET. Diese Funktion wurde eingestellt und sollte vom HAL auf NULL gesetzt werden. Implementieren Sie stattdessen get_vendor_tag_ops in camera_common.h .

Definition in Zeile 2950 der Datei camera3.h .

initialize:

Einmalige Initialisierung, um Framework-Callback-Funktionszeigers an die HAL zu übergeben. Wird einmal nach einem erfolgreichen Aufruf von „open()“ aufgerufen, bevor andere Funktionen für die Struktur camera3_device_ops aufgerufen werden.

Leistungsanforderungen:

Dies sollte ein nicht blockierender Aufruf sein. Die HAL sollte nach 5 ms von diesem Aufruf zurückkehren und muss nach 10 ms von diesem Aufruf zurückkehren.

Rückgabewerte:

0: Nach erfolgreicher Initialisierung

-ENODEV: Wenn die Initialisierung fehlschlägt. Danach kann nur noch close() vom Framework erfolgreich aufgerufen werden.

Definition in Zeile 2530 der Datei camera3.h .

process_capture_request:

Senden Sie eine neue Aufnahmeanfrage an die HAL. Der HAL sollte erst von diesem Aufruf zurückkehren, wenn er bereit ist, die nächste Anfrage zur Verarbeitung anzunehmen. Das Framework ruft immer nur einen einzigen process_capture_request() -Aufruf auf und alle Aufrufe stammen 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 das, dass die Funktion vom Framework fast sofort wieder aufgerufen wird.

Die eigentliche Anfrageverarbeitung erfolgt asynchron. Die Ergebnisse der Erfassung werden vom HAL über den Aufruf „process_capture_result()“ zurückgegeben. Für diesen Aufruf müssen die Ergebnismetadaten verfügbar sein. Ausgabe-Puffer können jedoch einfach Synchronisationsschranken bereitstellen, auf die gewartet werden muss. Es wird davon ausgegangen, dass mehrere Anfragen gleichzeitig gesendet werden, um die volle Ausgabeframerate beizubehalten.

Das Framework behält die Inhaberschaft an der Anfragestruktur. Sie ist nur während dieses Aufrufs gültig. Das HAL-Gerät muss Kopien der Informationen erstellen, die für die Verarbeitung der Aufnahme benötigt werden. Die HAL ist dafür verantwortlich, auf die Sperren der Buffers zu warten und sie zu schließen sowie die Buffer-Handle an das Framework zurückzugeben.

Die HAL muss den Dateideskriptor für die Release-Synchronisationsschranke des Eingabepuffers in input_buffer->release_fence schreiben, wenn input_buffer nicht NULL ist. Wenn die HAL -1 für die Synchronisierungssperre zum Freigeben des Eingabepuffers zurückgibt, kann das Framework den Eingabepuffer sofort wiederverwenden. Andernfalls wartet das Framework auf den Synchronisierungspfosten, bevor der Eingabepuffer wieder aufgefüllt und wiederverwendet wird.

>= CAMERA_DEVICE_API_VERSION_3_2:

Die vom Framework in jeder Anfrage bereitgestellten Eingabe-/Ausgabe-Buffer können brandneu sein, d. h. sie wurden noch nie zuvor von der HAL gesehen.

---

Hinweise zur Leistung:

Die Verarbeitung eines neuen Buffers sollte extrem effizient sein und es darf keine Beeinträchtigung der Framerate oder Frame-Jitter geben.

Dieser Aufruf muss schnell genug zurückgegeben werden, damit die angeforderte Framerate aufrechterhalten werden kann, insbesondere bei Streaming (Qualitätseinstellungen für die Nachbearbeitung auf „SCHNELL“ gesetzt). Der HAL sollte diesen Aufruf in einem Frame-Intervall zurückgeben und nach diesem Aufruf in 4 Frame-Intervallen zurückkehren.

Rückgabewerte:

0: Bei erfolgreichem Start der Verarbeitung der Erfassungsanfrage

-EINVAL: Die Eingabe ist fehlerhaft (z. B. sind die Einstellungen NULL, wenn dies nicht zulässig ist, oder es gibt 0 Ausgabe-Buffer). Die Erfassung kann nicht gestartet werden. Fehler bei der Anfrageverarbeitung sollten durch Aufrufen von camera3_callback_ops_t.notify() gehandhabt werden. Bei diesem Fehler bleibt das Framework für die Semaphoren und Buffer-Handles der Stream-Buffer verantwortlich. Die HAL darf die Semaphoren nicht schließen oder diese Buffer 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.

Definition in Zeile 2928 der Datei camera3.h .

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

EINGESTELLT. Diese Funktion wird nicht aufgerufen und muss auf „NULL“ gesetzt werden.

<= CAMERA_DEVICE_API_VERSION_3_1:

Registriert Puffer für einen bestimmten Stream beim HAL-Gerät. Diese Methode wird vom Framework aufgerufen, nachdem ein neuer Stream mit „configure_streams“ definiert wurde und bevor Buffers aus diesem Stream in eine Aufnahmeanfrage aufgenommen werden. Wenn derselbe Stream in einem nachfolgenden Aufruf von configure_streams() aufgeführt ist, wird register_stream_buffers für diesen Stream nicht noch einmal aufgerufen.

Das Framework muss keine Puffer für alle konfigurierten Streams registrieren, bevor es die erste Aufnahmeanfrage sendet. So ist ein schneller Start für die Vorschau (oder ähnliche Anwendungsfälle) möglich, während andere Streams noch zugewiesen werden.

Mit dieser Methode soll es dem HAL-Gerät ermöglicht werden, die Puffer für die spätere Verwendung zuzuordnen oder anderweitig 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 Streamformat auf HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED festgelegt wurde, sollte die HAL der Kamera hier die übergebenen Puffer prüfen, um plattformspezifische Informationen zum Pixelformat zu ermitteln.

Leistungsanforderungen:

Dies sollte ein nicht blockierender Aufruf sein. Der HAL sollte nach 1 ms von diesem Aufruf zurückkehren und muss nach 5 ms von diesem Aufruf zurückkehren.

Rückgabewerte:

0: Nach erfolgreicher Registrierung der neuen Stream-Buffer

-EINVAL: Wenn sich „stream_buffer_set“ nicht auf einen gültigen aktiven Stream bezieht oder das Buffers-Array ungültig ist.

-ENOMEM: Bei einem Fehler bei der Registrierung der Puffer. Das Framework muss alle Stream-Buffer als nicht registriert betrachten und kann später versuchen, sie noch einmal zu registrieren.

-ENODEV: Ein schwerwiegender Fehler ist aufgetreten und das Gerät funktioniert nicht mehr. Nach der Rückgabe dieses Fehlers kann nur noch close() vom Framework erfolgreich aufgerufen werden.

Definition in Zeile 2823 der Datei camera3.h .

Definition in Zeile 3080 der Datei camera3.h .