AIDL dla interfejsu HAL usługi Hardware Composer

Od Androida 13 interfejs Hardware Composer (HWC) HAL jest zdefiniowany w AIDL. Wersje HIDL od android.hardware.graphics.composer@2.1 do android.hardware.graphics.composer@2.4 są wycofane.

Na tej stronie opisujemy różnice między interfejsami AIDL i HIDL HAL dla HWC oraz sposób implementacji i testowania interfejsu AIDL HAL.

AIDL ma wiele zalet, dlatego dostawcy mogą implementować interfejs AIDL HAL kompozytora od Androida 13 zamiast wersji HIDL. Więcej informacji znajdziesz w sekcji Implementacja.

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

Nowy interfejs AIDL HAL o nazwie android.hardware.graphics.composer3 jest zdefiniowany w IComposer.aidl. Interfejs API jest podobny do interfejsu HIDL HAL android.hardware.graphics.composer@2.4, ale zawiera te zmiany:

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

    Interfejs AIDL HAL definiuje interfejs poleceń na podstawie silnie typowanych typów parcelable zamiast serializowanych poleceń w HIDL. Zapewnia to stabilny interfejs poleceń i bardziej czytelną definicję sposobu, w jaki system interpretuje ładunek polecenia.

    Metoda executeCommands 5 jest zdefiniowana w IComposerClient.aidl:

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

    Każde polecenie jest silnie typowanym typem parcelable zdefiniowanym w DisplayCommand.aidl. Odpowiedzi na polecenia to silnie typowane typy parcelable zdefiniowane w CommandResultPayload.aidl.

  • Usunięcie IComposerClient.getClientTargetSupport, ponieważ żaden aktywny klient nie używa tej metody.

  • Reprezentacja kolorów jako liczb zmiennoprzecinkowych zamiast bajtów, aby dopasować się do górnej części stosu graficznego w Androidzie, zgodnie z definicją ASurfaceTransaction_setColor.

  • Dodanie nowych pól do sterowania treściami HDR.

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

    Pole brightness w LayerCommand umożliwia SurfaceFlinger określenie jasności poszczególnych warstw. Dzięki temu HWC może przyciemniać zawartość warstwy w liniowej przestrzeni kolorów zamiast w przestrzeni gamma.

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

    Pole dimmingStage umożliwia HWC skonfigurowanie, kiedy RenderEngine ma przyciemniać treści. Umożliwia to obsługę zdefiniowanych przez dostawcę ColorModes, które mogą preferować przyciemnianie w przestrzeni gamma, aby włączyć zdefiniowane przez dostawcę ulepszenia kontrastu w swoich potokach kolorów.

  • Dodanie typu kompozycji DISPLAY_DECORATION w Composition.aidl do 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 i zwracać strukturę DisplayDecorationSupport zdefiniowaną w DisplayDecorationSupport.aidl. Ta struktura opisuje wyliczenia PixelFormat i AlphaInterpretation wymagane przez urządzenie. Po tej implementacji interfejs systemowy UI oznacza warstwę maski alfa jako DISPLAY_DECORATION, czyli typ kompozycji, który wykorzystuje specjalny sprzęt.

  • Dodanie pola expectedPresentTime do DisplayCommand.aidl.

    Pole expectedPresentTime umożliwia SurfaceFlinger ustawienie oczekiwanego czasu wyświetlania bieżącej treści na ekranie. Dzięki tej funkcji SurfaceFlinger wysyła polecenie wyświetlania do implementacji z wyprzedzeniem, co pozwala na potokowe przetwarzanie większej części pracy związanej z kompozycją.

  • Dodanie nowych interfejsów API do sterowania konfiguracją wyświetlacza podczas uruchamiania.

    Za pomocą BOOT_DISPLAY_CONFIG dostawcy mogą określić, że konfiguracja wyświetlacza podczas uruchamiania jest obsługiwana. Metody setBootDisplayConfig, clearBootDisplayConfig i getPreferredBootDisplayConfig używają BOOT_DISPLAY_CONFIG w ten sposób:

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

    • Za pomocą clearBootDisplayConfig platforma informuje dostawców aby wyczyścili konfigurację wyświetlacza podczas uruchamiania i uruchomili urządzenie w preferowanej konfiguracji wyświetlacza podczas następnego ponownego uruchomienia.

    • Za pomocą getPreferredBootDisplayConfig platforma wysyła zapytanie o preferowany tryb uruchamiania dostawcy.

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

  • Dodanie nowych interfejsów API do sterowania licznikiem czasu bezczynności wyświetlacza:

    • Za pomocą DISPLAY_IDLE_TIMER dostawcy mogą określić, że licznik czasu bezczynności jest implementowany przez dostawcę dla tego wyświetlacza. Gdy urządzenie jest bezczynne, ta funkcja zmienia częstotliwość odświeżania na niższą, aby oszczędzać energię. Platforma używa setIdleTimerEnabled do sterowania czasem oczekiwania licznika czasu, a w niektórych przypadkach do jego wyłączania, aby zapobiec niepożądanym zmianom częstotliwości odświeżania, gdy urządzenie jest bezczynne.

    • Użycie wywołania zwrotnego IComposerCallback.onVsyncIdle informuje platformę, że wyświetlacz jest bezczynny i zmieniła się częstotliwość vsync. Platforma odpowiada na to wywołanie zwrotne, resetując model vsync. Wymusza ponowną synchronizację vsync w następnej klatce i uczy się nowej vsync częstotliwości.

Implementacja

Dostawcy nie muszą implementować interfejsu AIDL HAL w Androidzie 13. Zachęcamy jednak do implementowania interfejsu AIDL HAL zamiast wersji HIDL, aby korzystać z funkcji i interfejsów API interfejsu AIDL HAL.

Emulatory Androida zawierają implementację referencyjną interfejsu AIDL HWC HAL.

Testowanie

Aby przetestować implementację, uruchom VtsHalGraphicsComposer3_TargetTest.