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

En raison des avantages offerts par AIDL, les fournisseurs sont encouragés à implémenter le HAL du compilateur 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 du compilateur AIDL, nommé android.hardware.graphics.composer3, est défini dans IComposer.aidl. Il expose une API semblable à l'API HAL HIDL android.hardware.graphics.composer@2.4 avec les modifications suivantes:

  • Suppression de la file d'attente de messages rapide (FMQ) au profit des commandes parcelables.

    Le HAL AIDL définit l'interface de commande en fonction de types parcellables fortement typés, contrairement aux commandes sérialisées via 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 parcelable fortement typé défini dans DisplayCommand.aidl. Les réponses de commande sont des éléments parcelables fortement typés définis dans CommandResultPayload.aidl.

  • Suppression de IComposerClient.getClientTargetSupport, car aucun client n'utilise ce mode.

  • Représentation des couleurs sous forme de nombres à virgule flottante au lieu 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 le HAL AIDL, les piles de couches SDR/HDR mixtes permettent d'atténuer de manière fluide les couches SDR lorsqu'une couche 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 atténue le contenu de la couche dans l'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 client et d'indiquer à RenderEngine s'il faut assombrir les calques SDR dans la composition client.

    Le champ dimmingStage permet au HWC de configurer quand RenderEngine doit atténuer le contenu. Cela permet d'accepter les 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 de matériel dédié pour optimiser le dessin du masque alpha qui lisse les coins 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 la couche de masque alpha comme DISPLAY_DECORATION, un nouveau type de composition qui exploite le 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 s'afficher à l'écran. Avec cette fonctionnalité, SurfaceFlinger envoie une commande de présentation à l'implémentation à l'avance, ce qui lui permet de pipeliner davantage le travail de composition.

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

    À l'aide de BOOT_DISPLAY_CONFIG, les fournisseurs peuvent spécifier que la configuration d'affichage 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 au démarrage. Les fournisseurs doivent mettre en cache la configuration d'affichage de démarrage et démarrer dans cette configuration lors du prochain redémarrage. Si l'appareil ne parvient pas à démarrer dans 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 d'effacer la configuration d'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 d'affichage de démarrage n'est pas prise en charge, ces méthodes renvoient la valeur UNSUPPORTED.

  • Ajout de nouvelles API pour contrôler le délai 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. Lorsque l'appareil est inactif, cette fonctionnalité définit la fréquence d'actualisation sur un paramètre inférieur 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 un résynchronisation vsync sur le frame suivant et apprend la nouvelle cadence vsync.

Implémentation

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

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

Tests

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