Riferimento alla struttura camera3_device_ops

configure_streams:

Solo CAMERA_DEVICE_API_VERSION_3_0:

Ripristina la pipeline di elaborazione del dispositivo della videocamera HAL e configura nuovi stream di input e output. Questa chiamata sostituisce qualsiasi configurazione di stream esistente con gli stream definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo initialize() prima che venga inviata una richiesta con process_capture_request() .

L'elenco stream_list deve contenere almeno uno stream in grado di produrre output e non può contenere più di uno stream in grado di ricevere input.

L'elenco stream_list può contenere stream che si trovano anche nell'insieme di stream attualmente attivo (dalla chiamata precedente a configure_stream()). Questi stream avranno già valori validi per usage, max_buffers e il puntatore privato.

Se per uno stream sono già stati registrati i relativi buffer, register_stream_buffers() non verrà richiamato di nuovo per lo stream e i buffer dello stream potranno essere inclusi immediatamente nelle richieste di input.

Se l'HAL deve modificare la configurazione di uno stream esistente a causa della nuova configurazione, potrebbe riscrivere i valori di usage e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà questa modifica, riallocherà i buffer dello stream e chiamerà nuovamente register_stream_buffers() prima di utilizzare i buffer di questo stream in una richiesta.

Se uno stream attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in sicurezza tutti i riferimenti a questo stream. Non verrà riutilizzato in una chiamata successiva di configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati al termine del ritorno della chiamata configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi al termine di questa chiamata. L'indirizzo di una singola struttura camera3_stream_t rimarrà valido per l'accesso da parte dell'HAL fino alla fine della prima chiamata di configure_stream(), che non include più la struttura camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura dello stream al di fuori del puntatore privato, ad eccezione dei membri usage e max_buffers durante la chiamata stessa di configure_streams() .

Se lo stream è nuovo, i campi usage, max_buffer e private_pointer della struttura dello stream verranno impostati su 0. Il dispositivo HAL deve impostare questi campi prima che la chiamata configure_streams() restituisca. Questi campi vengono poi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ogni stream.

Prima che i buffer di un nuovo stream possano essere inclusi in una richiesta di acquisizione, il framework chiamerà register_stream_buffers() con lo stream in questione. Tuttavia, il framework non è tenuto a registrare i buffer per tutti gli stream prima di inviare una richiesta. Ciò consente l'avvio rapido, ad esempio, di uno stream di anteprima, con l'allocazione di altri stream in un secondo momento o contemporaneamente.

---

Solo CAMERA_DEVICE_API_VERSION_3_1:

Ripristina la pipeline di elaborazione del dispositivo della videocamera HAL e configura nuovi stream di input e output. Questa chiamata sostituisce qualsiasi configurazione di stream esistente con gli stream definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo initialize() prima che venga inviata una richiesta con process_capture_request() .

L'elenco stream_list deve contenere almeno uno stream in grado di produrre output e non può contenere più di uno stream in grado di ricevere input.

L'elenco stream_list può contenere stream che si trovano anche nell'insieme di stream attualmente attivo (dalla chiamata precedente a configure_stream()). Questi stream avranno già valori validi per usage, max_buffers e il puntatore privato.

Se per uno stream sono già stati registrati i relativi buffer, register_stream_buffers() non verrà richiamato di nuovo per lo stream e i buffer dello stream potranno essere inclusi immediatamente nelle richieste di input.

Se l'HAL deve modificare la configurazione di uno stream esistente a causa della nuova configurazione, potrebbe riscrivere i valori di usage e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà questa modifica, riallocherà i buffer dello stream e chiamerà nuovamente register_stream_buffers() prima di utilizzare i buffer di questo stream in una richiesta.

Se uno stream attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in sicurezza tutti i riferimenti a questo stream. Non verrà riutilizzato in una chiamata successiva di configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati al termine del ritorno della chiamata configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi al termine di questa chiamata. L'indirizzo di una singola struttura camera3_stream_t rimarrà valido per l'accesso da parte dell'HAL fino alla fine della prima chiamata di configure_stream(), che non include più la struttura camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura dello stream al di fuori del puntatore privato, ad eccezione dei membri usage e max_buffers durante la chiamata stessa di configure_streams() .

Se lo stream è nuovo, i campi max_buffer e private pointer della struttura dello stream verranno impostati su 0. L'utilizzo verrà impostato sui flag di utilizzo dei consumatori. Il dispositivo HAL deve impostare questi campi prima che la chiamata configure_streams() restituisca. Questi campi vengono poi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ogni stream.

Prima che i buffer di un nuovo stream possano essere inclusi in una richiesta di acquisizione, il framework chiamerà register_stream_buffers() con lo stream in questione. Tuttavia, il framework non è tenuto a registrare i buffer per tutti gli stream prima di inviare una richiesta. Ciò consente l'avvio rapido, ad esempio, di uno stream di anteprima, con l'allocazione di altri stream in un secondo momento o contemporaneamente.

---

>= CAMERA_DEVICE_API_VERSION_3_2:

Ripristina la pipeline di elaborazione del dispositivo della videocamera HAL e configura nuovi stream di input e output. Questa chiamata sostituisce qualsiasi configurazione di stream esistente con gli stream definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo initialize() prima che venga inviata una richiesta con process_capture_request() .

L'elenco stream_list deve contenere almeno uno stream in grado di produrre output e non può contenere più di uno stream in grado di ricevere input.

L'elenco stream_list può contenere stream che si trovano anche nell'insieme di stream attualmente attivo (dalla chiamata precedente a configure_stream()). Questi stream avranno già valori validi per usage, max_buffers e il puntatore privato.

Se l'HAL deve modificare la configurazione di uno stream esistente a causa della nuova configurazione, potrebbe riscrivere i valori di usage e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà questa modifica e potrà quindi riallocare i buffer dello stream prima di utilizzarli in una richiesta.

Se uno stream attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in sicurezza tutti i riferimenti a questo stream. Non verrà riutilizzato in una chiamata successiva di configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati al termine del ritorno della chiamata configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi al termine di questa chiamata. L'indirizzo di una singola struttura camera3_stream_t rimarrà valido per l'accesso da parte dell'HAL fino alla fine della prima chiamata di configure_stream(), che non include più la struttura camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura dello stream al di fuori del puntatore privato, ad eccezione dei membri usage e max_buffers durante la chiamata stessa di configure_streams() .

Se lo stream è nuovo, i campi max_buffer e private pointer della struttura dello stream verranno impostati su 0. L'utilizzo verrà impostato sui flag di utilizzo dei consumatori. Il dispositivo HAL deve impostare questi campi prima che la chiamata configure_streams() restituisca. Questi campi vengono poi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ogni stream.

I buffer appena allocati possono essere inclusi in una richiesta di acquisizione in qualsiasi momento dal framework. Una volta che un buffer gralloc viene restituito al framework con process_capture_result (e il relativo release_fence è stato segnalato), il framework può liberarlo o riutilizzarlo in qualsiasi momento.

---

Condizioni preliminari:

Il framework chiamerà questo metodo solo quando non vengono elaborate acquisizioni. In altre parole, tutti i risultati sono stati restituiti al framework, tutti i buffer di input e output in-flight sono stati restituiti e le relative barriere di sincronizzazione di rilascio sono state segnalate dall'HAL. Il framework non invierà nuove richieste di acquisizione mentre è in corso la chiamata configure_streams() .

Postcondizioni:

Il dispositivo HAL deve configurarsi per fornire la frequenza fotogrammi di output massima possibile in base alle dimensioni e ai formati degli stream di output, come documentato nei metadati statici del dispositivo della fotocamera.

Requisiti di rendimento:

Questa chiamata dovrebbe essere pesante e potrebbe richiedere diverse centinaia di millisecondi per essere completata, poiché potrebbe richiedere la reimpostazione e la riconfigurazione del sensore di immagine e della pipeline di elaborazione della fotocamera. Tuttavia, il dispositivo HAL deve tentare di ridurre al minimo il ritardo di ricofigurazione per ridurre al minimo le interruzioni visibili all'utente durante le modifiche della modalità operativa dell'applicazione (ad esempio il passaggio dall'acquisizione di foto alla registrazione video).

L'HAL dovrebbe tornare da questa chiamata in 500 ms e deve tornare da questa chiamata in 1000 ms.

Valori restituiti:

0: configurazione dello stream riuscita

-EINVAL: se la configurazione dello stream richiesta non è valida. Ecco alcuni esempi di configurazioni di stream non valide:

• Sono inclusi più di 1 stream con possibilità di inserimento (INPUT o BIDIRECTIONAL)
• Non sono inclusi stream con output (OUTPUT o BIDIRECTIONAL)
• Sono inclusi stream con formati non supportati o con dimensioni non supportate per quel formato.
• Sono inclusi troppi stream di output di un determinato formato.
• Configurazione di rotazione non supportata (si applica solo ai dispositivi con versione >= CAMERA_DEVICE_API_VERSION_3_3)
• Le dimensioni/i formati dello stream non soddisfano i requisiti di camera3_stream_configuration_t->operation_mode per la modalità non NORMAL o il valore operation_mode richiesto non è supportato dall'HAL. (si applica solo ai dispositivi con versione >= CAMERA_DEVICE_API_VERSION_3_3)

Tieni presente che l'invio da parte del framework di una configurazione dello stream non valida non è un'operazione normale, poiché le configurazioni dello stream vengono controllate prima della configurazione. Una configurazione non valida indica che esiste un bug nel codice del framework o che esiste una mancata corrispondenza tra i metadati statici dell'HAL e i requisiti degli stream.

-ENODEV: se si è verificato un errore irreversibile e il dispositivo non è più operativo. Dopo il ritorno di questo errore, il framework può chiamare correttamente solo close().

Definizione nella riga 2769 del file camera3.h .

construct_default_request_settings:

Crea impostazioni di acquisizione per i casi d'uso standard della fotocamera.

Il dispositivo deve restituire un buffer delle impostazioni configurato per soddisfare il caso d'uso richiesto, che deve essere uno degli enum CAMERA3_TEMPLATE_* È necessario includere tutti i campi di controllo della richiesta.

L'HAL mantiene la proprietà di questa struttura, ma il puntatore alla struttura deve essere valido fino alla chiusura del dispositivo. Il framework e l'HAL potrebbero non modificare il buffer una volta restituito da questa chiamata. Lo stesso buffer può essere restituito per chiamate successive per lo stesso modello o per altri modelli.

Requisiti di rendimento:

Deve essere una chiamata non bloccante. L'HAL dovrebbe tornare da questa chiamata in 1 ms e deve tornare da questa chiamata in 5 ms.

Valori restituiti:

Metadati validi: dopo la creazione di un buffer delle impostazioni predefinite.

NULL: in caso di errore irreversibile. Dopo che questo valore è stato restituito, solo il metodo close() può essere chiamato correttamente dal framework.

Definizione nella riga 2859 del file camera3.h .

dump:

Stampa lo stato di debug del dispositivo della videocamera. Verrà chiamato dal framework quando al servizio della fotocamera viene richiesto un dump di debug, ad esempio quando si utilizza lo strumento dumpsys o quando si acquisisce un report di bug.

Il descrittore di file passato può essere utilizzato per scrivere il testo di debug utilizzando dprintf() o write(). Il testo deve essere solo in codifica ASCII.

Requisiti di rendimento:

Deve essere una chiamata non bloccante. L'HAL dovrebbe tornare da questa chiamata in 1 ms, deve tornare da questa chiamata in 10 ms. Questa chiamata deve evitare deadlock, in quanto può essere chiamata in qualsiasi momento durante il funzionamento della videocamera. Eventuali primitive di sincronizzazione utilizzate (come lock mutex o semafori) devono essere acquisite con un timeout.

Definizione nella riga 2971 del file camera3.h .

flush:

Svuotare tutti gli acquisimenti attualmente in corso e tutti i buffer nella pipeline sul dispositivo in questione. Il framework lo utilizzerà per scaricare tutto lo stato il più rapidamente possibile per prepararsi a una chiamata configure_streams() .

Non è necessario che i buffer vengano restituiti correttamente, pertanto ogni buffer trattenuto al momento di flush() (indipendentemente dal fatto che sia stato compilato o meno) può essere restituito con CAMERA3_BUFFER_STATUS_ERROR. Tieni presente che l'HAL è comunque autorizzato a restituire buffer validi (CAMERA3_BUFFER_STATUS_OK) durante questa chiamata, a condizione che vengano compilati correttamente.

Tutte le richieste attualmente nell'HAL dovrebbero essere restituite il prima possibile. Le richieste non in corso di elaborazione dovrebbero restituire immediatamente errori. Eventuali blocchi hardware interrompibili devono essere interrotti ed eventuali blocchi non interrompibili devono essere in attesa.

flush() può essere chiamato contemporaneamente a process_capture_request() , con la previsione che process_capture_request ritorni rapidamente e che la richiesta inviata nella chiamata process_capture_request venga trattata come tutte le altre richieste in corso. A causa di problemi di concorrenza, è possibile che dal punto di vista dell'HAL, una chiamata process_capture_request() possa essere avviata dopo l'invocazione di flush, ma non sia ancora tornata. Se una chiamata di questo tipo avviene prima che flush() restituiscano, l'HAL deve trattare la nuova richiesta di acquisizione come le altre richieste in attesa in corso (vedi punto 4 di seguito).

Nello specifico, l'HAL deve rispettare i seguenti requisiti per vari casi:

1. Per le acquisizioni troppo tardi per l'annullamento/l'interruzione da parte dell'HAL, che verranno completate normalmente dall'HAL; ovvero l'HAL può inviare shutter/notify e process_capture_result e i buffer come di consueto.
2. Per le richieste in attesa per le quali non è stata eseguita alcuna elaborazione, l'HAL deve chiamare notify CAMERA3_MSG_ERROR_REQUEST e restituire tutti i buffer di output con process_capture_result nello stato di errore (CAMERA3_BUFFER_STATUS_ERROR). L'HAL non deve impostare la barriera di rilascio in uno stato di errore, ma le barriere di rilascio devono essere impostate sulle barriere di acquisizione passate dal framework o su -1 se sono già state attese dall'HAL. Questo è anche il percorso da seguire per tutte le acquisizioni per le quali l'HAL ha già chiamato notify() con CAMERA3_MSG_SHUTTER, ma per le quali non verranno prodotti metadati/buffer validi. Dopo CAMERA3_MSG_ERROR_REQUEST, per un determinato frame sono consentiti solo i messaggi process_capture_results con buffer in CAMERA3_BUFFER_STATUS_ERROR. Non sono consentiti ulteriori notify o process_capture_result con metadati non null.

3. Per le richieste in attesa parzialmente completate che non avranno tutti i buffer di output o forse i metadati mancanti, l'HAL deve essere il seguente:

   3.1. Chiama notify con CAMERA3_MSG_ERROR_RESULT se alcuni dei metadati del risultato previsti (ad es. uno o più metadati parziali) non saranno disponibili per l'acquisizione.

   3.2. Chiama notify con CAMERA3_MSG_ERROR_BUFFER per ogni buffer che non verrà prodotto per l'acquisizione.

   3.3 Chiama notify con CAMERA3_MSG_SHUTTER con il timestamp dell'acquisizione prima che eventuali buffer/metadati vengano restituiti con process_capture_result.

   3.4 Per le acquisizioni che produrranno alcuni risultati, l'HAL non deve chiamare CAMERA3_MSG_ERROR_REQUEST, poiché indica un errore completo.

   3.5. I buffer/metadati validi devono essere passati al framework come di consueto.

   3.6. I buffer non riusciti devono essere restituiti al framework come descritto per la situazione 2. Tuttavia, i buffer non riusciti non devono seguire l'ordine rigoroso dei buffer validi e potrebbero essere fuori sequenza rispetto a questi ultimi. Ad esempio, se vengono inviati i buffer A, B, C, D ed E, D ed E non vanno a buon fine, quindi A, E, B, D e C è un ordine di restituzione accettabile.

   3.7. Per i metadati completamente mancanti, è sufficiente chiamare CAMERA3_MSG_ERROR_RESULT, non è necessario chiamare process_capture_result con metadati NULL o equivalenti.

4. Se viene invocato un flush() mentre è attiva un'invocazione di process_capture_request() la chiamata di processo deve restituire il risultato il prima possibile. Inoltre, se viene eseguita una chiamata process_capture_request() dopo che è stata invocata flush() ma prima che flush() sia stato restituito, la richiesta di acquisizione fornita dalla chiamata tardiva process_capture_request deve essere trattata come una richiesta in attesa nel caso 2 riportato sopra.

flush() deve essere restituito solo quando non sono presenti più buffer o richieste in sospeso nell'HAL. Il framework potrebbe chiamare configure_streams (poiché lo stato HAL è ora in stato di riposo) o potrebbe inviare nuove richieste.

Tieni presente che è sufficiente supportare solo i casi di risultati completamente riusciti e completamente non riusciti. Tuttavia, è molto consigliabile supportare anche i casi di errore parziale, in quanto potrebbero contribuire a migliorare il rendimento complessivo della chiamata di svuotamento.

Requisiti di rendimento:

L'HAL dovrebbe tornare da questa chiamata in 100 ms e deve tornare da questa chiamata in 1000 ms. Inoltre, questa chiamata non deve essere bloccata per più tempo della latenza della pipeline (vedi S7 per la definizione).

Informazioni sulla versione:

Disponibile solo se la versione del dispositivo è >= CAMERA_DEVICE_API_VERSION_3_1.

Valori restituiti:

0: dopo l'aggiornamento dell'HAL della fotocamera.

-EINVAL: se l'input non è formattato correttamente (il dispositivo non è valido).

-ENODEV: se il dispositivo della videocamera ha rilevato un errore grave. Dopo che viene restituito questo errore, il framework può chiamare correttamente solo il metodo close().

Definizione nella riga 3077 del file camera3.h .

get_metadata_vendor_tag_ops:

Ottieni metodi per eseguire query sulle informazioni dei tag dei metadati delle estensioni del fornitore. L'HAL deve compilare tutti i metodi di operazione dei tag del fornitore o lasciare invariate le operazioni se non sono definiti tag del fornitore.

La definizione di vendor_tag_query_ops_t è disponibile in system/media/camera/include/system/camera_metadata.h.

>= CAMERA_DEVICE_API_VERSION_3_2: DEPRECATED. Questa funzione è stata ritirata e deve essere impostata su NULL dall'HAL. Implementa get_vendor_tag_ops in camera_common.h al suo posto.

Definizione nella riga 2950 del file camera3.h .

initialize:

Inizializzazione una tantum per passare i puntatori alle funzioni di callback del framework all'HAL. Verrà chiamata una volta dopo una chiamata open() riuscita, prima che vengano chiamate altre funzioni nella struttura camera3_device_ops .

Requisiti di rendimento:

Deve essere una chiamata non bloccante. L'HAL dovrebbe tornare da questa chiamata in 5 ms e deve tornare da questa chiamata in 10 ms.

Valori restituiti:

0: in caso di inizializzazione riuscita

-ENODEV: se l'inizializzazione non va a buon fine. Dopodiché, solo close() può essere chiamato correttamente dal framework.

Definizione nella riga 2530 del file camera3.h .

process_capture_request:

Invia una nuova richiesta di acquisizione all'HAL. L'HAL non deve tornare da questa chiamata finché non è pronto ad accettare la richiesta successiva da elaborare. Il framework effettuerà una sola chiamata alla volta a process_capture_request() e tutte le chiamate provengono dallo stesso thread. La chiamata successiva a process_capture_request() verrà effettuata non appena saranno disponibili una nuova richiesta e i relativi buffer associati. In uno scenario di anteprima normale, significa che la funzione verrà richiamata di nuovo dal framework quasi istantaneamente.

L'elaborazione effettiva della richiesta è asincrona e i risultati dell'acquisizione vengono restituiti dall'HAL tramite la chiamata process_capture_result(). Questa chiamata richiede che i metadati del risultato siano disponibili, ma i buffer di output possono semplicemente fornire barriere di sincronizzazione da attendere. È previsto che più richieste vengano inviate contemporaneamente per mantenere la frequenza fotogrammi di output completa.

Il framework mantiene la proprietà della struttura della richiesta. È garantito che sia valido solo durante questa chiamata. Il dispositivo HAL deve creare copie delle informazioni che deve conservare per l'elaborazione dell'acquisizione. L'HAL è responsabile dell'attesa e della chiusura delle recinti dei buffer e del ritorno dei handle dei buffer al framework.

L'HAL deve scrivere il descrittore file per la barriera di sincronizzazione di rilascio del buffer di input in input_buffer->release_fence, se input_buffer non è NULL. Se l'HAL restituisce -1 per la barriera di sincronizzazione di rilascio del buffer di input, il framework è libero di riutilizzare immediatamente il buffer di input. In caso contrario, il framework attenderà la recinzione di sincronizzazione prima di riempire e riutilizzare il buffer di input.

>= CAMERA_DEVICE_API_VERSION_3_2:

I buffer di input/output forniti dal framework in ogni richiesta potrebbero essere nuovi di zecca (non sono mai stati visti dall'HAL).

---

Considerazioni sulle prestazioni:

La gestione di un nuovo buffer deve essere estremamente leggera e non deve essere introdotto alcun degrado della frequenza fotogrammi o jitter dei fotogrammi.

Questa chiamata deve restituire un valore sufficientemente rapido per garantire che la frequenza fotogrammi richiesta possa essere sostenuta, in particolare per i casi di streaming (impostazioni di qualità di post-elaborazione impostate su VELOCE). L'HAL deve restituire questa chiamata in un intervallo di 1 frame e deve tornare da questa chiamata in 4 intervalli di frame.

Valori restituiti:

0: all'avvio dell'elaborazione della richiesta di acquisizione

-EINVAL: se l'input non è formattato correttamente (le impostazioni sono NULL quando non sono consentite, non sono presenti buffer di output e così via) e non è possibile avviare l'elaborazione dell'acquisizione. Gli errori durante l'elaborazione della richiesta devono essere gestiti chiamando camera3_callback_ops_t.notify() . In caso di questo errore, il framework manterrà la responsabilità per le barriere e gli handle dei buffer dello stream; l'HAL non deve chiudere le barriere o restituire questi buffer con process_capture_result.

-ENODEV: se il dispositivo della videocamera ha rilevato un errore grave. Dopo che viene restituito questo errore, il framework può chiamare correttamente solo il metodo close().

Definizione nella riga 2928 del file camera3.h .

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

OBSOLETO. Questo valore non verrà chiamato e deve essere impostato su NULL.

<= CAMERA_DEVICE_API_VERSION_3_1:

Registra i buffer per un determinato stream con il dispositivo HAL. Questo metodo viene chiamato dal framework dopo che un nuovo stream è stato definito da configure_streams e prima che i buffer di questo stream vengano inclusi in una richiesta di acquisizione. Se lo stesso stream è elencato in una chiamata configure_streams() successiva, register_stream_buffers non verrà chiamato di nuovo per lo stream.

Il framework non deve registrare i buffer per tutti gli stream configurati prima di inviare la prima richiesta di acquisizione. Ciò consente un avvio rapido per l'anteprima (o casi d'uso simili) mentre altri stream sono ancora in fase di allocazione.

Questo metodo è progettato per consentire al dispositivo HAL di mappare o preparare in altro modo i buffer per un uso successivo. I buffer passati saranno già bloccati per l'utilizzo. Al termine della chiamata, tutti i buffer devono essere pronti per essere restituiti allo stream. L'argomento buffer_set è valido solo per la durata di questa chiamata.

Se il formato dello stream è impostato su HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, l'HAL della fotocamera deve ispezionare i buffer passati per determinare eventuali informazioni sul formato dei pixel private della piattaforma.

Requisiti di rendimento:

Deve essere una chiamata non bloccante. L'HAL dovrebbe tornare da questa chiamata in 1 ms e deve tornare da questa chiamata in 5 ms.

Valori restituiti:

0: dopo la registrazione riuscita dei nuovi buffer di stream

-EINVAL: se stream_buffer_set non fa riferimento a uno stream attivo valido o se l'array di buffer non è valido.

-ENOMEM: se si è verificato un errore durante la registrazione dei buffer. Il framework deve considerare tutti i buffer dello stream non registrati e può provare a registrarli di nuovo in un secondo momento.

-ENODEV: se si verifica un errore irreversibile e il dispositivo non è più operativo. Dopo il ritorno di questo errore, il framework può chiamare correttamente solo close().

Definizione alla riga 2823 del file camera3.h .

Definizione alla riga 3080 del file camera3.h .