Les capacités d'affichage (telles que les modes d'affichage et les types HDR pris en charge) peuvent changer de manière dynamique sur les appareils dotés d'écrans connectés en externe (avec HDMI ou DisplayPort), tels que les décodeurs Android TV (STB) et over-the-top (OTT) dispositifs. Ce changement peut se produire à la suite d'un signal de connexion à chaud HDMI, par exemple lorsque l'utilisateur passe d'un écran à un autre ou démarre l'appareil sans écran connecté. Android 12 et supérieur inclut des modifications dans le cadre pour gérer les capacités de branchement à chaud et d'affichage dynamique.
Cette page décrit la gestion des hotplugs d'affichage et les modifications des capacités d'affichage dans l'implémentation Composer HAL. De plus, il explique comment gérer le framebuffer associé et éviter les conditions de concurrence dans ces situations.
Mettre à jour les capacités d'affichage
Cette section décrit comment le framework Android gère les modifications des capacités d'affichage initiées par Composer HAL.
Avant qu'Android puisse gérer correctement les modifications des capacités d'affichage, l'OEM doit implémenter Composer HAL de sorte qu'il utilise onHotplug(display, connection=CONNECTED)
pour informer le framework de toute modification des capacités d'affichage. Une fois cela mis en œuvre, Android gère les modifications apportées aux fonctionnalités d'affichage comme suit :
- Lors de la détection d'un changement dans les capacités d'affichage, le framework reçoit une
onHotplug(display, connection=CONNECTED)
. - À la réception de la notification, le framework supprime son état d'affichage et le recrée avec les nouvelles fonctionnalités de HAL en utilisant les
getActiveConfig
,getDisplayConfigs
,getDisplayAttribute
,getColorModes
,getHdrCapabilities
etgetDisplayCapabilities
. - Une fois que le framework a recréé un nouvel état d'affichage, il envoie le rappel
onDisplayChanged
aux applications qui écoutent de tels événements.
Le framework réaffecte les framebuffers lors des onHotplug(display, connection=CONNECTED)
suivants. Voir Gestion du framebuffer client pour plus d'informations sur la façon de gérer correctement la mémoire du framebuffer afin d'éviter les échecs lors de l'allocation de nouveaux framebuffers.
Gérer les scénarios de connexion courants
Cette section explique comment gérer correctement divers scénarios de connexion dans vos implémentations lorsque l'affichage principal est connecté et déconnecté.
Ayant été conçu pour les appareils mobiles, le framework Android n'a pas de prise en charge intégrée pour un affichage principal déconnecté. Au lieu de cela, la HAL doit remplacer l'affichage principal par un affichage d'espace réservé dans ses interactions avec le cadre dans le cas où un affichage principal est physiquement déconnecté.
Les scénarios suivants peuvent se produire dans les décodeurs et les dongles TV qui ont des écrans connectés en externe qui peuvent être déconnectés. Pour implémenter la prise en charge de ces scénarios, utilisez les informations du tableau ci-dessous :
Scénario | Manutention |
---|---|
Pas d'écran connecté au démarrage |
|
L'affichage principal est physiquement connecté |
|
L'affichage principal est physiquement déconnecté |
|
Utilisez des ID de configuration séquentiels pour éviter les conditions de concurrence
Des conditions de concurrence peuvent survenir si Composer HAL met à jour les configurations d'affichage prises en charge simultanément avec le framework appelant setActiveConfig
ou setActiveConfigWithConstraints
. La solution consiste à implémenter Composer HAL pour utiliser des ID séquentiels et éviter ce problème.
Cette section décrit comment les conditions de concurrence peuvent se produire, suivie de détails sur la façon d'implémenter Composer HAL afin qu'il utilise des ID séquentiels pour empêcher de telles conditions.
Considérez la séquence d'événements suivante, lorsque de nouveaux ID séquentiels ne sont PAS attribués aux nouvelles configurations d'affichage, provoquant une condition de concurrence :
Les ID de configuration d'affichage pris en charge sont :
- identifiant=1 , 1080x1920 60 Hz
- id=2 , 1080x1920 50 Hz
Le framework appelle
setActiveConfig(display, config=1)
.Simultanément, Composer HAL traite un changement de configuration d'affichage et met à jour son état interne vers un nouvel ensemble de configurations d'affichage, illustré comme suit :
- identifiant=1 , 2160x3840 60Hz
- id=2 , 2160x3840 50Hz
- id=3 , 1080x1920 60Hz
- id=4 , 1080x1920 50Hz
Composer HAL envoie un événement
onHotplug
au framework, pour notifier que l'ensemble des modes pris en charge a changé.Le Composer HAL reçoit
setActiveConfig(display, config=1)
(à partir de l'étape 2).Le HAL interprète que le framework a demandé un changement de configuration à 2160x3840 60 Hz , bien qu'en réalité 1080x1920 60 Hz ait été souhaité.
Le processus utilisant des attributions d'ID non séquentielles se termine ici par une mauvaise interprétation du changement de configuration souhaité.
Configurer Composer HAL pour utiliser des ID séquentiels
Pour éviter de telles conditions de concurrence, l'OEM doit implémenter la HAL Composer comme suit :
- Lorsque Composer HAL met à jour les configurations d'affichage prises en charge, il attribue de nouveaux ID séquentiels aux nouvelles configurations d'affichage.
- Lorsque le framework appelle
setActiveConfig
ousetActiveConfigWithConstraints
avec un ID de configuration non valide, Composer HAL ignore l'appel.
Ces étapes servent à prévenir les conditions de concurrence comme indiqué dans la discussion suivante.
Tenez compte de la séquence d'événements suivante, lorsque de nouveaux ID séquentiels sont attribués aux nouvelles configurations d'affichage :
Les ID de configuration d'affichage pris en charge sont :
- identifiant=1 , 1080x1920 60Hz
- id=2 , 1080x1920 50Hz
Le framework appelle
setActiveConfig(display, config=1)
.Lorsqu'un changement de configuration d'affichage est traité, le prochain ensemble d'ID de configuration est attribué à partir du nombre entier inutilisé suivant, illustré comme suit :
id=3 , 2160x3840 60Hz
id=4 , 2160x3840 50Hz
id=5 , 1080x1920 60Hz
id=6 , 1080x1920 50Hz
Le Composer HAL envoie un événement
onHotplug
au framework, pour notifier que l'ensemble des modes pris en charge a changé.Le Composer HAL reçoit
setActiveConfig(display, config=1)
(à partir de l'étape 2).Le Composer HAL ignore l'appel car l'ID n'est plus valide.
Le framework reçoit et traite l'événement
onHotplug
de l'étape 4. Il appelle le Composer HAL à l'aide des fonctionsgetDisplayConfigs
etgetDisplayAttribute
. Avec ces fonctions, le framework identifie le nouvel ID (5) pour la résolution et le taux de rafraîchissement souhaités de 1080x1920 et 60 Hz.Le framework envoie un autre événement
setActiveConfig
avec un ID mis à jour de 5.Le Composer HAL reçoit
setActiveConfig(display, config=5)
de l'étape 5.Le HAL interprète correctement que le framework a demandé un changement de configuration en 1080x1920 60 Hz.
Comme illustré dans l'exemple ci-dessus, le processus utilisant des affectations d'ID séquentielles garantit que la condition de concurrence est évitée et que le changement de configuration d'affichage correct est mis à jour.