Référence de structure camera3_device_ops
#include < camera3.h >
Champs de données | |
| entier(* | initialiser )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
| entier(* | configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
| entier(* | register_stream_buffers )(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
| const camera_metadata_t *(* | construct_default_request_settings )(const struct camera3_device *, type int) |
| entier(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| vide(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, supplier_tag_query_ops_t *ops) |
| vide(* | dump )(const struct camera3_device *, int fd) |
| entier(* | flush )(const struct camera3_device *) |
| vide * | réservé [8] |
Description détaillée
Documentation de terrain
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams :
CAMERA_DEVICE_API_VERSION_3_0 uniquement :
Réinitialisez le pipeline de traitement du périphérique de caméra 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 sera appelée au moins une fois après initialize() avant qu'une requête ne soit soumise 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 stream_list peut contenir des flux qui font également partie de l'ensemble de flux actuellement actif (depuis 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 un tel flux a déjà ses tampons enregistrés, register_stream_buffers() ne sera plus appelé pour le flux et les tampons du flux peuvent être immédiatement inclus dans les requêtes d'entrée.
Si la HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, elle peut réécrire les valeurs d'utilisation et/ou max_buffers lors de l'appel de configuration.
Le framework détectera un tel changement, puis réaffectera 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, la HAL peut supprimer en toute sécurité toute référence à ce flux. Il ne sera pas réutilisé lors d'un appel configure() ultérieur par le framework, et tous les tampons gralloc correspondants seront libérés après le retour de l'appel configure_streams() .
La structure stream_list appartient au framework et n'est plus accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus ce camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs dans la structure du flux en dehors du pointeur privé, à l'exception des membres usage et max_buffers pendant l'appel configure_streams() lui-même.
Si le flux est nouveau, les champs d'utilisation, max_buffer et de pointeur privé de la structure du flux seront tous définis sur 0. Le périphérique 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 plateforme pour allouer les tampons gralloc pour chaque flux.
Avant qu'un tel nouveau flux puisse avoir ses tampons inclus dans une demande de capture, le framework appellera register_stream_buffers() avec ce flux. Cependant, le framework n'est pas obligé d'enregistrer des tampons pour tous les flux avant de soumettre une demande. Cela permet le démarrage rapide (par exemple) d'un flux de prévisualisation, l'allocation d'autres flux ayant lieu plus tard ou simultanément.
CAMERA_DEVICE_API_VERSION_3_1 uniquement :
Réinitialisez le pipeline de traitement du périphérique de caméra 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 sera appelée au moins une fois après initialize() avant qu'une requête ne soit soumise 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 stream_list peut contenir des flux qui font également partie de l'ensemble de flux actuellement actif (depuis 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 un tel flux a déjà ses tampons enregistrés, register_stream_buffers() ne sera plus appelé pour le flux et les tampons du flux peuvent être immédiatement inclus dans les requêtes d'entrée.
Si la HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, elle peut réécrire les valeurs d'utilisation et/ou max_buffers lors de l'appel de configuration.
Le framework détectera un tel changement, puis réaffectera 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, la HAL peut supprimer en toute sécurité toute référence à ce flux. Il ne sera pas réutilisé lors d'un appel configure() ultérieur par le framework, et tous les tampons gralloc correspondants seront libérés après le retour de l'appel configure_streams() .
La structure stream_list appartient au framework et n'est plus accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus ce camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs dans la structure du flux en dehors du pointeur privé, à l'exception des membres usage et max_buffers pendant l'appel configure_streams() lui-même.
Si le flux est nouveau, max_buffer et les champs de pointeur privé de la structure du flux seront tous définis sur 0. L'utilisation sera définie sur les indicateurs d'utilisation du consommateur. Le périphérique 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 plateforme pour allouer les tampons gralloc pour chaque flux.
Avant qu'un tel nouveau flux puisse avoir ses tampons inclus dans une demande de capture, le framework appellera register_stream_buffers() avec ce flux. Cependant, le framework n'est pas obligé d'enregistrer des tampons pour tous les flux avant de soumettre une demande. Cela permet le démarrage rapide (par exemple) d'un flux de prévisualisation, l'allocation d'autres flux ayant lieu plus tard ou simultanément.
>= CAMERA_DEVICE_API_VERSION_3_2 :
Réinitialisez le pipeline de traitement du périphérique de caméra 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 sera appelée au moins une fois après initialize() avant qu'une requête ne soit soumise 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 stream_list peut contenir des flux qui font également partie de l'ensemble de flux actuellement actif (depuis 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 la HAL doit modifier la configuration du flux pour un flux existant en raison de la nouvelle configuration, elle peut réécrire les valeurs d'utilisation et/ou max_buffers lors de l'appel de configuration.
Le framework détectera un tel changement 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, la HAL peut supprimer en toute sécurité toute référence à ce flux. Il ne sera pas réutilisé lors d'un appel configure() ultérieur par le framework, et tous les tampons gralloc correspondants seront libérés après le retour de l'appel configure_streams() .
La structure stream_list appartient au framework et n'est plus accessible une fois cet appel terminé. L'adresse d'une structure camera3_stream_t individuelle restera valide pour l'accès par HAL jusqu'à la fin du premier appel configure_stream() qui n'inclut plus ce camera3_stream_t dans l'argument stream_list. Le HAL ne peut pas modifier les valeurs dans la structure du flux en dehors du pointeur privé, à l'exception des membres usage et max_buffers pendant l'appel configure_streams() lui-même.
Si le flux est nouveau, max_buffer et les champs de pointeur privé de la structure du flux seront tous définis sur 0. L'utilisation sera définie sur les indicateurs d'utilisation du consommateur. Le périphérique 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 plateforme pour allouer les tampons gralloc pour chaque flux.
Les tampons nouvellement alloués peuvent être inclus dans une demande de capture à tout moment par le framework. 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'appellera 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 ont été renvoyés et leurs clôtures de synchronisation de libération ont été signalées par le HAL. Le framework ne soumettra pas de nouvelles demandes de capture pendant que l'appel configure_streams() est en cours.
Postconditions :
Le périphérique HAL doit se configurer pour fournir une fréquence d'images de sortie maximale possible compte tenu des tailles et des formats des flux de sortie, comme indiqué dans les métadonnées statiques de la caméra.
Exigences de performances :
Cet appel devrait être lourd et prendre éventuellement plusieurs centaines de millisecondes, car il peut nécessiter une réinitialisation et une reconfiguration du capteur d'image et du pipeline de traitement de la caméra. Néanmoins, le périphérique HAL doit tenter de minimiser le délai de reconfiguration afin de minimiser les pauses visibles par l'utilisateur lors des changements de mode de fonctionnement de l'application (comme le passage de la capture d'image fixe à l'enregistrement vidéo).
Le HAL devrait revenir de cet appel dans 500 ms et doit revenir de cet appel dans 1 000 ms.
Valeurs de retour :
0 : sur une configuration de flux réussie
-EINVAL : Si la configuration du flux demandée n'est pas valide. Voici quelques exemples de configurations de flux non valides :
- Y compris plus d'un flux compatible avec l'entrée (INPUT ou BIDIRECTIONAL)
- N'inclut aucun flux compatible avec la sortie (OUTPUT ou BIDIRECTIONAL)
- Y compris les flux avec des formats non pris en charge ou une taille non prise en charge pour ce format.
- Y compris trop de flux de sortie d'un certain format.
- Configuration de rotation non prise en charge (s'applique uniquement aux appareils avec la version >= CAMERA_DEVICE_API_VERSION_3_3)
- Les tailles/formats de flux ne satisfont pas aux exigences de camera3_stream_configuration_t->operation_mode pour le mode non NORMAL, ou le mode d'opération demandé n'est pas pris en charge par HAL. (s'applique uniquement aux appareils avec la version >= CAMERA_DEVICE_API_VERSION_3_3)
Notez que le framework soumettant une configuration de flux invalide ne constitue pas un fonctionnement normal, puisque les configurations de flux sont vérifiées avant la configuration. Une configuration non valide signifie qu'un bug existe dans le code du framework ou qu'il existe une incompatibilité entre les métadonnées statiques de HAL et les exigences relatives aux flux.
-ENODEV : S'il y a eu une 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.
| const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, type int) |
construct_default_request_settings :
Créez des paramètres de capture pour les cas d’utilisation standard de la caméra.
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 des demandes doivent être inclus.
Le HAL conserve la propriété de cette structure, mais le pointeur vers la structure doit être valide jusqu'à la fermeture de l'appareil. 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 des appels ultérieurs pour le même modèle ou pour d'autres modèles.
Exigences de performances :
Cela devrait être un appel non bloquant. Le HAL devrait revenir de cet appel dans 1 ms et doit revenir de cet appel dans 5 ms.
Valeurs de retour :
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 ceci renvoyé, seule la méthode close() peut être appelée avec succès par le framework.
| void(* dump)(const struct camera3_device *, int fd) |
décharge:
Imprimez l’état de débogage du périphérique caméra. Ceci sera appelé par le framework lorsque le service de caméra sera invité à effectuer un dump de débogage, ce qui se produit lors de l'utilisation de l'outil dumpsys ou lors de la capture d'un rapport de bug.
Le descripteur de fichier transmis peut être utilisé pour écrire du texte de débogage à l'aide de dprintf() ou write(). Le texte doit être uniquement en codage ASCII.
Exigences de performances :
Il doit s'agir d'un appel non bloquant. Le HAL devrait revenir de cet appel dans 1 ms, doit revenir de cet appel dans 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 d'attente.
| int(*flush)(const struct camera3_device *) |
affleurer:
Videz toutes les captures actuellement en cours et tous les tampons dans le pipeline sur l'appareil donné. Le framework l'utilisera pour vider tous les états le plus rapidement possible afin de préparer un appel configure_streams() .
Aucun tampon n'est requis pour être renvoyé avec succès, donc chaque tampon détenu au moment de flush() (qu'il soit rempli avec succès ou non) peut être renvoyé avec CAMERA3_BUFFER_STATUS_ERROR. Notez que HAL est toujours autorisé à renvoyer des tampons valides (CAMERA3_BUFFER_STATUS_OK) pendant cet appel, à condition qu'ils soient remplis avec succès.
Toutes les demandes actuellement dans le HAL devraient être renvoyées dès que possible. Les requêtes non en cours doivent renvoyer des erreurs immédiatement. Tous les blocs matériels interruptibles doivent être arrêtés et tous les blocs ininterruptibles doivent être attendus.
flush() peut être appelé simultanément à process_capture_request() , dans l'espoir que process_capture_request reviendra rapidement et que la requête soumise dans cet appel process_capture_request soit traitée comme toutes les autres requêtes en cours. En raison de problèmes de concurrence, il est possible que du point de vue de HAL, un appel process_capture_request() soit lancé après que flush ait été invoqué mais n'ait pas encore été renvoyé. Si un tel appel se produit avant le retour de flush() , le HAL doit traiter la nouvelle demande de capture comme les autres demandes en attente en cours (voir #4 ci-dessous).
Plus précisément, le HAL doit suivre les exigences ci-dessous pour divers cas :
- Pour les captures qui arrivent trop tard pour que le HAL puisse s'annuler/s'arrêter et qui seront terminées normalement par le HAL ; c'est-à-dire que le HAL peut envoyer Shutter/Notify, Process_capture_result et des tampons comme d'habitude.
- Pour les demandes en attente qui n'ont effectué aucun traitement, 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). La HAL ne doit pas placer la clôture de libération dans un état d'erreur, mais les clôtures de libération doivent être définies sur les clôtures d'acquisition transmises par le framework, ou sur -1 si elles ont déjà été attendues par la HAL. C'est également le chemin à suivre pour toutes les captures pour lesquelles le HAL a déjà appelé notify() avec CAMERA3_MSG_SHUTTER mais ne produira aucune métadonnée/tampon valide. Après CAMERA3_MSG_ERROR_REQUEST, pour une image donnée, seuls process_capture_results avec des tampons dans CAMERA3_BUFFER_STATUS_ERROR sont autorisés. Aucune autre notification ou process_capture_result avec des métadonnées non nulles n'est autorisée.
Pour les demandes en attente partiellement complétées qui n'auront pas tous les tampons de sortie ou peut-être des métadonnées manquantes, le HAL doit suivre ci-dessous :
3.1. Appelez notify avec CAMERA3_MSG_ERROR_RESULT si certaines des métadonnées du résultat attendues (c'est-à-dire une ou plusieurs métadonnées partielles) ne seront 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 la notification avec CAMERA3_MSG_SHUTTER avec l'horodatage de capture avant que les 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 un échec complet.
3.5. Les tampons/métadonnées valides doivent être transmis au framework normalement.
3.6. Les tampons en échec doivent être renvoyés au framework comme décrit pour le cas 2. Mais les tampons en échec ne doivent pas nécessairement suivre l'ordre strict des tampons valides et peuvent être dans le désordre par rapport aux tampons valides. Par exemple, si les tampons A, B, C, D, E sont envoyés, et que D et E échouent, alors A, E, B, D, C est un ordre de retour acceptable.
3.7. Pour les métadonnées totalement manquantes, l'appel de CAMERA3_MSG_ERROR_RESULT est suffisant, pas besoin d'appeler process_capture_result avec des métadonnées NULL ou équivalent.
- Si un flush() est invoqué alors qu'une invocation process_capture_request() est active, cet appel de processus doit revenir dès que possible. De plus, si un appel process_capture_request() est effectué après l'appel de flush() mais avant le retour de flush() , la requête de capture fournie par l'appel tardif de process_capture_request doit être traitée comme une requête en attente dans le cas n°2 ci-dessus.
flush() ne devrait revenir que lorsqu'il n'y a plus de tampons ou de requêtes en attente dans le HAL. Le framework peut appeler configure_streams (car l'état HAL est maintenant mis au repos) ou peut émettre de nouvelles requêtes.
Notez qu'il suffit de prendre en charge uniquement les cas de résultats pleinement réussis et totalement échoués. Cependant, il est hautement souhaitable de prendre également en charge les cas d'échec partiel, car cela pourrait contribuer à améliorer les performances globales des appels de vidage.
Exigences de performances :
Le HAL devrait revenir de cet appel dans 100 ms et doit revenir de cet appel dans 1 000 ms. Et cet appel ne doit pas être bloqué plus longtemps que la latence du pipeline (voir S7 pour la définition).
Information sur la version:
disponible uniquement si la version de l'appareil >= CAMERA_DEVICE_API_VERSION_3_1.
Valeurs de retour :
0 : Lors d'un rinçage réussi de la caméra HAL.
-EINVAL : Si l'entrée est mal formée (le périphérique 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.
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, supplier_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops :
Obtenez des méthodes pour interroger les informations sur les balises de métadonnées d’extension du fournisseur. Le HAL doit renseigner toutes les méthodes de fonctionnement des balises du fournisseur, ou laisser les opérations inchangées si aucune balise du fournisseur n'est définie.
La définition de supplier_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 HAL. Veuillez plutôt implémenter get_vendor_tag_ops dans camera_common.h .
| int(* initialiser)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
initialiser:
Initialisation unique pour transmettre les pointeurs de fonction de rappel du framework au HAL. Sera 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 de performances :
Cela devrait être un appel non bloquant. Le HAL devrait revenir de cet appel dans 5 ms et doit revenir de cet appel dans 10 ms.
Valeurs de retour :
0 : en cas d'initialisation réussie
-ENODEV : Si l'initialisation échoue. Seul close() peut être appelé avec succès par le framework après cela.
| int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request) |
processus_capture_request :
Envoyez une nouvelle demande de capture au HAL. La HAL ne devrait pas revenir de cet appel tant qu'elle n'est pas prête à accepter la prochaine demande à traiter. Un seul appel à process_capture_request() sera effectué à la fois par le framework, et les appels proviendront tous du même thread. Le prochain appel à process_capture_request() sera effectué dès qu'une nouvelle requête et ses tampons associés seront disponibles. Dans un scénario de prévisualisation normal, cela signifie que la fonction sera à nouveau appelée par le framework presque instantanément.
Le traitement réel de la demande est asynchrone, les résultats de la capture étant renvoyés par HAL via l'appel process_capture_result(). Cet appel nécessite que les métadonnées du résultat soient disponibles, mais les tampons de sortie peuvent simplement fournir des clôtures de synchronisation sur lesquelles attendre. Plusieurs requêtes devraient être en cours en même temps, afin de maintenir une fréquence d'images de sortie maximale.
Le framework conserve la propriété de la structure de la demande. Sa validité n'est garantie que pendant cet appel. Le périphérique HAL doit faire des copies des informations qu'il doit conserver pour le traitement de capture. Le HAL est chargé d'attendre et de fermer les clôtures des tampons et de renvoyer les handles du tampon au framework.
Le HAL doit écrire le descripteur de fichier pour la clôture 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 clôture 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 sur la clôture 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 flambant neufs (n'ayant jamais été vus auparavant par le HAL).
Considérations relatives aux performances :
La gestion d'un nouveau tampon doit être extrêmement légère et il ne doit y avoir aucune dégradation de la fréquence d'images ni aucune gigue d'image.
Cet appel doit revenir suffisamment rapidement pour garantir 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 RAPIDE). La HAL doit renvoyer cet appel dans un intervalle de 1 trame et doit revenir de cet appel dans un intervalle de 4 trames.
Valeurs de retour :
0 : en cas de démarrage réussi du traitement de la demande de capture
-EINVAL : Si l'entrée est mal formée (les paramètres sont NULL lorsqu'ils ne sont pas autorisés, il y a 0 tampons de sortie, etc.) et le traitement de capture ne peut pas démarrer. Les échecs lors du traitement de la demande doivent être gérés en appelant camera3_callback_ops_t.notify() . En cas de cette erreur, le framework conservera la responsabilité des clôtures des tampons de flux et des descripteurs de tampon ; le HAL ne doit pas fermer les clôtures ou 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.
| int(* register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
registre_stream_buffers :
>= CAMERA_DEVICE_API_VERSION_3_2 :
DÉCONSEILLÉ. Celui-ci ne sera pas appelé et doit être défini sur NULL.
<= CAMERA_DEVICE_API_VERSION_3_1 :
Enregistrez les tampons pour un flux donné avec le périphérique HAL. Cette méthode est appelée par le framework après qu'un nouveau flux soit défini par configure_streams et avant que les tampons de ce flux ne soient inclus dans une demande de capture. Si le même flux est répertorié dans un appel configure_streams() ultérieur, register_stream_buffers ne sera plus appelé pour ce flux.
Le framework n'a pas besoin d'enregistrer des tampons pour tous les flux configurés avant de soumettre la première demande de capture. Cela permet un démarrage rapide pour un aperçu (ou des cas d'utilisation similaires) pendant que d'autres flux sont encore en cours d'allocation.
Cette méthode est destinée à permettre au périphérique HAL de mapper ou de préparer d'une autre manière les tampons pour une utilisation ultérieure. Les tampons transmis seront déjà verrouillés pour utilisation. A la fin de l'appel, tous les buffers doivent être prêts à être renvoyés dans le flux. L'argument buffer_set n'est valide que pendant la durée de cet appel.
Si le format du flux était défini sur HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, la caméra HAL doit inspecter les tampons transmis ici pour déterminer toute information de format de pixel privée à la plate-forme.
Exigences de performances :
Cela devrait être un appel non bloquant. Le HAL devrait revenir de cet appel dans 1 ms et doit revenir de cet appel dans 5 ms.
Valeurs de retour :
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 buffers n'est pas valide.
-ENOMEM : s'il y a eu un échec dans l'enregistrement des tampons. Le framework doit considérer que tous les tampons de flux ne sont pas enregistrés et peut tenter de s'enregistrer à nouveau ultérieurement.
-ENODEV : S'il y a une 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.
La documentation de cette structure a été générée à partir du fichier suivant :
- matériel/libhardware/include/hardware/ camera3.h