Возможности отображения (такие как режимы отображения и поддерживаемые типы HDR) могут динамически изменяться на устройствах с внешними дисплеями (через HDMI или DisplayPort), таких как телеприставки Android TV (STB) и устройства Over-the-top (OTT). устройства. Это изменение может произойти в результате сигнала горячего подключения HDMI, например, когда пользователь переключается с одного дисплея на другой или загружает устройство без подключенного дисплея. Начиная с Android 12, в структуру были внесены изменения для поддержки возможностей горячего подключения и динамического отображения.
На этой странице рассказывается, как обрабатывать «горячие» подключения дисплея и изменения возможностей дисплея в реализации Composer HAL. Кроме того, в нем обсуждается, как управлять соответствующим буфером кадра и предотвращать условия гонки в таких ситуациях.
Обновление возможностей отображения
В этом разделе описывается, как платформа Android обрабатывает изменения в возможностях отображения, инициированные Composer HAL.
Прежде чем Android сможет правильно обрабатывать изменения в возможностях отображения, OEM-производитель должен внедрить Composer HAL таким образом, чтобы он использовал onHotplug(display, connection=CONNECTED)
для уведомления платформы о любых изменениях возможностей отображения. Как только это реализовано, Android обрабатывает изменения возможностей отображения следующим образом:
- При обнаружении изменения возможностей отображения платформа получает
onHotplug(display, connection=CONNECTED)
. - При получении уведомления инфраструктура отбрасывает свое состояние отображения и воссоздает его с новыми возможностями из HAL с помощью
getActiveConfig
,getDisplayConfigs
,getDisplayAttribute
,getColorModes
,getHdrCapabilities
иgetDisplayCapabilities
. - Как только платформа воссоздает новое состояние отображения, она отправляет обратный вызов
onDisplayChanged
приложениям, которые прослушивают такие события.
Платформа перераспределяет буферы кадра при последующих onHotplug(display, connection=CONNECTED)
. См. Управление памятью кадрового буфера для получения дополнительной информации о том, как справиться с этим.
Обработка распространенных сценариев подключения
В этом разделе описывается, как правильно обрабатывать различные сценарии подключения в ваших реализациях, когда основной дисплей подключен и отключен.
Платформа Android, созданная для мобильных устройств, не имеет встроенной поддержки отключенного основного дисплея. Вместо этого HAL должен заменить основной дисплей замещающим дисплеем при взаимодействии с платформой в случае, когда основной дисплей физически отключен.
Следующие сценарии могут возникать в телевизионных приставках и телевизионных адаптерах, которые имеют внешне подключенные дисплеи, которые можно отключить. Чтобы реализовать поддержку этих сценариев, используйте информацию в таблице ниже:
Сценарий | Умение обращаться |
---|---|
Нет подключенного дисплея во время загрузки |
|
Основной дисплей физически подключен |
|
Основной дисплей физически отключен |
|
Управление памятью фреймбуфера
Когда уже подключенный дисплей получает последующее событие уведомления onHotplug(display, connection=CONNECTED)
, платформа перераспределяет буферы кадра, связанные с этим дисплеем. Реализации устройств должны предвидеть такое поведение и должным образом управлять памятью кадрового буфера. При реализации используйте следующие рекомендации:
Перед отправкой последующих событий уведомления
onHotplug(display, connection=CONNECTED)
обязательно освободите дескрипторы кадровых буферов, чтобы система могла правильно их освободить, прежде чем перераспределять их. Если освобождение не удалось, перераспределение может завершиться ошибкой из-за нехватки памяти.Мы рекомендуем выделять выделенный пул памяти для кадровых буферов, отделенный от остальной части буфера графической памяти.
Это важно, потому что между освобождением и перераспределением кадровых буферов сторонний процесс может попытаться выделить графическую память. Если тот же пул графической памяти используется буфером кадра и если графическая память заполнена, сторонний процесс может занять графическую память, ранее выделенную буфером кадра, что оставит недостаточно памяти для перераспределения буфера кадра (или, возможно, фрагментации пространства памяти) .
Использование последовательных идентификаторов конфигурации для предотвращения условий гонки
Условия гонки могут возникнуть, если Composer HAL обновляет поддерживаемые конфигурации дисплея одновременно с фреймворком, вызывающим setActiveConfig
или setActiveConfigWithConstraints
. Решение состоит в том, чтобы реализовать Composer HAL для использования последовательных идентификаторов и предотвращения этой проблемы.
В этом разделе описывается, как могут возникнуть условия гонки, а затем подробно о том, как реализовать Composer HAL, чтобы он использовал последовательные идентификаторы для предотвращения таких условий.
Рассмотрим следующую последовательность событий, когда новые последовательные идентификаторы НЕ назначаются новым конфигурациям дисплея, вызывая состояние гонки:
Поддерживаемые идентификаторы конфигурации дисплея:
- id=1 , 1080x1920 60 Гц
- ID=2 , 1080x1920 50 Гц
Фреймворк вызывает
setActiveConfig(display, config=1)
.Одновременно Composer HAL обрабатывает изменение конфигураций дисплея и обновляет свое внутреннее состояние до нового набора конфигураций дисплея, как показано ниже:
- id=1 , 2160x3840 60 Гц
- id=2 , 2160x3840 50 Гц
- ID=3 , 1080x1920 60 Гц
- ID=4 , 1080x1920 50 Гц
Composer HAL отправляет событие
onHotplug
в фреймворк, чтобы уведомить об изменении набора поддерживаемых режимов.Composer HAL получает
setActiveConfig(display, config=1)
(из шага 2).HAL интерпретирует, что фреймворк запросил изменение конфигурации на 2160x3840 60hz , хотя на самом деле было желательно 1080x1920 60hz .
Процесс, использующий непоследовательные назначения идентификаторов, заканчивается здесь неверной интерпретацией желаемого изменения конфигурации.
Настройка Composer HAL для использования последовательных идентификаторов
Чтобы избежать таких условий гонки, OEM-производитель должен реализовать Composer HAL следующим образом:
- Когда Composer HAL обновляет поддерживаемые конфигурации дисплея, он назначает новые последовательные идентификаторы новым конфигурациям дисплея.
- Когда платформа вызывает
setActiveConfig
илиsetActiveConfigWithConstraints
с недопустимым идентификатором конфигурации, Composer HAL игнорирует вызов.
Эти шаги служат для предотвращения условий гонки, как показано в следующем обсуждении.
Рассмотрим следующую последовательность событий, когда новым конфигурациям дисплея назначаются новые последовательные идентификаторы:
Поддерживаемые идентификаторы конфигурации дисплея:
- id=1 , 1080x1920 60 Гц
- ID=2 , 1080x1920 50 Гц
Фреймворк вызывает
setActiveConfig(display, config=1)
.Когда изменение конфигураций дисплея обрабатывается, следующий набор идентификаторов конфигураций назначается, начиная со следующего неиспользуемого целого числа, как показано ниже:
id=3 , 2160x3840 60 Гц
id=4 , 2160x3840 50 Гц
ID=5 , 1080x1920 60 Гц
ID=6 , 1080x1920 50 Гц
Composer HAL отправляет событие
onHotplug
в инфраструктуру, чтобы уведомить об изменении набора поддерживаемых режимов.Composer HAL получает
setActiveConfig(display, config=1)
(из шага 2).Composer HAL игнорирует вызов, поскольку идентификатор больше недействителен.
Фреймворк получает и обрабатывает событие
onHotplug
с шага 4. Он вызывает Composer HAL с помощью функцийgetDisplayConfigs
иgetDisplayAttribute
. С помощью этих функций фреймворк идентифицирует новый идентификатор (5) для нужного разрешения и частоты обновления 1080x1920 и 60 Гц.Платформа отправляет еще одно событие
setActiveConfig
с обновленным идентификатором 5.Composer HAL получает
setActiveConfig(display, config=5)
с шага 5.HAL правильно интерпретирует, что фреймворк запросил изменение конфигурации на 1080x1920 60 Гц.
Как показано в приведенном выше примере, процесс с использованием последовательных назначений идентификаторов гарантирует, что состояние гонки будет предотвращено, а правильное изменение конфигурации дисплея будет обновлено.