Référence de la struct camera3_device_ops

configure_streams:

CAMERA_DEVICE_API_VERSION_3_0 uniquement:

Réinitialisez le pipeline de traitement de l'appareil photo HAL et configurez de nouveaux flux d'entrée et de sortie. Cet appel remplace toute configuration de flux existante par les flux définis dans stream_list. Cette méthode est appelée au moins une fois après initialize() avant qu'une requête ne soit envoyée avec process_capture_request() .

La liste stream_list doit contenir au moins un flux compatible avec la sortie et ne peut pas contenir plus d'un flux compatible avec l'entrée.

La liste stream_list peut contenir des flux qui figurent également dans l'ensemble de flux actuellement actif (à partir de l'appel précédent à configure_stream()). Ces flux auront déjà des valeurs valides pour l'utilisation, max_buffers et le pointeur privé.

Si les tampons d'un tel flux ont déjà été enregistrés, register_stream_buffers() ne sera pas appelé à nouveau pour le flux, et les tampons du flux peuvent être immédiatement inclus dans les requêtes d'entrée.

Si le HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, il peut réécrire les valeurs d'utilisation et/ou de max_buffers lors de l'appel de configuration.

Le framework détectera ce changement, puis réallouera les tampons de flux et appellera à nouveau register_stream_buffers() avant d'utiliser les tampons de ce flux dans une requête.

Si un flux actuellement actif n'est pas inclus dans stream_list, le HAL peut supprimer en toute sécurité toutes les références à ce flux. Il ne sera pas réutilisé dans un appel configure() ultérieur par le framework, et tous les tampons gralloc associés seront libérés après le retour de l'appel configure_streams() .

La structure stream_list appartient au framework et ne peut pas être accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par le HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus cette camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs de la structure de flux en dehors du pointeur privé, sauf pour les membres "usage" et "max_buffers" lors de l'appel configure_streams() .

Si le flux est nouveau, les champs "usage", "max_buffer" et "pointeur privé" de la structure de flux sont tous définis sur 0. L'appareil HAL doit définir ces champs avant le retour de l'appel configure_streams() . Ces champs sont ensuite utilisés par le framework et le module gralloc de la plate-forme pour allouer les tampons gralloc pour chaque flux.

Avant que les tampons d'un nouveau flux puissent être inclus dans une requête de capture, le framework appelle register_stream_buffers() avec ce flux. Toutefois, le framework n'est pas tenu d'enregistrer des tampons pour tous les flux avant d'envoyer une requête. Cela permet de démarrer rapidement (par exemple) un flux d'aperçu, avec une allocation pour d'autres flux qui se produit plus tard ou simultanément.

---

CAMERA_DEVICE_API_VERSION_3_1 uniquement:

Réinitialisez le pipeline de traitement de l'appareil photo HAL et configurez de nouveaux flux d'entrée et de sortie. Cet appel remplace toute configuration de flux existante par les flux définis dans stream_list. Cette méthode est appelée au moins une fois après initialize() avant qu'une requête ne soit envoyée avec process_capture_request() .

La liste stream_list doit contenir au moins un flux compatible avec la sortie et ne peut pas contenir plus d'un flux compatible avec l'entrée.

La liste stream_list peut contenir des flux qui figurent également dans l'ensemble de flux actuellement actif (à partir de l'appel précédent à configure_stream()). Ces flux auront déjà des valeurs valides pour l'utilisation, max_buffers et le pointeur privé.

Si les tampons d'un tel flux ont déjà été enregistrés, register_stream_buffers() ne sera pas appelé à nouveau pour le flux, et les tampons du flux peuvent être immédiatement inclus dans les requêtes d'entrée.

Si le HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, il peut réécrire les valeurs d'utilisation et/ou de max_buffers lors de l'appel de configuration.

Le framework détectera ce changement, puis réallouera les tampons de flux et appellera à nouveau register_stream_buffers() avant d'utiliser les tampons de ce flux dans une requête.

Si un flux actuellement actif n'est pas inclus dans stream_list, le HAL peut supprimer en toute sécurité toutes les références à ce flux. Il ne sera pas réutilisé dans un appel configure() ultérieur par le framework, et tous les tampons gralloc associés seront libérés après le retour de l'appel configure_streams() .

La structure stream_list appartient au framework et ne peut pas être accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par le HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus cette camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs de la structure de flux en dehors du pointeur privé, sauf pour les membres "usage" et "max_buffers" lors de l'appel configure_streams() .

Si le flux est nouveau, les champs "max_buffer" et "pointeur privé" de la structure de flux sont tous définis sur 0. L'utilisation sera définie sur les indicateurs d'utilisation par le consommateur. L'appareil HAL doit définir ces champs avant le retour de l'appel configure_streams() . Ces champs sont ensuite utilisés par le framework et le module gralloc de la plate-forme pour allouer les tampons gralloc pour chaque flux.

Avant que les tampons d'un nouveau flux puissent être inclus dans une requête de capture, le framework appelle register_stream_buffers() avec ce flux. Toutefois, le framework n'est pas tenu d'enregistrer des tampons pour tous les flux avant d'envoyer une requête. Cela permet de démarrer rapidement (par exemple) un flux d'aperçu, avec une allocation pour d'autres flux qui se produit plus tard ou simultanément.

---

>= CAMERA_DEVICE_API_VERSION_3_2:

Réinitialisez le pipeline de traitement de l'appareil photo HAL et configurez de nouveaux flux d'entrée et de sortie. Cet appel remplace toute configuration de flux existante par les flux définis dans la liste stream_list. Cette méthode est appelée au moins une fois après initialize() avant qu'une requête ne soit envoyée avec process_capture_request() .

La liste stream_list doit contenir au moins un flux compatible avec la sortie et ne peut pas contenir plus d'un flux compatible avec l'entrée.

La liste stream_list peut contenir des flux qui figurent également dans l'ensemble de flux actuellement actif (à partir de l'appel précédent à configure_stream()). Ces flux auront déjà des valeurs valides pour l'utilisation, max_buffers et le pointeur privé.

Si le HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, il peut réécrire les valeurs d'utilisation et/ou de max_buffers lors de l'appel de configuration.

Le framework détectera cette modification et pourra ensuite réallouer les tampons de flux avant d'utiliser les tampons de ce flux dans une requête.

Si un flux actuellement actif n'est pas inclus dans stream_list, le HAL peut supprimer en toute sécurité toutes les références à ce flux. Il ne sera pas réutilisé dans un appel configure() ultérieur par le framework, et tous les tampons gralloc associés seront libérés après le retour de l'appel configure_streams() .

La structure stream_list appartient au framework et ne peut pas être accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par le HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus cette camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs de la structure de flux en dehors du pointeur privé, sauf pour les membres "usage" et "max_buffers" lors de l'appel configure_streams() .

Si le flux est nouveau, les champs "max_buffer" et "pointeur privé" de la structure de flux sont tous définis sur 0. L'utilisation sera définie sur les indicateurs d'utilisation par le consommateur. L'appareil HAL doit définir ces champs avant le retour de l'appel configure_streams() . Ces champs sont ensuite utilisés par le framework et le module gralloc de la plate-forme pour allouer les tampons gralloc pour chaque flux.

Le framework peut inclure à tout moment des tampons nouvellement alloués dans une requête de capture. Une fois qu'un tampon gralloc est renvoyé au framework avec process_capture_result (et que son release_fence respectif a été signalé), le framework peut le libérer ou le réutiliser à tout moment.

---

Conditions préalables :

Le framework n'appelle cette méthode que lorsqu'aucune capture n'est en cours de traitement. Autrement dit, tous les résultats ont été renvoyés au framework, et tous les tampons d'entrée et de sortie en cours d'exécution ont été renvoyés, et leurs barrières de synchronisation de libération ont été signalées par le HAL. Le framework n'envoie pas de nouvelles requêtes de capture tant que l'appel configure_streams() est en cours.

Postconditions:

L'appareil HAL doit se configurer pour fournir le débit d'images de sortie maximal possible compte tenu des tailles et des formats des flux de sortie, comme indiqué dans les métadonnées statiques de l'appareil photo.

Exigences liées aux performances:

Cet appel est lourd et peut prendre plusieurs centaines de millisecondes, car il peut nécessiter la réinitialisation et la reconfiguration du capteur d'image et du pipeline de traitement de la caméra. Néanmoins, l'appareil HAL doit essayer de réduire le délai de reconfiguration afin de réduire les pauses visibles par l'utilisateur lors des changements de mode de fonctionnement de l'application (par exemple, passer de la capture d'image à l'enregistrement vidéo).

Le HAL doit renvoyer cet appel en 500 ms et doit le renvoyer en 1 000 ms.

Valeurs renvoyées:

0: en cas de configuration réussie du flux

-EINVAL: si la configuration de flux demandée n'est pas valide. Voici quelques exemples de configurations de flux non valides:

• Inclure plusieurs flux compatibles avec l'entrée (INPUT ou BIDIRECTIONAL)
• sans flux compatibles avec la sortie (OUTPUT ou BIDIRECTIONAL) ;
• y compris les flux dont le format n'est pas accepté ou dont la taille n'est pas compatible avec ce format.
• Inclure trop de flux de sortie d'un certain format
• Configuration de rotation non prise en charge (ne s'applique qu'aux appareils avec version >= CAMERA_DEVICE_API_VERSION_3_3)
• Les tailles/formats de flux ne répondent pas aux exigences de camera3_stream_configuration_t->operation_mode pour le mode autre que NORMAL, ou le mode_d'opération demandé n'est pas compatible avec le HAL. (ne s'applique qu'aux appareils avec la version CAMERA_DEVICE_API_VERSION_3_3 ou ultérieure)

Notez que le framework qui envoie une configuration de flux non valide n'est pas un fonctionnement normal, car les configurations de flux sont vérifiées avant d'être configurées. Une configuration non valide signifie qu'un bug existe dans le code du framework ou qu'il existe une incohérence entre les métadonnées statiques du HAL et les exigences concernant les flux.

-ENODEV: en cas d'erreur fatale et que l'appareil n'est plus opérationnel. Seul close() peut être appelé avec succès par le framework après le retour de cette erreur.

Définition à la ligne  2769 du fichier camera3.h .

construct_default_request_settings:

Créez des paramètres de capture pour les cas d'utilisation standards de l'appareil photo.

L'appareil doit renvoyer un tampon de paramètres configuré pour répondre au cas d'utilisation demandé, qui doit être l'une des énumérations CAMERA3_TEMPLATE_* Tous les champs de contrôle de la requête doivent être inclus.

Le HAL conserve la propriété de cette structure, mais le pointeur vers la structure doit être valide jusqu'à ce que l'appareil soit fermé. Le framework et le HAL ne peuvent pas modifier le tampon une fois qu'il est renvoyé par cet appel. Le même tampon peut être renvoyé pour les appels ultérieurs du même modèle ou d'autres modèles.

Exigences liées aux performances:

Il doit s'agir d'un appel non bloquant. Le HAL doit revenir de cet appel en 1 ms et doit revenir de cet appel en 5 ms.

Valeurs renvoyées:

Métadonnées valides: lors de la création réussie d'un tampon de paramètres par défaut.

NULL: en cas d'erreur fatale. Une fois cette valeur renvoyée, seule la méthode close() peut être appelée avec succès par le framework.

Définition à la ligne  2859 du fichier camera3.h .

dump:

Imprimez l'état de débogage de l'appareil photo. Cette méthode est appelée par le framework lorsqu'un dump de débogage est demandé au service de caméra, ce qui se produit lorsque vous utilisez l'outil dumpsys ou lorsque vous créez un bugreport.

Le descripteur de fichier transmis peut être utilisé pour écrire du texte de débogage à l'aide de dprintf() ou de write(). Le texte doit être encodé en ASCII uniquement.

Exigences liées aux performances:

Il doit s'agir d'un appel non bloquant. Le HAL doit renvoyer cet appel en 1 ms, et doit le faire en 10 ms. Cet appel doit éviter les interblocages, car il peut être appelé à tout moment pendant le fonctionnement de la caméra. Toutes les primitives de synchronisation utilisées (telles que les verrous mutex ou les sémaphores) doivent être acquises avec un délai avant expiration.

Définition à la ligne  2971 du fichier camera3.h .

flush:

Vider toutes les captures en cours de traitement et toutes les mémoires tampons du pipeline sur l'appareil donné. Le framework l'utilisera pour vider tout l'état aussi rapidement que possible afin de se préparer à un appel configure_streams() .

Aucun tampon n'est requis pour être renvoyé avec succès. Par conséquent, chaque tampon détenu au moment de l'appel flush() (qu'il soit rempli ou non) peut être renvoyé avec CAMERA3_BUFFER_STATUS_ERROR. Notez que l'HAL est toujours autorisé à renvoyer des tampons valides (CAMERA3_BUFFER_STATUS_OK) lors de cet appel, à condition qu'ils soient correctement remplis.

Toutes les requêtes actuellement dans la file d'attente HAL devraient être renvoyées dès que possible. Les requêtes non en cours de traitement doivent renvoyer des erreurs immédiatement. Tous les blocs matériels interruptibles doivent être arrêtés, et tous les blocs non interruptibles doivent être mis en attente.

flush() peut être appelé simultanément à process_capture_request() , en supposant que process_capture_request renvoie rapidement et que la requête envoyée dans cet appel process_capture_request est traitée comme toutes les autres requêtes en cours. En raison de problèmes de simultanéité, il est possible que, du point de vue du HAL, un appel process_capture_request() puisse être lancé après l'appel de vidage, mais qu'il ne soit pas encore renvoyé. Si un tel appel se produit avant le retour de flush() , le HAL doit traiter la nouvelle requête de capture comme les autres requêtes en attente en cours (voir point 4 ci-dessous).

Plus précisément, le HAL doit respecter les exigences ci-dessous dans différents cas:

1. Pour les captures trop tardives pour que le HAL puisse les annuler/arrêter, elles seront finalisées normalement par le HAL. Autrement dit, le HAL peut envoyer shutter/notify et process_capture_result et les tampons comme d'habitude.
2. Pour les requêtes en attente qui n'ont pas été traitées, le HAL doit appeler notify CAMERA3_MSG_ERROR_REQUEST et renvoyer tous les tampons de sortie avec process_capture_result dans l'état d'erreur (CAMERA3_BUFFER_STATUS_ERROR). Le HAL ne doit pas placer la barrière de libération dans un état d'erreur. Au lieu de cela, les barrières de libération doivent être définies sur les barrières d'acquisition transmises par le framework, ou sur -1 si elles ont déjà été attendues par le HAL. Il s'agit également du chemin à suivre pour toutes les captures pour lesquelles le HAL a déjà appelé notify() avec CAMERA3_MSG_SHUTTER, mais pour lesquelles il ne produira aucune métadonnées ni aucun tampon valide. Après CAMERA3_MSG_ERROR_REQUEST, pour un frame donné, seuls les process_capture_results avec des tampons dans CAMERA3_BUFFER_STATUS_ERROR sont autorisés. Aucune autre notification ou aucun autre process_capture_result avec des métadonnées non nulles n'est autorisé.

3. Pour les requêtes en attente partiellement terminées qui ne disposent pas de tous les tampons de sortie ou dont les métadonnées sont manquantes, le HAL doit suivre les instructions ci-dessous:

   3.1. Appelez notify avec CAMERA3_MSG_ERROR_RESULT si certaines des métadonnées de résultat attendues (c'est-à-dire une ou plusieurs métadonnées partielles) ne sont pas disponibles pour la capture.

   3.2. Appelez notify avec CAMERA3_MSG_ERROR_BUFFER pour chaque tampon qui ne sera pas produit pour la capture.

   3.3 Appelez notify avec CAMERA3_MSG_SHUTTER avec le code temporel de capture avant que des tampons/métadonnées ne soient renvoyés avec process_capture_result.

   3.4 Pour les captures qui produiront des résultats, le HAL ne doit pas appeler CAMERA3_MSG_ERROR_REQUEST, car cela indique une défaillance complète.

   3.5. Les tampons/métadonnées valides doivent être transmis au framework comme d'habitude.

   3.6. Les tampons ayant échoué doivent être renvoyés au framework, comme décrit pour le cas 2. Toutefois, les tampons ayant échoué ne doivent pas respecter l'ordre strict des tampons valides et peuvent être désordonnés par rapport à eux. Par exemple, si les tampons A, B, C, D et E sont envoyés, que D et E échouent, l'ordre de retour A, E, B, D, C est acceptable.

   3.7. Pour les métadonnées complètement manquantes, l'appel de CAMERA3_MSG_ERROR_RESULT est suffisant. Il n'est pas nécessaire d'appeler process_capture_result avec des métadonnées NULL ou équivalentes.

4. Si une fonction flush() est appelée alors qu'une invocation process_capture_request() est active, cet appel de processus doit renvoyer une valeur dès que possible. De plus, si un appel process_capture_request() est effectué après l'appel flush() , mais avant que flush() ne renvoie une valeur, la requête de capture fournie par l'appel process_capture_request tardif doit être traitée comme une requête en attente dans le cas 2 ci-dessus.

flush() doit uniquement être renvoyé lorsqu'il ne reste plus de tampons ou de requêtes en attente dans le HAL. Le framework peut appeler configure_streams (car l'état HAL est maintenant en mode veille) ou peut émettre de nouvelles requêtes.

Notez qu'il suffit de prendre en charge les cas de résultats entièrement réussis et entièrement échoués. Toutefois, il est vivement recommandé de prendre en charge les cas de défaillance partielle, car cela pourrait améliorer les performances globales de l'appel de vidage.

Exigences liées aux performances:

Le HAL doit revenir de cet appel en 100 ms et doit revenir de cet appel en 1 000 ms. Cet appel ne doit pas être bloqué plus longtemps que la latence du pipeline (voir la section S7 pour en savoir plus).

Informations sur la version:

Disponible uniquement si la version de l'appareil est >= CAMERA_DEVICE_API_VERSION_3_1.

Valeurs renvoyées:

0: lors d'un vidage réussi de l'HAL de l'appareil photo.

-EINVAL: si l'entrée est incorrecte (l'appareil n'est pas valide).

-ENODEV: si l'appareil photo a rencontré une erreur grave. Une fois cette erreur renvoyée, seule la méthode close() peut être appelée avec succès par le framework.

Définition à la ligne  3077 du fichier camera3.h .

get_metadata_vendor_tag_ops:

Obtenez des méthodes pour interroger les informations de la balise de métadonnées de l'extension du fournisseur. Le HAL doit renseigner toutes les méthodes d'opération des tags du fournisseur ou laisser les opérations inchangées si aucun tag de fournisseur n'est défini.

La définition de vendor_tag_query_ops_t se trouve dans system/media/camera/include/system/camera_metadata.h.

>= CAMERA_DEVICE_API_VERSION_3_2: OBSOLÈTE. Cette fonction est obsolète et doit être définie sur NULL par le HAL. Veuillez implémenter get_vendor_tag_ops dans camera_common.h à la place.

Définition à la ligne  2950 du fichier camera3.h .

initialize:

Initialisation unique pour transmettre des pointeurs de fonction de rappel du framework au HAL. Appelé une fois après un appel open() réussi, avant que d'autres fonctions ne soient appelées sur la structure camera3_device_ops .

Exigences liées aux performances:

Il doit s'agir d'un appel non bloquant. Le HAL doit renvoyer cet appel en 5 ms et doit le renvoyer en 10 ms.

Valeurs renvoyées:

0: en cas d'initialisation réussie

-ENODEV: en cas d'échec de l'initialisation. Seul close() peut être appelé avec succès par le framework après cela.

Définition à la ligne 2530 du fichier Camera3.h .

process_capture_request:

Envoyez une nouvelle requête de capture au HAL. Le HAL ne doit pas revenir de cet appel tant qu'il n'est pas prêt à accepter la prochaine requête à traiter. Un seul appel à process_capture_request() est effectué à la fois par le framework, et les appels proviennent tous du même thread. L'appel suivant à process_capture_request() sera effectué dès qu'une nouvelle requête et ses tampons associés seront disponibles. Dans un scénario d'aperçu normal, cela signifie que la fonction sera appelée à nouveau par le framework presque instantanément.

Le traitement de la requête est asynchrone, et les résultats de la capture sont renvoyés par le HAL via l'appel process_capture_result(). Cet appel nécessite que les métadonnées de résultat soient disponibles, mais les tampons de sortie peuvent simplement fournir des barrières de synchronisation à attendre. Plusieurs requêtes doivent être en cours d'exécution simultanément pour maintenir le débit d'images de sortie complet.

Le framework conserve la propriété de la structure de requête. Il n'est valide que pendant cet appel. L'appareil HAL doit créer des copies des informations qu'il doit conserver pour le traitement de la capture. Le HAL est chargé d'attendre et de fermer les barrières des tampons, puis de renvoyer les poignées de tampon au framework.

Le HAL doit écrire le descripteur de fichier pour la barrière de synchronisation de libération du tampon d'entrée dans input_buffer->release_fence, si input_buffer n'est pas NULL. Si le HAL renvoie -1 pour la barrière de synchronisation de libération du tampon d'entrée, le framework est libre de réutiliser immédiatement le tampon d'entrée. Sinon, le framework attendra la barrière de synchronisation avant de remplir et de réutiliser le tampon d'entrée.

>= CAMERA_DEVICE_API_VERSION_3_2:

Les tampons d'entrée/sortie fournis par le framework dans chaque requête peuvent être tout nouveaux (jamais vus auparavant par le HAL).

---

Considérations sur les performances:

La gestion d'un nouveau tampon doit être extrêmement légère, et aucune dégradation de la fréquence d'images ni aucun à-coup ne doit être introduit.

Cet appel doit être renvoyé suffisamment rapidement pour que la fréquence d'images demandée puisse être maintenue, en particulier pour les cas de streaming (paramètres de qualité de post-traitement définis sur "FAST"). Le HAL doit renvoyer cet appel dans un intervalle de 1 frame et doit revenir de cet appel dans un intervalle de 4 frames.

Valeurs renvoyées:

0: au début du traitement de la requête de capture

-EINVAL: si l'entrée est mal formée (les paramètres sont NULL lorsqu'ils ne sont pas autorisés, il n'y a pas de tampons de sortie, etc.) et que le traitement de la capture ne peut pas démarrer. Les échecs lors du traitement des requêtes doivent être gérés en appelant Camera3_callback_ops_t.notify() . En cas d'erreur, le framework conserve la responsabilité des barrières des tampons de flux et des poignées de tampon. Le HAL ne doit pas fermer les barrières ni renvoyer ces tampons avec process_capture_result.

-ENODEV: si l'appareil photo a rencontré une erreur grave. Une fois cette erreur renvoyée, seule la méthode close() peut être appelée avec succès par le framework.

Définition à la ligne  2928 du fichier camera3.h .

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

OBSOLÈTE. Cette valeur ne sera pas appelée et doit être définie sur NULL.

<= CAMERA_DEVICE_API_VERSION_3_1:

Enregistrez des tampons pour un flux donné avec l'appareil HAL. Cette méthode est appelée par le framework après qu'un nouveau flux a été défini par configure_streams et avant que les tampons de ce flux ne soient inclus dans une requête de capture. Si le même flux est listé dans un appel configure_streams() ultérieur, register_stream_buffers ne sera pas appelé à nouveau pour ce flux.

Le framework n'a pas besoin d'enregistrer des tampons pour tous les flux configurés avant d'envoyer la première requête de capture. Cela permet un démarrage rapide pour l'aperçu (ou des cas d'utilisation similaires) pendant que d'autres flux sont encore en cours d'allocation.

Cette méthode permet à l'appareil HAL de mapper ou de préparer les tampons pour une utilisation ultérieure. Les tampons transmis sont déjà verrouillés pour être utilisés. À la fin de l'appel, tous les tampons doivent être prêts à être renvoyés au flux. L'argument buffer_set n'est valide que pendant la durée de cet appel.

Si le format de flux a été défini sur HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, le HAL de l'appareil photo doit inspecter les tampons transmis ici pour déterminer toute information sur le format de pixel privé de la plate-forme.

Exigences liées aux performances:

Il doit s'agir d'un appel non bloquant. Le HAL doit revenir de cet appel en 1 ms et doit revenir de cet appel en 5 ms.

Valeurs renvoyées:

0: en cas d'enregistrement réussi des nouveaux tampons de flux

-EINVAL: si stream_buffer_set ne fait pas référence à un flux actif valide ou si le tableau de tampons n'est pas valide.

-ENOMEM: si l'enregistrement des tampons a échoué. Le framework doit considérer que tous les tampons de flux sont non enregistrés et peut essayer de les enregistrer à nouveau plus tard.

-ENODEV: en cas d'erreur fatale et si l'appareil n'est plus opérationnel. Seul close() peut être appelé avec succès par le framework après le retour de cette erreur.

Définition à la ligne  2823 du fichier camera3.h .

Définition à la ligne  3080 du fichier camera3.h .