AIDL dla interfejsu HAL usługi Hardware Composer

Od Androida 13 interfejs HAL dla komponisty sprzętowego (HWC) jest definiowany w AIDL, a wersje HIDL od android.hardware.graphics.composer@2.1 do android.hardware.graphics.composer@2.4 są wycofane.

Na tej stronie opisano różnice między interfejsem AIDL i HIDL HAL w przypadku HWC oraz implementację i testowanie interfejsu AIDL HAL.

Ze względu na zalety oferowane przez AIDL dostawcy powinni zaimplementować kompozytora HAL AIDL w wersji Android 13 zamiast wersji HIDL. Więcej informacji znajdziesz w sekcji Wdrażanie.

Różnice między interfejsami HAL AIDL i HIDL

Nowy interfejs HAL do tworzenia kompozyturu AIDL o nazwie android.hardware.graphics.composer3 jest zdefiniowany w pliku IComposer.aidl. Udostępnia on interfejs API podobny do interfejsu HIDL HALandroid.hardware.graphics.composer@2.4 z tymi różnicami:

  • Usunięcie kolejki szybkich wiadomości (FMQ) na rzecz poleceń z możliwością dzielenia na części.

    Interfejs AIDL HAL definiuje interfejs poleceń na podstawie typów z silną kontrolą typów i typów możliwych do zapakowania, a nie serializowanych poleceń za pomocą FMQ w HIDL. Zapewnia to stabilny interfejs poleceń i czytelniejszą definicję sposobu interpretowania ich danych.

    Metoda executeCommands jest zdefiniowana w IComposerClient.aidljako

    CommandResultPayload[] executeCommands(in DisplayCommand[] commands);

    gdzie każda komenda jest silnie typowanym typem parcelable zdefiniowanym w DisplayCommand.aidl. Odpowiedzi na polecenia to obiekty Parcelable o ściśle określonym typie zdefiniowane w CommandResultPayload.aidl.

  • Usunięcie metody IComposerClient.getClientTargetSupport, ponieważ nie ma aktywnych klientów korzystających z tej metody.

  • Reprezentacja kolorów jako liczby zmiennoprzecinkowej z amiast bajtów, aby lepiej dopasować się do wyższego stosu graficznego w Androidzie zgodnie z definicją w ASurfaceTransaction_setColor.

  • Dodano nowe pola do zarządzania treściami HDR.

    W interfejsie AIDL HAL mieszane zestawy warstw SDR/HDR umożliwiają płynne przyciemnianie warstw SDR, gdy na ekranie wyświetlana jest warstwa HDR.

    Pole brightness w LayerCommand pozwala aplikacji SurfaceFlinger określić jasność dla poszczególnych warstw, dzięki czemu HWC przyciemnia zawartość warstwy w przestrzeni światła liniowego, a nie w przestrzeni gamma.

    Pole brightness w ClientTargetPropertyWithBrightness pozwala HWC określić przestrzeń jasności dla kompozycji klienta i zlecić RenderEngine, czy zaciemnić warstwy SDR w kompozycji klienta.

    Pole dimmingStage pozwala konfigurować HWC, kiedy RenderEngine ma przyciemniać treści. Umożliwia to stosowanie zdefiniowanych przez dostawcę ColorModes, które mogą przyciemniać w przestrzeni gamma, aby umożliwić ulepszenia kontrastu zdefiniowane przez dostawcę w ich ścieżkach kolorów.

  • Dodaliśmy nowy typ kompozycji DISPLAY_DECORATION w Composition.aidldo dekoracji ekranu.

    Niektóre urządzenia mają specjalny sprzęt do optymalizacji rysowania maski alfa, która wygładza zaokrąglone rogi i wycięcia na wyświetlaczach. Urządzenia z takim sprzętem muszą implementować IComposerClient.getDisplayDecorationSupport, aby zwracać strukturę DisplayDecorationSupport zgodnie z definicją w nowej DisplayDecorationSupport.aidl. Ta struktura opisuje enumeracje PixelFormat i AlphaInterpretationwymagane przez urządzenie. Po wprowadzeniu tej funkcji interfejs systemu oznacza warstwę maski alfa jako DISPLAY_DECORATION, czyli nowy typ kompozycji, który korzysta z dedykowanego sprzętu.

  • Dodano nowe pole expectedPresentTime do DisplayCommand.aidl.

    Pole expectedPresentTime pozwala narzędziu SurfaceFlinger określić oczekiwany czas wyświetlania treści na ekranie. Dzięki tej funkcji SurfaceFlinger wysyła do implementacji polecenie prezentowania z wyprzedzeniem, co pozwala mu przekazać więcej danych do tworzenia kompozycji.

  • Dodano nowe interfejsy API do sterowania konfiguracją wyświetlania ekranu uruchamiania.

    Korzystając z polecenia BOOT_DISPLAY_CONFIG, sprzedawcy mogą określić, że konfiguracja wyświetlacza rozruchu jest obsługiwana. Metody setBootDisplayConfig, clearBootDisplayConfig i getPreferredBootDisplayConfig używają wartości BOOT_DISPLAY_CONFIG w następujący sposób:

    • Korzystając z ustawień setBootDisplayConfig, platforma informuje dostawców o konfiguracji wyświetlania czasu rozruchu. Dostawcy muszą przechowywać w pamięci podręcznej konfigurację ekranu uruchamiania i uruchamiać się z tą konfiguracją przy następnym restarcie. Jeśli urządzenie nie może się uruchomić w tej konfiguracji, sprzedawca musi znaleźć konfigurację z odpowiednią rozdzielczością i częstotliwością odświeżania. Jeśli nie ma takiej konfiguracji, dostawca powinien użyć preferowanej konfiguracji wyświetlania.

    • Korzystając z clearBootDisplayConfig, platforma informuje dostawców o konieczności wyczyszczenia konfiguracji wyświetlacza rozruchu i uruchomieniu preferowanej konfiguracji wyświetlacza podczas następnego restartu.

    • Korzystając z getPreferredBootDisplayConfig, platforma wysyła zapytanie o preferowany tryb uruchamiania.

    Jeśli konfiguracja wyświetlacza podczas uruchamiania nie jest obsługiwana, te metody zwracają wartość UNSUPPORTED.

  • Dodano nowe interfejsy API do sterowania czasem bezczynności wyświetlacza.

    • Za pomocą atrybutu DISPLAY_IDLE_TIMER dostawcy mogą określić, że dla tego wyświetlacza zastosowano timer nieaktywności. Gdy urządzenie jest nieaktywne, ta funkcja zmienia częstotliwość odświeżania na niższą, aby oszczędzać energię. Platforma używa setIdleTimerEnabled do kontrolowania limitu czasu działania minutnika, a w niektórych przypadkach do jego wyłączenia, aby zapobiec niepożądanym zmianom częstotliwości odświeżania w czasie bezczynności.

    • Użycie wywołania zwrotnego IComposerCallback.onVsyncIdle wskazuje platformie, że wyświetlacz jest nieaktywny i że zmieniła się częstotliwość vsync. Platforma reaguje na ten wywołanie zwrotne przez zresetowanie modelu vsync. Wymusza ona vsync ponowne zsynchronizowanie na następnej klatce i uczy się nowej vsync kadencji.

Implementacja

Dostawcy nie muszą wdrażać interfejsu AIDL HAL w Androidzie 13. Zachęcamy jednak do implementacji interfejsu HAL kompozytora AIDL zamiast wersji HIDL, aby korzystać z nowych funkcji i interfejsów API.

Implementacja referencyjna interfejsu AIDL HWC HAL jest implementowana w emulatorach Androida.

Testowanie

Aby przetestować implementację, uruchom VtsHalGraphicsComposer3_TargetTest.