riferimento alla struttura camera3_device_ops

configure_streams:

Solo CAMERA_DEVICE_API_VERSION_3_0:

Reimpostare la pipeline di elaborazione del dispositivo fotocamera HAL e impostare nuovi flussi di input e output. Questa chiamata sostituisce qualsiasi configurazione di flusso esistente con i flussi definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo inizializzare() prima che venga inviata una richiesta con process_capture_request() .

stream_list deve contenere almeno un flusso con capacità di output e non può contenere più di un flusso con capacità di input.

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

Se un flusso di questo tipo ha già registrato i suoi buffer, Register_stream_buffers() non verrà chiamato nuovamente per il flusso e i buffer del flusso potranno essere immediatamente inclusi nelle richieste di input.

Se l'HAL deve modificare la configurazione del flusso per un flusso esistente a causa della nuova configurazione, potrebbe riscrivere i valori di utilizzo e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà tale modifica, quindi riallocherà i buffer del flusso e chiamerà nuovamente Register_stream_buffers() prima di utilizzare i buffer di quel flusso in una richiesta.

Se un flusso attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in modo sicuro qualsiasi riferimento a quel flusso. Non verrà riutilizzato in una successiva chiamata a configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati dopo il ritorno della chiamata a configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi una volta completata 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 configure_stream() che non include più quella camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura del flusso al di fuori del puntatore privato, ad eccezione dei membri di utilizzo e max_buffers durante la chiamata configure_streams() stessa.

Se il flusso è nuovo, i campi di utilizzo, max_buffer e puntatore privato della struttura del flusso verranno tutti impostati su 0. Il dispositivo HAL deve impostare questi campi prima che venga restituita la chiamata configure_streams() . Questi campi vengono quindi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ciascun flusso.

Prima che un nuovo flusso di questo tipo possa includere i propri buffer in una richiesta di acquisizione, il framework chiamerà Register_stream_buffers() con quel flusso. Tuttavia, il framework non è tenuto a registrare i buffer per tutti i flussi prima di inviare una richiesta. Ciò consente l'avvio rapido (ad esempio) di un flusso di anteprima, con l'allocazione per altri flussi che avviene successivamente o contemporaneamente.

Solo CAMERA_DEVICE_API_VERSION_3_1:

Reimpostare la pipeline di elaborazione del dispositivo fotocamera HAL e impostare nuovi flussi di input e output. Questa chiamata sostituisce qualsiasi configurazione di flusso esistente con i flussi definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo inizializzare() prima che venga inviata una richiesta con process_capture_request() .

stream_list deve contenere almeno un flusso con capacità di output e non può contenere più di un flusso con capacità di input.

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

Se un flusso di questo tipo ha già registrato i suoi buffer, Register_stream_buffers() non verrà chiamato nuovamente per il flusso e i buffer del flusso potranno essere immediatamente inclusi nelle richieste di input.

Se l'HAL deve modificare la configurazione del flusso per un flusso esistente a causa della nuova configurazione, potrebbe riscrivere i valori di utilizzo e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà tale modifica, quindi riallocherà i buffer del flusso e chiamerà nuovamente Register_stream_buffers() prima di utilizzare i buffer di quel flusso in una richiesta.

Se un flusso attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in modo sicuro qualsiasi riferimento a quel flusso. Non verrà riutilizzato in una successiva chiamata a configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati dopo il ritorno della chiamata a configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi una volta completata 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 configure_stream() che non include più quella camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura del flusso al di fuori del puntatore privato, ad eccezione dei membri di utilizzo e max_buffers durante la chiamata configure_streams() stessa.

Se il flusso è nuovo, i campi max_buffer e puntatore privato della struttura del flusso verranno tutti impostati su 0. L'utilizzo verrà impostato sui flag di utilizzo del consumatore. Il dispositivo HAL deve impostare questi campi prima che venga restituita la chiamata configure_streams() . Questi campi vengono quindi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ciascun flusso.

Prima che un nuovo flusso di questo tipo possa includere i propri buffer in una richiesta di acquisizione, il framework chiamerà Register_stream_buffers() con quel flusso. Tuttavia, il framework non è tenuto a registrare i buffer per tutti i flussi prima di inviare una richiesta. Ciò consente l'avvio rapido (ad esempio) di un flusso di anteprima, con l'allocazione per altri flussi che avviene successivamente o contemporaneamente.

>= CAMERA_DEVICE_API_VERSION_3_2:

Reimpostare la pipeline di elaborazione del dispositivo fotocamera HAL e impostare nuovi flussi di input e output. Questa chiamata sostituisce qualsiasi configurazione di flusso esistente con i flussi definiti in stream_list. Questo metodo verrà chiamato almeno una volta dopo inizializzare() prima che venga inviata una richiesta con process_capture_request() .

stream_list deve contenere almeno un flusso con capacità di output e non può contenere più di un flusso con capacità di input.

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

Se l'HAL deve modificare la configurazione del flusso per un flusso esistente a causa della nuova configurazione, potrebbe riscrivere i valori di utilizzo e/o max_buffers durante la chiamata di configurazione.

Il framework rileverà tale modifica e potrebbe quindi riallocare i buffer del flusso prima di utilizzare i buffer di quel flusso in una richiesta.

Se un flusso attualmente attivo non è incluso in stream_list, l'HAL può rimuovere in modo sicuro qualsiasi riferimento a quel flusso. Non verrà riutilizzato in una successiva chiamata a configure() da parte del framework e tutti i relativi buffer gralloc verranno liberati dopo il ritorno della chiamata a configure_streams() .

La struttura stream_list è di proprietà del framework e non è possibile accedervi una volta completata 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 configure_stream() che non include più quella camera3_stream_t nell'argomento stream_list. L'HAL non può modificare i valori nella struttura del flusso al di fuori del puntatore privato, ad eccezione dei membri di utilizzo e max_buffers durante la chiamata configure_streams() stessa.

Se il flusso è nuovo, i campi max_buffer e puntatore privato della struttura del flusso verranno tutti impostati su 0. L'utilizzo verrà impostato sui flag di utilizzo del consumatore. Il dispositivo HAL deve impostare questi campi prima che venga restituita la chiamata configure_streams() . Questi campi vengono quindi utilizzati dal framework e dal modulo gralloc della piattaforma per allocare i buffer gralloc per ciascun flusso.

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 suo rispettivo release_fence è stato segnalato) il framework può liberarlo o riutilizzarlo in qualsiasi momento.

Precondizioni:

Il framework chiamerà questo metodo solo quando non vengono elaborate acquisizioni. Cioè, tutti i risultati sono stati restituiti al framework e tutti i buffer di input e output in volo sono stati restituiti e i relativi limiti di sincronizzazione del rilascio sono stati segnalati 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 massima frequenza fotogrammi di output possibile in base alle dimensioni e ai formati dei flussi di output, come documentato nei metadati statici del dispositivo fotocamera.

Requisiti di prestazione:

Si prevede che questa chiamata sarà pesante e potrebbe richiedere diverse centinaia di millisecondi per essere completata, poiché potrebbe richiedere il ripristino 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 riconfigurazione per ridurre al minimo le pause visibili all'utente durante le modifiche alla modalità operativa dell'applicazione (ad esempio il passaggio dall'acquisizione di immagini fisse 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: in caso di configurazione del flusso riuscita

-EINVAL: se la configurazione del flusso richiesta non è valida. Alcuni esempi di configurazioni di streaming non valide includono:

• Includere più di 1 flusso con capacità di input (INPUT o BIDIREZIONALE)
• Escluso qualsiasi flusso con capacità di output (OUTPUT o BIDIREZIONALE)
• Inclusi stream con formati non supportati o dimensioni non supportate per quel formato.
• Includere troppi flussi di output di un determinato formato.
• Configurazione della rotazione non supportata (si applica solo ai dispositivi con versione >= CAMERA_DEVICE_API_VERSION_3_3)
• Le dimensioni/formati del flusso non soddisfano i requisiti camera3_stream_configuration_t->Operation_mode per la modalità non NORMAL oppure l'operazione_mode richiesta non è supportata dall'HAL. (vale solo per i dispositivi con versione >= CAMERA_DEVICE_API_VERSION_3_3)

Tieni presente che il framework che invia una configurazione di flusso non valida non è un funzionamento normale, poiché le configurazioni di flusso vengono controllate prima della configurazione. Una configurazione non valida significa che esiste un bug nel codice del framework o che esiste una mancata corrispondenza tra i metadati statici dell'HAL e i requisiti sui flussi.

-ENODEV: Se si è verificato un errore fatale e il dispositivo non è più operativo. Solo close() può essere chiamato correttamente dal framework dopo che è stato restituito questo errore.

Definizione alla riga 2769 del file camera3.h .

build_default_request_settings:

Crea impostazioni di acquisizione per 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 una delle enumerazioni CAMERA3_TEMPLATE_*. Tutti i campi di controllo della richiesta devono essere inclusi.

L'HAL mantiene la proprietà di questa struttura, ma il puntatore alla struttura deve essere valido finché il dispositivo non viene chiuso. Il framework e l'HAL non possono 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 prestazione:

Dovrebbe 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 riuscita di un buffer delle impostazioni predefinite.

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

Definizione alla riga 2859 del file camera3.h .

scarico:

Stampa lo stato di debug per il dispositivo fotocamera. Questo verrà chiamato dal framework quando al servizio fotocamera viene richiesto un dump di debug, cosa che accade quando si utilizza lo strumento dumpsys o quando si cattura un bugreport.

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

Requisiti di prestazione:

Questa 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 situazioni di stallo, poiché può essere chiamata in qualsiasi momento durante il funzionamento della telecamera. Eventuali primitive di sincronizzazione utilizzate (come blocchi mutex o semafori) devono essere acquisite con un timeout.

Definizione alla riga 2971 del file camera3.h .

sciacquone:

Svuota tutte le acquisizioni attualmente in corso e tutti i buffer nella pipeline sul dispositivo specificato. 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 con successo, quindi ogni buffer mantenuto al momento di flush() (sia riempito con successo o meno) può essere restituito con CAMERA3_BUFFER_STATUS_ERROR. Tieni presente che all'HAL è ancora consentito restituire buffer validi (CAMERA3_BUFFER_STATUS_OK) durante questa chiamata, a condizione che vengano riempiti correttamente.

Si prevede che tutte le richieste attualmente presenti nell'HAL vengano restituite il prima possibile. Le richieste non in elaborazione dovrebbero restituire immediatamente errori. Qualsiasi blocco hardware interrompibile deve essere interrotto e qualsiasi blocco non interrompibile deve essere atteso.

flush() può essere chiamato contemporaneamente a process_capture_request() , con l'aspettativa che process_capture_request ritorni rapidamente e la richiesta inviata in quella chiamata process_capture_request venga trattata come tutte le altre richieste in volo. A causa di problemi di concorrenza, è possibile che dal punto di vista dell'HAL, una chiamata process_capture_request() possa essere avviata dopo che flush è stato richiamato ma non è ancora stato restituito. Se tale chiamata avviene prima che flush() ritorni, l'HAL dovrebbe trattare la nuova richiesta di acquisizione come altre richieste in sospeso in corso (vedere il punto 4 di seguito).

Più specificamente, l'HAL deve seguire i seguenti requisiti per vari casi:

1. Per le acquisizioni che sono troppo tardi perché l'HAL possa annullarle/interromperle e che verranno completate normalmente dall'HAL; ovvero l'HAL può inviare shutter/notify e process_capture_result e buffer normalmente.
2. Per le richieste in sospeso che non hanno eseguito alcuna elaborazione, l'HAL deve chiamare la notifica 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 posizionare il recinto di rilascio in uno stato di errore, invece, i recinti di rilascio devono essere impostati sui recinti di acquisizione passati dal framework o -1 se sono già stati attesi dall'HAL. Questo è anche il percorso da seguire per qualsiasi acquisizione per la quale l'HAL ha già chiamato notify() con CAMERA3_MSG_SHUTTER ma per la quale non produrrà metadati/buffer validi. Dopo CAMERA3_MSG_ERROR_REQUEST, per un determinato fotogramma, sono consentiti solo process_capture_results con buffer in CAMERA3_BUFFER_STATUS_ERROR. Non sono consentite ulteriori notifiche o process_capture_result con metadati diversi da null.

3. Per le richieste in sospeso parzialmente completate che non avranno tutti i buffer di output o forse metadati mancanti, l'HAL dovrebbe seguire di seguito:

   3.1. Chiama la notifica con CAMERA3_MSG_ERROR_RESULT se alcuni dei metadati dei risultati attesi (ovvero uno o più metadati parziali) non saranno disponibili per l'acquisizione.

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

   3.3 Notifica chiamata con CAMERA3_MSG_SHUTTER con il timestamp di 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é ciò indica un fallimento completo.

   3.5. Buffer/metadati validi devono essere passati al framework normalmente.

   3.6. I buffer con errori dovrebbero essere restituiti al framework come descritto per il caso 2. Ma i buffer con errori non devono seguire l'ordinamento rigoroso seguito dai buffer validi e potrebbero essere fuori ordine rispetto ai buffer validi. Ad esempio, se i buffer A, B, C, D, E vengono inviati, D ed E non funzionano, allora A, E, B, D, C è un ordine di reso 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 al processo dovrebbe ritornare il prima possibile. Inoltre, se viene effettuata una chiamata a process_capture_request() dopo che flush() è stato invocato ma prima che flush() sia ritornato, la richiesta di acquisizione fornita dall'ultima chiamata process_capture_request dovrebbe essere trattata come una richiesta in sospeso nel caso #2 sopra.

flush() dovrebbe restituire solo quando non ci sono più buffer o richieste in sospeso nell'HAL. Il framework può chiamare configure_streams (poiché lo stato HAL è ora inattivo) o può emettere nuove richieste.

Tieni presente che è sufficiente supportare solo i casi di risultati completamente riusciti e completamente falliti. Tuttavia, è altamente auspicabile supportare anche i casi di fallimento parziale, poiché potrebbe contribuire a migliorare le prestazioni complessive della chiamata di scarico.

Requisiti di prestazione:

L'HAL dovrebbe tornare da questa chiamata in 100 ms e deve tornare da questa chiamata in 1000 ms. E questa chiamata non deve essere bloccata per un periodo superiore alla latenza della pipeline (per la definizione vedere S7).

Informazioni sulla versione:

disponibile solo se la versione del dispositivo >= CAMERA_DEVICE_API_VERSION_3_1.

Valori restituiti:

0: in caso di svuotamento riuscito dell'HAL della fotocamera.

-EINVAL: Se l'input non è valido (il dispositivo non è valido).

-ENODEV: se il dispositivo fotocamera ha riscontrato un errore grave. Dopo che viene restituito questo errore, solo il metodo close() può essere chiamato con successo dal framework.

Definizione alla riga 3077 del file camera3.h .

get_metadata_vendor_tag_ops:

Ottieni metodi per eseguire query sulle informazioni sui tag dei metadati dell'estensione del fornitore. L'HAL deve compilare tutti i metodi operativi dei tag del fornitore o lasciare le operazioni invariate se non sono definiti i tag del fornitore.

La definizione di seller_tag_query_ops_t è reperibile in system/media/camera/include/system/camera_metadata.h.

>= CAMERA_DEVICE_API_VERSION_3_2: OBSOLETO. Questa funzione è stata deprecata e dovrebbe essere impostata su NULL dall'HAL. Implementa invece get_vendor_tag_ops in camera_common.h .

Definizione alla riga 2950 del file camera3.h .

inizializzare:

Inizializzazione una tantum per passare i puntatori della funzione di callback del framework all'HAL. Verrà chiamato una volta dopo una chiamata open() riuscita, prima che venga chiamata qualsiasi altra funzione sulla struttura camera3_device_ops .

Requisiti di prestazione:

Dovrebbe 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 fallisce. Solo close() può essere chiamato con successo dal framework dopo questo.

Definizione alla riga 2530 del file camera3.h .

process_capture_request:

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

L'effettiva elaborazione della richiesta è asincrona, con i risultati dell'acquisizione restituiti dall'HAL tramite la chiamata process_capture_result(). Questa chiamata richiede che i metadati dei risultati siano disponibili, ma i buffer di output possono semplicemente fornire recinti di sincronizzazione in attesa. È previsto che più richieste siano in esecuzione contemporaneamente, per mantenere la frequenza fotogrammi di output completa.

Il framework mantiene la proprietà della struttura della richiesta. La sua validità è garantita 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 dei recinti dei buffer e della restituzione degli handle del buffer al framework.

L'HAL deve scrivere il descrittore di file per il recinto di sincronizzazione del rilascio del buffer di input in input_buffer->release_fence, se input_buffer non è NULL. Se l'HAL restituisce -1 per il limite di sincronizzazione del rilascio del buffer di input, il framework è libero di riutilizzare immediatamente il buffer di input. Altrimenti, il framework attenderà sul recinto 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 ciascuna richiesta possono essere nuovi di zecca (mai visti prima dall'HAL).

Considerazioni sulle prestazioni:

La gestione di un nuovo buffer dovrebbe essere estremamente leggera e non dovrebbe verificarsi alcun degrado del frame rate o jitter del frame.

Questa chiamata deve tornare abbastanza velocemente da garantire che la frequenza fotogrammi richiesta possa essere sostenuta, soprattutto per i casi di streaming (impostazioni di qualità post-elaborazione impostate su FAST). L'HAL deve restituire questa chiamata in intervalli di 1 frame e deve restituire questa chiamata in intervalli di 4 frame.

Valori restituiti:

0: in caso di avvio corretto dell'elaborazione della richiesta di acquisizione

-EINVAL: se l'input non è valido (le impostazioni sono NULL quando non consentite, ci sono 0 buffer di output, ecc.) e l'elaborazione dell'acquisizione non può essere avviata. 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à delle recinzioni dei buffer del flusso e degli handle del buffer; l'HAL non dovrebbe chiudere i recinti o restituire questi buffer con process_capture_result.

-ENODEV: se il dispositivo fotocamera ha riscontrato un errore grave. Dopo che viene restituito questo errore, solo il metodo close() può essere chiamato con successo dal framework.

Definizione alla riga 2928 del file camera3.h .

Register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

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

<= CAMERA_DEVICE_API_VERSION_3_1:

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

Non è necessario che il framework registri i buffer per tutti i flussi configurati prima di inviare la prima richiesta di acquisizione. Ciò consente un avvio rapido per l'anteprima (o casi d'uso simili) mentre altri flussi sono ancora in fase di allocazione.

Questo metodo ha lo scopo di consentire al dispositivo HAL di mappare o preparare in altro modo i buffer per un utilizzo successivo. I buffer passati saranno già bloccati per l'uso. 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 del flusso è stato impostato su HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, l'HAL della fotocamera dovrebbe controllare i buffer passati qui per determinare eventuali informazioni sul formato pixel privato della piattaforma.

Requisiti di prestazione:

Dovrebbe 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: in caso di registrazione riuscita dei nuovi buffer di flusso

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

-ENOMEM: se si è verificato un errore nella registrazione dei buffer. Il framework deve considerare tutti i buffer di flusso come non registrati e può provare a registrarli nuovamente in un secondo momento.

-ENODEV: se si verifica un errore irreversibile e il dispositivo non è più operativo. Solo close() può essere chiamato correttamente dal framework dopo che è stato restituito questo errore.

Definizione alla riga 2823 del file camera3.h .

Definizione alla riga 3080 del file camera3.h .