AIDL pour le HAL Hardware Composer

À partir d'Android 13, le HAL Hardware Composer (HWC) est défini dans AIDL. 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, et explique comment implémenter et tester le HAL AIDL.

Étant donné qu'AIDL offre des avantages, les fournisseurs peuvent implémenter le HAL du 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. L'API est semblable à la HAL HIDL android.hardware.graphics.composer@2.4, mais inclut les modifications suivantes :

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

    Le HAL AIDL définit l'interface de commande basée sur des types de données Parcelable fortement typés au lieu des 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 le système interprète la charge utile de la commande.

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

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

    Chaque commande est un type Parcelable fortement typé défini dans DisplayCommand.aidl. Les réponses aux commandes sont des objets 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 au lieu d'octets pour s'aligner sur la pile graphique supérieure d'Android, telle que définie par 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'atténuer facilement les calques SDR lorsqu'un calque HDR est affiché à l'écran en même temps.

    Le champ brightness de LayerCommand permet à SurfaceFlinger de spécifier une luminosité par calque. Cela permet au HWC d'assombrir le contenu du calque dans l'espace de luminosité linéaire au lieu de l'espace gamma.

    Le champ brightness de ClientTargetPropertyWithBrightness permet au HWC de spécifier l'espace de luminosité pour la composition du client et indique à 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 atténue le contenu. Cela permet d'adapter les ColorModes définis par le fournisseur qui préfèrent peut-être atténuer la luminosité dans l'espace gamma pour activer les améliorations de contraste définies par le fournisseur dans leurs pipelines de couleurs.

  • Ajout d'un 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 et renvoyer une structure DisplayDecorationSupport telle que définie dans DisplayDecorationSupport.aidl. Cette structure décrit les énumérations PixelFormat et AlphaInterpretation requises par l'appareil. Après cette implémentation, l'UI système marque le calque de masque alpha comme DISPLAY_DECORATION, un 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 attendue pour l'affichage du contenu actuel à 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 :

    • À l'aide de setBootDisplayConfig, le framework informe les fournisseurs de la configuration d'affichage du temps de 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 qui correspond à 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 leur configuration d'écran 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'é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 écran. 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 avant 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 le HAL AIDL pour Android 13. Toutefois, les fournisseurs sont encouragés à implémenter le HAL de compositeur AIDL au lieu de la version HIDL pour utiliser les fonctionnalités et les API du HAL de compositeur AIDL.

Les émulateurs Android incluent une implémentation de référence pour le HAL HWC AIDL.

Tests

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