Le funzionalità del display (ad esempio le modalità di visualizzazione e i tipi di HDR supportati) possono cambiare dinamicamente sui dispositivi con display collegati esternamente (con HDMI o DisplayPort), ad esempio set-top box (STB) Android TV e dispositivi over-the-top (OTT). Questo cambiamento può verificarsi a causa di un segnale hot plug HDMI, ad esempio quando l'utente passa da un display all'altro o avvia il dispositivo senza un display collegato. Android 12 e versioni successive includono modifiche al framework per gestire il hot-plugging e le funzionalità di visualizzazione dinamica.
Questa pagina descrive la gestione delle hot plug-in per la visualizzazione e le modifiche alle funzionalità di visualizzazione nell'implementazione di Composer HAL. Inoltre, spiega come gestire il framebuffer associato e prevenire le condizioni di gara in queste situazioni.
Aggiorna le funzionalità del display
Questa sezione descrive come il framework Android gestisce le modifiche alle funzionalità di visualizzazione avviate dall'HAL di Composer.
Prima che Android possa gestire correttamente le modifiche alle funzionalità di visualizzazione, l'OEM deve implementare Composer HAL in modo che utilizzi onHotplug(display, connection=CONNECTED) per notificare al framework eventuali modifiche alle funzionalità di visualizzazione. Una volta implementata la funzionalità, Android gestisce le modifiche alle funzionalità di visualizzazione come segue:
- Quando viene rilevata una modifica delle funzionalità di visualizzazione, il framework riceve una
onHotplug(display, connection=CONNECTED)notifica. - Al ricevimento della notifica, il framework rilascia il proprio stato di visualizzazione e lo ricrea con le nuove funzionalità dell'HAL utilizzando i metodi
getActiveConfig,getDisplayConfigs,getDisplayAttribute,getColorModes,getHdrCapabilitiesegetDisplayCapabilities. - Dopo che il framework ha ricreato un nuovo stato di visualizzazione, invia il callback
onDisplayChangedalle app che ascoltano questi eventi.
Il framework rialloca i framebuffer negli eventi onHotplug(display, connection=CONNECTED)
successivi. Per ulteriori informazioni su come gestire correttamente la memoria del framebuffer per evitare errori durante l'allocazione di nuovi framebuffer, consulta la sezione Gestione del framebuffer client.
Gestire scenari di connessione comuni
Questa sezione spiega come gestire correttamente i vari scenari di connessione nelle implementazioni quando il display principale è connesso e disconnesso.
Poiché è stato creato per i dispositivi mobili, il framework Android non ha il supporto integrato per un display principale scollegato. L'HAL deve invece sostituire il display principale con un display segnaposto nelle sue interazioni con il framework nel caso in cui un display principale sia scollegato fisicamente.
I seguenti scenari possono verificarsi in TV set-top box e TV dongle con display collegati esternamente che possono essere scollegati. Per implementare il supporto per questi scenari, utilizza le informazioni riportate nella tabella seguente:
| Scenario | Prescrizioni d'uso |
|---|---|
| Nessun display connesso all'avvio |
|
| Il display principale è collegato fisicamente |
|
| Il display principale è scollegato fisicamente |
|
Considerazioni sulle connessioni non HDMI
Android TV supporta solo le seguenti risoluzioni:
- 720x1280
- 1080x1920
- 2160x3840
- 4320x7680
Quando un set-top box o un dongle TV tenta di visualizzare una risoluzione non supportata, ad esempio 480i tramite una connessione CVBS, all'utente viene mostrato un messaggio di errore.
Se l'STB o il dongle TV ha connessioni sia HDMI che non HDMI, la connessione HDMI è il display principale e la connessione non HDMI è inattiva. Di conseguenza, se la connessione HDMI viene disconnessa mentre la connessione non HDMI è ancora collegata, viene inviato un evento a SurfaceFlinger e le funzionalità del display non HDMI devono essere riflesse tramite getDisplayAttribute e altre API iComposerClient (ad esempio getHdrCapabilities).
Utilizza ID di configurazione sequenziali per evitare condizioni di gara
Possono verificarsi condizioni di gara se l'HAL di Composer aggiorna le configurazioni dei display supportati contemporaneamente alla chiamata del framework a setActiveConfig o setActiveConfigWithConstraints.
La soluzione è implementare HAL di Composer per utilizzare ID sequenziali ed evitare questo problema.
Questa sezione descrive come potrebbero verificarsi le condizioni di gara, seguita da dettagli su come implementare HAL di Composer in modo che utilizzi ID sequenziali per evitare queste condizioni.
Prendi in considerazione la seguente sequenza di eventi, quando ai nuovi ID sequenziali NON vengono assegnati le nuove configurazioni di visualizzazione, causando una condizione di gara:
Gli ID configurazione display supportati sono:
- id=1, 1080x1920 60 Hz
- id=2, 1080x1920 50 Hz
Il framework chiama
setActiveConfig(display, config=1).Contemporaneamente, l'HAL di Composer elabora una modifica delle configurazioni di visualizzazione e aggiorna il proprio stato interno con un nuovo insieme di configurazioni di visualizzazione, come mostrato di seguito:
- id=1, 2160x3840 60 Hz
- id=2, 2160x3840 50 Hz
- id=3, 1080x1920 60 Hz
- id=4, 1080x1920 50 Hz
Composer HAL invia un evento
onHotplugal framework per notificare che il set di modalità supportate è cambiato.L'HAL di Composer riceve
setActiveConfig(display, config=1)(dal passaggio 2).L'HAL interpreta che il framework ha richiesto una modifica della configurazione a 2160x3840 60 Hz, anche se in realtà è stata desiderata 1080x1920 60 Hz.
Il processo che utilizza le assegnazioni di ID non sequenziali termina qui con una errata interpretazione della modifica della configurazione desiderata.
Configurare HAL di Composer per utilizzare ID sequenziali
Per evitare queste condizioni di gara, l'OEM deve implementare l'HAL di Composer come segue:
- Quando l'HAL di Composer aggiorna le configurazioni di visualizzazione supportate, assegna nuovi ID sequenziali alle nuove configurazioni di visualizzazione.
- Quando il framework chiama
setActiveConfigosetActiveConfigWithConstraintscon un ID di configurazione non valido, l'HAL di Composer ignora la chiamata.
Questi passaggi servono a evitare condizioni di gara come mostrato nella discussione che segue.
Considera la seguente sequenza di eventi, quando vengono assegnati nuovi ID sequenziali alle nuove configurazioni di visualizzazione:
Gli ID configurazione display supportati sono:
- id=1, 1080x1920 60 Hz
- id=2, 1080x1920 50 Hz
Il framework chiama
setActiveConfig(display, config=1).Quando viene elaborata una modifica delle configurazioni di visualizzazione, il successivo insieme di ID configurazione viene assegnato a partire dal successivo numero intero inutilizzato, come mostrato di seguito:
id=3, 2160x3840 60 Hz
id=4, 2160x3840 50 Hz
id=5, 1080x1920 60 Hz
id=6, 1080x1920 50 Hz
Composer HAL invia un evento
onHotplugal framework per notificare che il set di modalità supportate è cambiato.Composer HAL riceve
setActiveConfig(display, config=1)(dal passaggio 2).L'HAL di Composer ignora la chiamata perché l'ID non è più valido.
Il framework riceve ed elabora l'evento
onHotplugdel passaggio 4. Effettua chiamate a Composer HAL utilizzando le funzionigetDisplayConfigsegetDisplayAttribute. Con queste funzioni, il framework identifica il nuovo ID (5) per la risoluzione e la frequenza di aggiornamento desiderate di 1080 x 1920 e 60 Hz.Il framework invia un altro evento
setActiveConfigcon un ID aggiornato pari a 5.L'HAL di Composer riceve
setActiveConfig(display, config=5)dal passaggio 5.L'HAL interpreta correttamente che il framework ha richiesto una modifica della configurazione a 1080 x 1920 a 60 Hz.
Come mostrato nell'esempio precedente, il processo che utilizza le assegnazioni di ID sequenziali garantisce che la condizione di gara venga evitata e che la modifica della configurazione di visualizzazione corretta venga aggiornata.