AIDL dla Hardware Composer HAL

Począwszy od Androida 13, HAL Hardware Composer (HWC) jest zdefiniowany w AIDL , a wersje HIDL od android.hardware.graphics.composer@2.1 do android.hardware.graphics.composer@2.4 są przestarzałe.

Ta strona opisuje różnice między AIDL i HIDL HAL dla HWC oraz implementację i testowanie AIDL HAL.

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

Różnice między AIDL i HIDL HAL

Nowa warstwa HAL kompozytora AIDL o nazwie android.hardware.graphics.composer3 jest zdefiniowana w IComposer.aidl . Udostępnia API podobne do HIDL HAL android.hardware.graphics.composer@2.4 z następującymi zmianami:

  • Usunięcie kolejki Fast Message Queue (FMQ) na rzecz poleceń paczkowalnych.

    AIDL HAL definiuje interfejs poleceń oparty na silnie typowanych typach pakowalnych, w przeciwieństwie do serializowanych poleceń przez FMQ w HIDL. Zapewnia to stabilny interfejs dla poleceń i bardziej czytelną definicję interpretacji ładunku polecenia.

    Metoda executeCommands jest zdefiniowana w IComposerClient.aidl jako

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

    gdzie każde polecenie jest silnie wpisanym typem paczki, zdefiniowanym w DisplayCommand.aidl . Odpowiedzi na polecenia to silnie wpisane elementy typu parcelables zdefiniowane w CommandResultPayload.aidl .

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

  • Reprezentacja kolorów jako elementów 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 zawartości HDR.

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

    Pole brightness w LayerCommand pozwala SurfaceFlinger określić jasność dla poszczególnych warstw, dzięki czemu HWC przyciemnia zawartość warstwy w liniowej przestrzeni światła, w przeciwieństwie do przestrzeni gamma.

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

    Pole dimmingStage pozwala HWC skonfigurować, kiedy RenderEngine ma przyciemniać zawartość. To uwzględnia 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 do dekoracji ekranu.

    Niektóre urządzenia mają dedykowany 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 nowym DisplayDecorationSupport.aidl . Ta struktura opisuje wyliczenia PixelFormat i AlphaInterpretation wymagane przez urządzenie. Po tej implementacji systemowy interfejs użytkownika 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 SurfaceFlinger ustawić oczekiwany czas obecny, kiedy bieżąca zawartość musi zostać wyświetlona na ekranie. Dzięki tej funkcji SurfaceFlinger wysyła aktualne polecenie do implementacji z wyprzedzeniem, umożliwiając jej potokowanie większej ilości pracy nad kompozycją.

  • Dodanie nowych interfejsów API do sterowania konfiguracją ekranu startowego.

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

    • Za pomocą setBootDisplayConfig platforma informuje dostawców o konfiguracji wyświetlania czasu rozruchu. Dostawcy muszą przechowywać w pamięci podręcznej konfigurację wyświetlacza rozruchowego i uruchamiać w tej konfiguracji przy następnym uruchomieniu. Jeśli urządzenie nie może się uruchomić w tej konfiguracji, dostawca musi znaleźć konfigurację, która odpowiada rozdzielczości i częstotliwości odświeżania tej konfiguracji. Jeśli taka konfiguracja nie istnieje, dostawca powinien użyć preferowanej konfiguracji wyświetlania.

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

    • Używając getPreferredBootDisplayConfig , struktura wysyła zapytanie o preferowany tryb rozruchu dostawcy.

    Gdy konfiguracja ekranu rozruchowego nie jest obsługiwana, te metody 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 licznik czasu braku aktywności jest zaimplementowany przez dostawcę dla tego wyświetlacza. W stanie bezczynności ta funkcja zmienia częstotliwość odświeżania na niższą, aby oszczędzać energię. Platforma używa setIdleTimerEnabled do kontrolowania limitu czasu timera, aw niektórych przypadkach do wyłączania go, 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, a rytm vsync uległ zmianie. 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 muszą implementować AIDL HAL dla Androida 13. Jednak zachęca się ich do implementacji AIDL Composer HAL zamiast wersji HIDL w celu korzystania 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 .