AIDL dla interfejsu HAL usługi Hardware Composer

Od Androida 13 interfejs HAL kompozytora sprzętowego (HWC) 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 HAL AIDL i HIDL dla HWC oraz sposób implementacji i testowania interfejsu HAL AIDL.

Ze względu na zalety AIDL dostawcy mogą implementować AIDL HAL kompozytora od Androida 13 zamiast wersji HIDL. Więcej informacji znajdziesz w sekcji Implementacja.

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

Nowy interfejs HAL kompozytora AIDL o nazwie android.hardware.graphics.composer3 jest zdefiniowany w pliku IComposer.aidl. Interfejs API jest podobny do HIDL HAL android.hardware.graphics.composer@2.4, ale zawiera następujące zmiany:

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

  AIDL HAL definiuje interfejs poleceń na podstawie silnie typizowanych typów możliwych do przekazania, a nie serializowanych poleceń w FMQ 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 typizowanym typem możliwym do przekazania w pakiecie, zdefiniowanym w pliku DisplayCommand.aidl. Odpowiedzi na polecenia są silnie typizowanymi obiektami Parcelable zdefiniowanymi 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ć je do górnej warstwy graficznej w Androidzie, zgodnie z definicją w ASurfaceTransaction_setColor.

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

  W 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 SurfaceFlingerowi określenie jasności poszczególnych warstw. Umożliwia to HWC przyciemnianie zawartości warstwy w przestrzeni światła liniowego zamiast w przestrzeni gamma.

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

  Pole dimmingStage umożliwia HWC skonfigurowanie, kiedy RenderEngine przyciemnia treści. Umożliwia to dostosowanie do zdefiniowanych przez dostawcę ColorModes ustawień, 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ą specjalne komponenty, które optymalizują rysowanie maski alfa, wygładzając 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 systemu oznaczy warstwę maski alfa jako DISPLAY_DECORATION, czyli typ kompozycji, który wykorzystuje dedykowany sprzęt.

• Dodanie pola expectedPresentTime do DisplayCommand.aidl.

  Pole expectedPresentTime umożliwia usłudze SurfaceFlinger ustawienie oczekiwanego czasu wyświetlania, w którym bieżąca treść musi być wyświetlana na ekranie. Dzięki tej funkcji SurfaceFlinger wysyła polecenie prezentacji do implementacji z wyprzedzeniem, co pozwala na bardziej efektywne przetwarzanie kompozycji.

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

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

  • Za pomocą setBootDisplayConfig platforma informuje dostawców o konfiguracji wyświetlania czasu uruchomienia. Dostawcy muszą zapisywać w pamięci podręcznej konfigurację wyświetlacza rozruchowego i przy następnym ponownym uruchomieniu używać tej konfiguracji. 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 musi użyć preferowanej konfiguracji wyświetlania.

  • Za pomocą clearBootDisplayConfig platforma informuje dostawców, aby wyczyścili konfigurację wyświetlania podczas uruchamiania i przy następnym ponownym uruchomieniu włączyli preferowaną konfigurację wyświetlania.

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

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

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

  • Za pomocą wartości DISPLAY_IDLE_TIMER dostawcy mogą określić, że w przypadku tego wyświetlacza dostawca wdrożył licznik czasu bezczynności. Gdy urządzenie jest nieaktywne, ta funkcja zmniejsza częstotliwość odświeżania, aby oszczędzać energię. Platforma używa 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 trybie bezczynności.

  • Użycie wywołania zwrotnego IComposerCallback.onVsyncIdle informuje platformę, że wyświetlacz jest nieaktywny, a częstotliwość vsync uległa zmianie. Platforma odpowiada na to wywołanie zwrotne, resetując swój vsyncmodel. Wymusza vsync ponowną synchronizację w następnej klatce i uczy się nowej vsync kadencji.

Implementacja

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

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

Testowanie

Aby przetestować implementację, uruchom VtsHalGraphicsComposer3_TargetTest.