AIDL dla HAL Hardware Composer

Począwszy od Androida 13 interfejs 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 zostały 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 implementować kompozytora HAL AIDL od wersji Android 13 zamiast wersji HIDL. Więcej informacji znajdziesz w sekcji Wdrażanie.

Różnice między 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 silnie wpisywanych typów papierowych w przeciwieństwie do poleceń serializowanych nad FMQ w HIDL. Zapewnia to stabilny interfejs poleceń i bardziej czytelną definicję sposobu interpretacji ładunku poleceń.

    Metoda executeCommands jest zdefiniowana w IComposerClient.aidljako

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

    gdzie każda komenda jest silnie typowanym typem pakietowym zdefiniowanym w DisplayCommand.aidl. Odpowiedzi poleceń to polecenia Parcelable o silnym typie zdefiniowane w narzędziu CommandResultPayload.aidl.

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

  • Przedstawienie kolorów w postaci liczby zmiennoprzecinkowej, a nie bajtów, aby lepiej dopasować je do górnego stosu graficznego na Androidzie, zgodnie z definicją podaną w zasadzie ASurfaceTransaction_setColor.

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

    W AIDL HAL mieszane stosy warstw SDR/HDR obsługują płynne przyciemnianie warstw SDR, gdy na ekranie jest jednocześnie 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 światła 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 HWC skonfigurować, kiedy RenderEngine ma przyciemnić treści. Umożliwia to korzystanie z zdefiniowanych przez dostawcę metod ColorModes, które mogą preferować przyciemnienie w przestrzeni gamma, aby umożliwić określone przez dostawcę ulepszenia kontrastu w strumieniach kolorów.

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

    Niektóre urządzenia mają specjalny sprzęt, który optymalizuje rysowanie maski alfa, która wygładza zaokrąglone rogi i wycięcia na wyświetlaczu. Urządzenia z takim sprzętem muszą implementować IComposerClient.getDisplayDecorationSupport, aby zwracać strukturę DisplayDecorationSupport zgodnie z definicją w nowej DisplayDecorationSupport.aidl. Ta struktura opisuje enumy PixelFormat i AlphaInterpretationwymagane przez urządzenie. W ramach tej implementacji interfejs systemu oznacza warstwę maski alfa jako DISPLAY_DECORATION, czyli nowy typ kompozycji, który korzysta ze specjalnego 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 obecne polecenie do implementacji z wyprzedzeniem, co pozwala na potokowanie większej ilości treści.

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

    Korzystając z parametru BOOT_DISPLAY_CONFIG, dostawcy mogą określić, że obsługują konfigurację wyświetlacza rozruchu. Metody setBootDisplayConfig, clearBootDisplayConfig i getPreferredBootDisplayConfig używają BOOT_DISPLAY_CONFIG w następujący sposób:

    • Dzięki setBootDisplayConfig platforma informuje dostawców o konfiguracji wyświetlania czasu uruchamiania. Dostawcy muszą przechowywać w pamięci podręcznej konfigurację ekranu uruchamiania i uruchamiać się z tą konfiguracją przy następnym ponownym uruchomieniu. 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.

    • Dzięki clearBootDisplayConfig platforma informuje dostawców, że powinni wyczyścić konfigurację wyświetlacza rozruchowego i uruchomić urządzenie w preferowanej przez siebie konfiguracji ekranu podczas następnego ponownego uruchamiania.

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

    Jeśli konfiguracja wyświetlania przy rozruchu 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ą wskazać, że licznik braku aktywności dla tego wyświetlacza ma być zaimplementowany przez niego. 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 czasu oczekiwania licznika, a w niektórych przypadkach do jego wyłączenia, aby zapobiec niepożądanym zmianom częstotliwości odświeżania podczas 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 są zobowiązani do wdrażania interfejsu AIDL HAL w Androidzie 13. Zachęcamy jednak do wdrożenia kodu HAL kompozytora AIDL zamiast wersji HIDL. Pozwoli to korzystać z nowych funkcji i interfejsów API.

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

Testowanie

Aby przetestować implementację, uruchom narzędzie VtsHalGraphicsComposer3_TargetTest.