AIDL dla Hardware Composer HAL

Począwszy od systemu Android 13, warstwa HAL narzędzia Hardware Composer (HWC) jest zdefiniowana w formacie AIDL , a wersje HIDL od android.hardware.graphics.composer@2.1 do android.hardware.graphics.composer@2.4 są przestarzałe.

Na tej stronie opisano różnice między AIDL i HIDL HAL dla HWC oraz wdrażanie i testowanie AIDL HAL.

Ze względu na zalety oferowane przez AIDL zachęca się dostawców do implementowania kompozytora AIDL HAL począwszy od Androida 13 zamiast wersji HIDL. Aby uzyskać więcej informacji, zobacz sekcję Implementacja .

Różnice pomiędzy AIDL i HIDL HAL

Nowy kompozytor AIDL HAL, nazwany android.hardware.graphics.composer3 , jest zdefiniowany w IComposer.aidl . Udostępnia interfejs API podobny do HIDL HAL android.hardware.graphics.composer@2.4 z następującymi zmianami:

  • Usunięcie szybkiej kolejki komunikatów (FMQ) na rzecz poleceń umożliwiających pakowanie.

    AIDL HAL definiuje interfejs poleceń w oparciu o typy z możliwością dzielenia na typy, w przeciwieństwie do poleceń serializowanych przez FMQ w HIDL. Zapewnia to stabilny interfejs dla poleceń i bardziej czytelną definicję sposobu interpretacji ładunku polecenia.

    Metoda executeCommands jest zdefiniowana w IComposerClient.aidl jako

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

    gdzie każde polecenie jest typem o jednoznacznie określonym typie, zdefiniowanym w DisplayCommand.aidl . Odpowiedzi na polecenia to pakiety o jednoznacznie określonym typie zdefiniowane w CommandResultPayload.aidl .

  • Usunięcie IComposerClient.getClientTargetSupport , ponieważ nie ma aktywnych klientów dla tej metody.

  • Reprezentacja kolorów jako zmiennoprzecinkowych zamiast bajtów w celu lepszego dopasowania do górnego stosu grafiki w systemie Android zgodnie z definicją w ASurfaceTransaction_setColor .

  • Dodanie nowych pól do kontrolowania treści HDR.

    W AIDL HAL mieszane stosy warstw SDR/HDR obsługują płynne przyciemnianie warstw SDR, gdy warstwa HDR jest jednocześnie na ekranie.

    Pole brightness w LayerCommand pozwala SurfaceFlingerowi określić jasność każdej warstwy, dzięki czemu HWC przyciemnia zawartość warstwy w liniowej przestrzeni światła, a nie w przestrzeni gamma.

    Pole brightness w ClientTargetPropertyWithBrightness umożliwia HWC określenie przestrzeni jasności dla kompozycji klienta i poinstruowanie RenderEngine , czy przyciemnić warstwy SDR w kompozycji klienta.

    Pole dimmingStage umożliwia HWC skonfigurowanie, kiedy RenderEngine powinien przyciemniać zawartość. Uwzględnia to zdefiniowane przez dostawcę ColorModes , które mogą preferować przyciemnianie w przestrzeni gamma, aby umożliwić zdefiniowane przez dostawcę ulepszenia kontrastu w ich potokach kolorów.

  • Dodanie nowego typu kompozycji DISPLAY_DECORATION w Composition.aidl dla dekoracji ekranu.

    Niektóre urządzenia mają dedykowany sprzęt optymalizujący rysowanie 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 zwrócić strukturę DisplayDecorationSupport zdefiniowaną w nowym DisplayDecorationSupport.aidl . Ta struktura opisuje wyliczenia PixelFormat i AlphaInterpretation wymagane przez urządzenie. Po tej implementacji interfejs użytkownika systemu oznacza warstwę maski alfa jako DISPLAY_DECORATION , nowy typ kompozycji wykorzystujący dedykowany sprzęt.

  • Dodanie nowego pola expectedPresentTime do DisplayCommand.aidl .

    Pole expectedPresentTime pozwala SurfaceFlingerowi ustawić oczekiwany czas obecny, kiedy bieżąca zawartość musi zostać wyświetlona na ekranie. Dzięki tej funkcji SurfaceFlinger z wyprzedzeniem wysyła obecne polecenie do implementacji, co pozwala mu potokować większą część pracy nad kompozycją.

  • Dodanie nowych interfejsów API do kontrolowania konfiguracji wyświetlania rozruchowego.

    Używając BOOT_DISPLAY_CONFIG , dostawcy mogą określić, czy obsługiwana jest konfiguracja wyświetlacza rozruchowego. Metody setBootDisplayConfig , clearBootDisplayConfig i getPreferredBootDisplayConfig korzystają z BOOT_DISPLAY_CONFIG w następujący sposób:

    • Korzystając z setBootDisplayConfig , platforma informuje dostawców o konfiguracji wyświetlania czasu rozruchu. Dostawcy muszą buforować w konfiguracji wyświetlacza rozruchowego i uruchamiać się w tej konfiguracji przy następnym uruchomieniu. Jeśli urządzenie nie może uruchomić się w tej konfiguracji, sprzedawca musi znaleźć konfigurację odpowiadającą rozdzielczości i częstotliwości odświeżania tej konfiguracji. Jeśli taka konfiguracja nie istnieje, sprzedawca powinien użyć preferowanej konfiguracji wyświetlacza.

    • Używając clearBootDisplayConfig , platforma informuje dostawców, aby wyczyścili konfigurację wyświetlania rozruchowego i uruchomili się w preferowanej konfiguracji wyświetlania podczas następnego ponownego uruchomienia.

    • Używając getPreferredBootDisplayConfig , platforma wysyła zapytanie o preferowany przez dostawcę tryb rozruchu.

    Jeśli konfiguracja ekranu rozruchowego nie jest obsługiwana, metody te zwracają wartość UNSUPPORTED .

  • Dodanie nowych interfejsów API do kontrolowania licznika czasu bezczynności wyświetlacza.

    • Używając DISPLAY_IDLE_TIMER , dostawcy mogą określić, że sprzedawca zaimplementował licznik czasu bezczynności dla tego wyświetlacza. W stanie bezczynności funkcja ta zmienia częstotliwość odświeżania na niższą, aby oszczędzać energię. Platforma wykorzystuje setIdleTimerEnabled do kontrolowania limitu czasu timera, a w niektórych przypadkach do jego wyłączania, aby zapobiec niepożądanym zmianom częstotliwości odświeżania w stanie bezczynności.

    • Użycie wywołania zwrotnego IComposerCallback.onVsyncIdle wskazuje platformie, że wyświetlacz jest bezczynny i zmieniła się kadencja vsync . Platforma odpowiada na to wywołanie zwrotne, resetując swój model vsync . Wymusza ponowną synchronizację vsync w następnej klatce i uczy się nowej kadencji vsync .

Realizacja

Dostawcy nie są zobowiązani do implementowania AIDL HAL dla Androida 13. Zachęcamy ich jednak do implementowania AIDL Composer HAL zamiast wersji HIDL, aby móc korzystać z nowych funkcji i interfejsów API.

Implementacja referencyjna dla AIDL HWC HAL jest zaimplementowana w emulatorach Androida.

Testowanie

Aby przetestować implementację, uruchom VtsHalGraphicsComposer3_TargetTest .