Anzeigefunktionen (z. B. Anzeigemodi und unterstützte HDR-Typen) können sich dynamisch auf Geräten ändern, die über extern angeschlossene Displays (mit HDMI oder DisplayPort) verfügen, z. B. Android TV-Set-Top-Boxen (STBs) und Over-the-Top-Boxen (OTT). Geräte. Diese Änderung kann als Folge eines HDMI-Hotplug-Signals auftreten, beispielsweise wenn der Benutzer von einem Display auf ein anderes wechselt oder das Gerät ohne angeschlossenes Display startet. Android 12 und höher enthält Änderungen im Framework, um Hotplugging und dynamische Anzeigefunktionen zu handhaben.
Auf dieser Seite werden die Handhabung von Anzeige-Hotplugs und Änderungen der Anzeigefunktionen in der Composer-HAL-Implementierung beschrieben. Darüber hinaus wird erläutert, wie der zugehörige Framebuffer verwaltet und Race Conditions in solchen Situationen verhindert werden können.
Anzeigefunktionen aktualisieren
In diesem Abschnitt wird beschrieben, wie das Android-Framework von Composer HAL initiierte Änderungen der Anzeigefunktionen verarbeitet.
Bevor Android Änderungen an den Anzeigefunktionen ordnungsgemäß verarbeiten kann, muss der OEM Composer HAL so implementieren, dass er onHotplug(display, connection=CONNECTED)
verwendet, um das Framework über alle Änderungen an den Anzeigefunktionen zu informieren. Nachdem dies implementiert wurde, verarbeitet Android Änderungen an den Anzeigefunktionen wie folgt:
- Wenn eine Änderung der Anzeigefunktionen erkannt wird, erhält das Framework eine
onHotplug(display, connection=CONNECTED)
-Benachrichtigung. - Beim Empfang der Benachrichtigung löscht das Framework seinen Anzeigestatus und erstellt ihn mit den neuen Funktionen aus der HAL neu, indem es die Methoden
getActiveConfig
,getDisplayConfigs
,getDisplayAttribute
,getColorModes
,getHdrCapabilities
undgetDisplayCapabilities
verwendet. - Nachdem das Framework einen neuen Anzeigestatus neu erstellt hat, sendet es den
onDisplayChanged
Rückruf an die Apps, die auf solche Ereignisse warten.
Das Framework weist die Framebuffer bei nachfolgenden onHotplug(display, connection=CONNECTED)
-Ereignissen neu zu. Weitere Informationen zur ordnungsgemäßen Verwaltung des Framebuffer-Speichers, um Fehler bei der Zuweisung neuer Framebuffer zu vermeiden, finden Sie unter Client-Framebuffer-Verwaltung .
Behandeln Sie häufige Verbindungsszenarien
In diesem Abschnitt wird erläutert, wie Sie verschiedene Verbindungsszenarien in Ihren Implementierungen richtig handhaben, wenn die primäre Anzeige angeschlossen und getrennt wird.
Da das Android-Framework für mobile Geräte entwickelt wurde, bietet es keine integrierte Unterstützung für eine getrennte primäre Anzeige. Stattdessen muss die HAL in ihren Interaktionen mit dem Framework die primäre Anzeige durch eine Platzhalteranzeige ersetzen, wenn eine primäre Anzeige physisch getrennt ist.
Die folgenden Szenarien können bei STBs und TV-Dongles auftreten, die über extern angeschlossene Displays verfügen, die getrennt werden können. Um die Unterstützung für diese Szenarien zu implementieren, verwenden Sie die Informationen in der folgenden Tabelle:
Szenario | Handhabung |
---|---|
Beim Booten ist kein Display angeschlossen |
|
Das primäre Display ist physisch verbunden |
|
Die primäre Anzeige ist physisch getrennt |
|
Verwenden Sie sequentielle Konfigurations-IDs, um Race Conditions zu verhindern
Race-Bedingungen können auftreten, wenn die Composer-HAL die unterstützten Anzeigekonfigurationen gleichzeitig mit dem Framework-Aufruf setActiveConfig
oder setActiveConfigWithConstraints
aktualisiert. Die Lösung besteht darin, Composer HAL zu implementieren, um sequentielle IDs zu verwenden und dieses Problem zu verhindern.
In diesem Abschnitt wird beschrieben, wie die Race-Bedingungen auftreten können, gefolgt von Details zur Implementierung von Composer HAL, sodass es sequenzielle IDs verwendet, um solche Bedingungen zu verhindern.
Betrachten Sie die folgende Abfolge von Ereignissen, wenn den neuen Anzeigekonfigurationen KEINE neuen, sequentiellen IDs zugewiesen werden, was zu einer Race-Bedingung führt:
Die unterstützten Anzeigekonfigurations-IDs sind:
- id=1 , 1080x1920 60 Hz
- id=2 , 1080x1920 50 Hz
Das Framework ruft
setActiveConfig(display, config=1)
auf.Gleichzeitig verarbeitet der Composer-HAL eine Änderung der Anzeigekonfigurationen und aktualisiert seinen internen Status auf einen neuen Satz von Anzeigekonfigurationen, wie folgt dargestellt:
- id=1 , 2160x3840 60 Hz
- id=2 , 2160x3840 50 Hz
- id=3 , 1080x1920 60 Hz
- id=4 , 1080x1920 50 Hz
Composer HAL sendet ein
onHotplug
Ereignis an das Framework, um zu benachrichtigen, dass sich der Satz unterstützter Modi geändert hat.Die Composer-HAL empfängt
setActiveConfig(display, config=1)
(aus Schritt 2).Der HAL interpretiert, dass das Framework eine Konfigurationsänderung auf 2160 x 3840 60 Hz angefordert hat, obwohl in Wirklichkeit 1080 x 1920 60 Hz gewünscht war.
Der Prozess mit nichtsequentiellen ID-Zuweisungen endet hier mit einer Fehlinterpretation der gewünschten Konfigurationsänderung.
Konfigurieren Sie Composer HAL für die Verwendung sequenzieller IDs
Um solche Race-Conditions zu vermeiden, muss der OEM die Composer-HAL wie folgt implementieren:
- Wenn die Composer-HAL die unterstützten Anzeigekonfigurationen aktualisiert, weist sie den neuen Anzeigekonfigurationen neue, sequentielle IDs zu.
- Wenn das Framework
setActiveConfig
odersetActiveConfigWithConstraints
mit einer ungültigen Konfigurations-ID aufruft, ignoriert die Composer-HAL den Aufruf.
Diese Schritte dienen dazu, Rennbedingungen zu verhindern, wie in der folgenden Diskussion gezeigt.
Betrachten Sie die folgende Abfolge von Ereignissen, wenn den neuen Anzeigekonfigurationen neue, sequentielle IDs zugewiesen werden:
Die unterstützten Anzeigekonfigurations-IDs sind:
- id=1 , 1080x1920 60 Hz
- id=2 , 1080x1920 50 Hz
Das Framework ruft
setActiveConfig(display, config=1)
auf.Wenn eine Änderung der Anzeigekonfigurationen verarbeitet wird, wird der nächste Satz von Konfigurations-IDs beginnend mit der nächsten nicht verwendeten Ganzzahl zugewiesen, wie folgt:
id=3 , 2160x3840 60 Hz
id=4 , 2160x3840 50 Hz
id=5 , 1080x1920 60 Hz
id=6 , 1080x1920 50 Hz
Der Composer-HAL sendet ein
onHotplug
Ereignis an das Framework, um zu benachrichtigen, dass sich der Satz unterstützter Modi geändert hat.Die Composer-HAL empfängt
setActiveConfig(display, config=1)
(aus Schritt 2).Der Composer-HAL ignoriert den Aufruf, da die ID nicht mehr gültig ist.
Das Framework empfängt und verarbeitet das
onHotplug
Ereignis aus Schritt 4. Es ruft die Composer-HAL mithilfe der FunktionengetDisplayConfigs
undgetDisplayAttribute
auf. Mit diesen Funktionen ermittelt das Framework die neue ID (5) für die gewünschte Auflösung und Bildwiederholfrequenz von 1080x1920 und 60 Hz.Das Framework sendet ein weiteres
setActiveConfig
Ereignis mit der aktualisierten ID 5.Die Composer-HAL erhält
setActiveConfig(display, config=5)
aus Schritt 5.Der HAL interpretiert korrekt, dass das Framework eine Konfigurationsänderung auf 1080 x 1920 60 Hz angefordert hat.
Wie im obigen Beispiel gezeigt, stellt der Prozess mit sequentiellen ID-Zuweisungen sicher, dass die Race-Bedingung verhindert wird und die korrekte Änderung der Anzeigekonfiguration aktualisiert wird.