AIDL pour le HAL Hardware Composer

À 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 les HAL AIDL et HIDL pour le HWC, ainsi que l'implémentation et le test du HAL AIDL.

En raison des avantages offerts par AIDL, les fournisseurs sont encouragés à implémenter le HAL de compositeur AIDL à partir d'Android 13 au lieu de la version HIDL. Pour en savoir plus, consultez la section Implémentation.

Différences entre les HAL AIDL et HIDL

Le nouveau HAL de compositeur AIDL, nommé android.hardware.graphics.composer3, est défini dans IComposer.aidl. Elle expose une API semblable à la HAL HIDL android.hardware.graphics.composer@2.4 avec les modifications suivantes :

  • Suppression de la file d'attente de messages rapides (FMQ) au profit des commandes pouvant être sérialisées.

    Le HAL AIDL définit l'interface de commande basée sur des types de données Parcelable fortement typés, contrairement 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 suit :

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

    où chaque commande est un type Parcelable fortement typé défini dans DisplayCommand.aidl. Les réponses aux commandes sont des éléments Parcelable fortement typés définis dans CommandResultPayload.aidl.

  • Suppression de IComposerClient.getClientTargetSupport, car aucun client actif n'utilise cette méthode.

  • Représentation des couleurs sous forme de valeurs flottantes plutôt que d'octets pour mieux s'aligner sur la pile graphique supérieure d'Android, comme défini dans ASurfaceTransaction_setColor.

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

    Dans l'AIDL HAL, les piles de calques SDR/HDR mixtes permettent d'assombrir facilement les calques SDR lorsqu'un calque HDR est simultanément à l'écran.

    Le champ brightness dans LayerCommand permet à SurfaceFlinger de spécifier une luminosité par calque, de sorte que le HWC diminue la luminosité du contenu du calque dans l'espace de luminosité 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 faut atténuer les calques SDR dans la composition du client.

    Le champ dimmingStage permet au HWC de configurer le moment où RenderEngine doit atténuer le contenu. Cela permet de prendre en compte les ColorModes définis par le fournisseur, qui peuvent préférer une atténuation dans l'espace gamma, afin d'autoriser les 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 adoucit les angles arrondis et les encoches sur les écrans. Les appareils dotés de ce 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, l'UI système marque le calque de masque alpha comme DISPLAY_DECORATION, un nouveau type de composition qui tire parti du matériel dédié.

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

    Le champ expectedPresentTime permet à SurfaceFlinger de définir l'heure de présentation prévue à laquelle le contenu actuel doit être affiché à l'écran. Avec cette fonctionnalité, SurfaceFlinger envoie une commande de présentation à l'implémentation à l'avance, ce qui lui permet de mettre en pipeline une plus grande partie du travail de composition.

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

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

    • En utilisant setBootDisplayConfig, le framework informe les fournisseurs de la configuration d'affichage au moment du démarrage. Les fournisseurs doivent mettre en cache la configuration de l'écran de démarrage et démarrer dans cette configuration au prochain redémarrage. Si l'appareil ne parvient pas à démarrer avec cette configuration, le fournisseur doit trouver une configuration correspondant à la résolution et à la fréquence d'actualisation de cette configuration. Si aucune configuration de ce type n'existe, le fournisseur doit utiliser la configuration d'affichage de son choix.

    • À l'aide de clearBootDisplayConfig, le framework informe les fournisseurs qu'ils doivent effacer la configuration de l'écran de démarrage et démarrer avec la configuration d'écran de leur choix 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'écran de démarrage n'est pas prise en charge, ces méthodes renvoient une valeur de UNSUPPORTED.

  • Ajout de nouvelles API pour contrôler le minuteur d'inactivité de l'écran.

    • À l'aide de DISPLAY_IDLE_TIMER, les fournisseurs peuvent spécifier qu'un minuteur d'inactivité est implémenté par le fournisseur pour cet affichage. Lorsqu'il est inactif, cette fonctionnalité réduit la fréquence d'actualisation pour économiser de 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 les changements de fréquence d'actualisation indésirables en cas d'inactivité.

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

Implémentation

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

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

Tests

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