AIDL pour Hardware Composer HAL

À partir d’Android 13, le HAL Hardware Composer (HWC) est défini dans AIDL et les versions HIDL allant de android.hardware.graphics.composer@2.1 à android.hardware.graphics.composer@2.4 sont obsolètes.

Cette page décrit les différences entre l'AIDL et le HIDL HAL pour le HWC ainsi que la mise en œuvre et les tests de l'AIDL HAL.

En raison des avantages offerts par AIDL, les fournisseurs sont encouragés à implémenter le compositeur AIDL HAL à partir d'Android 13 au lieu de la version HIDL. Voir la section Mise en œuvre pour plus d'informations.

Différences entre les HAL AIDL et HIDL

Le nouveau compositeur AIDL HAL, nommé android.hardware.graphics.composer3 , est défini dans IComposer.aidl . Il expose une API similaire au HIDL HAL android.hardware.graphics.composer@2.4 avec les modifications suivantes :

  • Suppression de la Fast Message Queue (FMQ) au profit de commandes parcellaires.

    L'AIDL HAL définit l'interface de commande basée sur des types parcellaires fortement typés par opposition aux commandes sérialisées sur FMQ dans HIDL. Cela fournit une interface stable pour les commandes et une définition plus lisible de la façon dont la charge utile de la commande est interprétée.

    La méthode executeCommands est définie dans IComposerClient.aidl comme

    CommandResultPayload[] executeCommands(in DisplayCommand[] commands);
    

    où chaque commande est un type parcellaire fortement typé défini dans DisplayCommand.aidl . Les réponses aux commandes sont des parcelles fortement typées définies dans CommandResultPayload.aidl .

  • Suppression de IComposerClient.getClientTargetSupport car il n’y a aucun client actif pour cette méthode.

  • Représentation des couleurs sous forme de flottants au lieu d'octets pour mieux s'aligner sur la pile graphique supérieure dans Android telle que définie dans ASurfaceTransaction_setColor .

  • Ajout de nouveaux champs pour contrôler le contenu HDR.

    Dans AIDL HAL, les piles de couches mixtes SDR/HDR prennent en charge l'atténuation transparente des couches SDR lorsqu'une couche HDR est simultanément à l'écran.

    Le champ brightness dans LayerCommand permet à SurfaceFlinger de spécifier une luminosité par couche, de sorte que HWC atténue le contenu de la couche dans un espace lumineux linéaire, par opposition à l'espace gamma.

    Le champ brightness dans ClientTargetPropertyWithBrightness permet au HWC de spécifier l'espace de luminosité pour la composition du client et d'indiquer à RenderEngine s'il doit atténuer les couches SDR dans la composition du client.

    Le champ dimmingStage permet au HWC de configurer le moment où RenderEngine doit atténuer le contenu. Cela prend en charge ColorModes définis par le fournisseur, qui peuvent préférer atténuer l'espace gamma, pour permettre des améliorations de contraste définies par le fournisseur dans leurs pipelines de couleurs.

  • Ajout d'un nouveau type de composition DISPLAY_DECORATION dans Composition.aidl pour les décorations d'écran.

    Certains appareils disposent d'un matériel dédié pour optimiser le dessin du masque alpha qui lisse les coins arrondis et les découpes sur les écrans. Les appareils dotés d'un tel matériel doivent implémenter IComposerClient.getDisplayDecorationSupport pour renvoyer une structure DisplayDecorationSupport telle que définie dans le nouveau DisplayDecorationSupport.aidl . Cette structure décrit les énumérations PixelFormat et AlphaInterpretation requises par l'appareil. Lors de cette implémentation, System UI marque la couche de masque alpha comme DISPLAY_DECORATION , un nouveau type de composition qui tire parti du matériel dédié.

  • Ajout d'un nouveau champ expectedPresentTime à DisplayCommand.aidl .

    Le champ expectedPresentTime permet à SurfaceFlinger de définir l'heure actuelle attendue à laquelle le contenu actuel doit être affiché à l'écran. Avec cette fonctionnalité, SurfaceFlinger envoie une commande actuelle à l'implémentation à l'avance, lui permettant de canaliser une plus grande partie du travail de composition.

  • Ajout de nouvelles API pour contrôler la configuration de l'affichage de démarrage.

    À l'aide BOOT_DISPLAY_CONFIG , les fournisseurs peuvent spécifier que la configuration de l'affichage de démarrage est prise en charge. Les méthodes setBootDisplayConfig , clearBootDisplayConfig et getPreferredBootDisplayConfig utilisent BOOT_DISPLAY_CONFIG comme suit :

    • À l'aide setBootDisplayConfig , le framework informe les fournisseurs de la configuration de l'affichage de l'heure de démarrage. Les fournisseurs doivent mettre en cache la configuration de l'affichage de démarrage et démarrer dans cette configuration au prochain redémarrage. Si le périphérique ne parvient pas à démarrer dans cette configuration, le fournisseur doit trouver une configuration correspondant à la résolution et au taux de rafraîchissement de cette configuration. Si aucune configuration de ce type n’existe, le fournisseur doit utiliser sa configuration d’affichage préférée.

    • À l'aide de clearBootDisplayConfig , le framework informe les fournisseurs d'effacer la configuration de l'affichage de démarrage et de démarrer dans leur configuration d'affichage préférée lors du prochain redémarrage.

    • À l'aide de getPreferredBootDisplayConfig , le framework interroge le mode de démarrage préféré du fournisseur.

    Lorsque la configuration de l'affichage de démarrage n'est pas prise en charge, ces méthodes renvoient la valeur UNSUPPORTED .

  • Ajout de nouvelles API pour contrôler la minuterie d'inactivité de l'affichage.

    • À l'aide DISPLAY_IDLE_TIMER , les fournisseurs peuvent spécifier qu'un minuteur d'inactivité est implémenté par le fournisseur pour cet affichage. En cas d'inactivité, cette fonctionnalité modifie le taux de rafraîchissement à un paramètre inférieur pour préserver l'énergie. La plate-forme utilise setIdleTimerEnabled pour contrôler le délai d'expiration du minuteur et, dans certains cas, pour le désactiver afin d'éviter des changements indésirables de taux de rafraîchissement en cas d'inactivité.

    • L'utilisation du rappel IComposerCallback.onVsyncIdle indique à la plate-forme que l'affichage est inactif et que la cadence vsync a changé. La plateforme répond à ce rappel en réinitialisant son modèle vsync . Il force une resynchronisation vsync sur l'image suivante et apprend la nouvelle cadence vsync .

Mise en œuvre

Les fournisseurs ne sont pas tenus d’implémenter AIDL HAL pour Android 13. Cependant, ils sont encouragés à implémenter AIDL composer HAL au lieu de la version HIDL pour utiliser les nouvelles fonctionnalités et API.

Une implémentation de référence pour AIDL HWC HAL est implémentée dans les émulateurs Android.

Essai

Pour tester votre implémentation, exécutez VtsHalGraphicsComposer3_TargetTest .