Горячее подключение

Возможности отображения (например, режимы отображения и поддерживаемые типы HDR) могут динамически меняться на устройствах с внешними подключенными дисплеями (с HDMI или DisplayPort), таких как ТВ-приставки Android (STB) и телевизионные приставки (OTT) устройства. Это изменение может произойти в результате сигнала горячего подключения HDMI, например, когда пользователь переключается с одного дисплея на другой или загружает устройство без подключенного дисплея. Android 12 и более поздних версий включает изменения в платформе для поддержки горячего подключения и возможностей динамического отображения.

На этой странице описывается обработка горячего подключения дисплея и изменения возможностей дисплея в реализации Composer HAL. Кроме того, в нем обсуждается, как управлять соответствующим кадровым буфером и предотвращать состояния гонки в таких ситуациях.

Обновить возможности отображения

В этом разделе описывается, как платформа Android обрабатывает изменения в возможностях отображения, инициированные Composer HAL.

Прежде чем Android сможет правильно обрабатывать изменения возможностей отображения, OEM-производитель должен реализовать Composer HAL таким образом, чтобы он использовал onHotplug(display, connection=CONNECTED) для уведомления платформы о любых изменениях возможностей отображения. После этого Android обрабатывает изменения возможностей отображения следующим образом:

1. При обнаружении изменения возможностей отображения платформа получает уведомление onHotplug(display, connection=CONNECTED) .
2. При получении уведомления платформа удаляет свое состояние отображения и воссоздает его с новыми возможностями из HAL, используя методы getActiveConfig , getDisplayConfigs , getDisplayAttribute , getColorModes , getHdrCapabilities и getDisplayCapabilities .
3. После того как платформа воссоздает новое состояние отображения, она отправляет обратный вызов onDisplayChanged приложениям, которые прослушивают такие события.

Платформа перераспределяет кадровые буферы при последующих событиях onHotplug(display, connection=CONNECTED) . См. раздел «Управление кадровым буфером клиента» для получения дополнительной информации о том, как правильно управлять памятью кадрового буфера, чтобы избежать сбоев при выделении новых кадровых буферов.

Обработка распространенных сценариев подключения

В этом разделе описано, как правильно обрабатывать различные сценарии подключения в ваших реализациях, когда основной дисплей подключен и отключен.

Будучи созданной для мобильных устройств, платформа Android не имеет встроенной поддержки отключенного основного дисплея. Вместо этого HAL должен заменить основной дисплей дисплеем-заполнителем при взаимодействии с платформой в случае, когда основной дисплей физически отключен.

Следующие сценарии могут возникнуть в приставках и ТВ-адаптерах с внешними подключенными дисплеями, которые можно отключить. Чтобы реализовать поддержку этих сценариев, используйте информацию в таблице ниже:

Сценарий	Умение обращаться
Нет подключенного дисплея во время загрузки	Отправьте сигнал onHotplug(display, connection=CONNECTED) из Composer HAL в платформу. Замените физическое состояние отображения внутри Composer HAL на состояние отображения заполнителя.
Основной дисплей физически подключен	Отправьте еще одно событие onHotplug(display, connection=CONNECTED) из HAL Composer в платформу. Это заставляет платформу перезагрузить все возможности отображения.
Основной дисплей физически отключен	Отправьте еще одно событие onHotplug(display, connection=CONNECTED) из HAL Composer в платформу. Замените физическое состояние отображения внутри Composer HAL на состояние отображения заполнителя. Отображение заполнителя должно иметь один режим отображения, чтобы платформа отправляла обратный вызов onDisplayChanged приложениям (поскольку набор поддерживаемых режимов изменился). Этот режим одного дисплея должен соответствовать последнему активному режиму физического дисплея перед отключением, чтобы приложения не получали события изменения конфигурации .

Используйте последовательные идентификаторы конфигурации для предотвращения состояний гонки.

Условия гонки могут возникнуть, если Composer HAL обновляет поддерживаемые конфигурации отображения одновременно с вызовом платформы setActiveConfig или setActiveConfigWithConstraints . Решение состоит в том, чтобы реализовать Composer HAL для использования последовательных идентификаторов и предотвращения этой проблемы.

В этом разделе описывается, как могут возникнуть условия гонки, а затем подробно описано, как реализовать Composer HAL, чтобы он использовал последовательные идентификаторы для предотвращения таких условий.

Рассмотрим следующую последовательность событий, когда новые последовательные идентификаторы НЕ назначаются новым конфигурациям дисплея, что приводит к состоянию гонки:

1. Поддерживаемые идентификаторы конфигурации дисплея:

   • идентификатор=1 , 1080x1920, 60 Гц
   • идентификатор=2 , 1080x1920, 50 Гц

2. Платформа вызывает setActiveConfig(display, config=1) .

3. Одновременно Composer HAL обрабатывает изменение конфигураций отображения и обновляет свое внутреннее состояние до нового набора конфигураций отображения, как показано ниже:

   • идентификатор=1 , 2160x3840, 60 Гц
   • идентификатор=2 , 2160x3840, 50 Гц
   • идентификатор=3 , 1080x1920, 60 Гц
   • идентификатор=4 , 1080x1920, 50 Гц

4. Composer HAL отправляет в платформу событие onHotplug , чтобы уведомить об изменении набора поддерживаемых режимов.

5. Composer HAL получает setActiveConfig(display, config=1) (из шага 2).

6. HAL интерпретирует, что платформа запросила изменение конфигурации на 2160x3840 60 Гц , хотя на самом деле было желательно 1080x1920 60 Гц .

Здесь процесс с использованием непоследовательного назначения идентификаторов заканчивается неправильной интерпретацией желаемого изменения конфигурации.

Настройте Composer HAL для использования последовательных идентификаторов.

Чтобы избежать таких состояний гонки, OEM должен реализовать Composer HAL следующим образом:

• Когда Composer HAL обновляет поддерживаемые конфигурации дисплея, он назначает новые последовательные идентификаторы новым конфигурациям дисплея.
• Когда платформа вызывает setActiveConfig или setActiveConfigWithConstraints с недопустимым идентификатором конфигурации, Composer HAL игнорирует вызов.

Эти шаги служат для предотвращения состояний гонки, как показано в следующем обсуждении.

Рассмотрим следующую последовательность событий, когда новым конфигурациям дисплея назначаются новые последовательные идентификаторы:

1. Поддерживаемые идентификаторы конфигурации дисплея:

   • идентификатор=1 , 1080x1920, 60 Гц
   • идентификатор=2 , 1080x1920, 50 Гц

2. Платформа вызывает setActiveConfig(display, config=1) .

3. При обработке изменения конфигурации отображения следующий набор идентификаторов конфигурации назначается, начиная со следующего неиспользуемого целого числа, как показано ниже:

   • идентификатор=3 , 2160x3840, 60 Гц

   • идентификатор=4 , 2160x3840, 50 Гц

   • идентификатор=5 , 1080x1920, 60 Гц

   • идентификатор=6 , 1080x1920, 50 Гц

4. Composer HAL отправляет событие onHotplug в платформу, чтобы уведомить об изменении набора поддерживаемых режимов.

5. Composer HAL получает setActiveConfig(display, config=1) (из шага 2).

6. Composer HAL игнорирует вызов, поскольку идентификатор больше не действителен.

7. Платформа получает и обрабатывает событие onHotplug с шага 4. Она вызывает Composer HAL с помощью функций getDisplayConfigs и getDisplayAttribute . С помощью этих функций платформа определяет новый идентификатор (5) для желаемого разрешения и частоты обновления 1080x1920 и 60 Гц.

8. Платформа отправляет еще одно событие setActiveConfig с обновленным идентификатором 5.

9. Composer HAL получает setActiveConfig(display, config=5) с шага 5.

10. HAL правильно интерпретирует, что платформа запросила изменение конфигурации на 1080x1920 60 Гц.

Как показано в приведенном выше примере, процесс с использованием последовательного назначения идентификаторов гарантирует предотвращение состояния гонки и обновление правильных изменений конфигурации дисплея.