AIDL pour Hardware Composer HAL

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

Cette page décrit les différences entre AIDL et HIDL HAL pour le HWC, ainsi que l'implémentation et le test du HAL AIDL.

Grâce au avantages offerts par AIDL, les fournisseurs sont encouragés à mettre en œuvre Démarrage du HAL du compositeur AIDL Android 13 au lieu de la version HIDL. Consultez le Implémentation.

Différences entre AIDL et HIDL HAL

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

  • Suppression de FMQ (Fast Message Queue) dans des commandes parcelables.

    Le HAL AIDL définit l'interface de commande en fonction de critères fortement typés parcelable par opposition aux commandes sérialisées sur FMQ en HIDL. Ce 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.

    executeCommands est définie dans IComposerClient.aidl. en tant que

    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 parcelables fortement typés définis dans CommandResultPayload.aidl

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

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

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

    Dans le HAL AIDL, les piles de couches SDR/HDR mixtes prennent en charge l'atténuation fluide de Couches SDR lorsqu'une couche HDR s'affiche simultanément à l'écran

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

    Le champ brightness dans ClientTargetPropertyWithBrightness permet au matériel de spécifier l'espace de luminosité pour la composition du client et instruction RenderEngine d'assombrir les couches SDR dans la composition du client.

    dimmingStage permet au matériel de configurer le moment où RenderEngine doit assombrir le contenu. Ce s'adapte aux ColorModes définis par le fournisseur, qui peuvent préférer baisser le gamma ce qui permet d'améliorer les contrastes définis par le fournisseur dans ses pipelines de couleurs.

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

    Certains appareils ont du 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 type de matériel doivent implémenter IComposerClient.getDisplayDecorationSupport pour renvoyer une structure DisplayDecorationSupport telle que définie dans la nouvelle DisplayDecorationSupport.aidl Cette structure décrit la PixelFormat et AlphaInterpretation et les énumérations requises par l'appareil. Lors de cette implémentation, l'UI du système marque le la couche de masque alpha en tant que DISPLAY_DECORATION, un nouveau type de composition qui tire parti du matériel dédié.

  • Ajout d'un nouveau expectedPresentTime sur DisplayCommand.aidl.

    Le champ expectedPresentTime permet à SurfaceFlinger de définir la valeur attendue à l'heure actuelle à laquelle le contenu actuel doit être affiché à l'écran. Grâce à cette SurfaceFlinger envoie une commande "Present" (présentation) à l'implémentation avant que ce qui lui permet de traiter une plus grande partie du travail de composition.

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

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

    • Avec setBootDisplayConfig, le framework informe les fournisseurs de la configuration de l'affichage du temps de démarrage. Fournisseurs devez mettre en cache dans la configuration d'affichage de démarrage et démarrer cette configuration à la prochaine redémarrer. Si l'appareil ne parvient pas à démarrer dans cette configuration, le fournisseur doit trouver un qui correspond à la résolution et à la fréquence d'actualisation de cette configuration. Si aucune existe, le fournisseur doit utiliser sa configuration d'affichage préférée.

    • Avec clearBootDisplayConfig, le framework demande aux fournisseurs d'effacer la configuration de l'affichage de démarrage ; démarrent dans la configuration d'affichage de leur choix lors du prochain redémarrage.

    • Avec 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 compatible, ces méthodes renvoient une la valeur de UNSUPPORTED.

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

    • Avec DISPLAY_IDLE_TIMER, les fournisseurs peuvent spécifier qu'un minuteur d'inactivité est mis en place par le fournisseur pour cet écran. En cas d'inactivité, cette fonctionnalité réduit la fréquence d'actualisation pour économiser 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 pour empêcher tout changement indésirable de la fréquence d'actualisation en cas d'inactivité.

    • Utiliser IComposerCallback.onVsyncIdle indique à la plate-forme que l'écran est inactif et que le vsync la cadence a changé. La plate-forme répond à ce rappel en réinitialisant son Modèle vsync. Il force une resynchronisation de vsync sur le frame suivant et apprend le nouveau Cadence de vsync.

Implémentation

Les fournisseurs ne sont pas tenus d'implémenter la solution AIDL HAL pour Android 13. Toutefois, ils sont encouragés à mettre en œuvre la 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 le HAL du matériel AIDL est implémenté dans les émulateurs Android.

Tests

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