AIDL cho trình soạn nhạc phần cứng HAL

Kể từ Android 13, HAL của Trình soạn phần cứng (HWC) được xác định trong AIDL và các phiên bản HIDL từ android.hardware.graphics.composer@2.1 đến android.hardware.graphics.composer@2.4 không được dùng nữa.

Trang này mô tả sự khác biệt giữa AIDL và HIDL HAL cho HWC cũng như việc triển khai và thử nghiệm AIDL HAL.

Do những lợi thế mà AIDL mang lại, các nhà cung cấp được khuyến khích triển khai trình soạn thảo AIDL HAL bắt đầu từ Android 13 thay vì phiên bản HIDL. Xem phần Thực hiện để biết thêm thông tin.

Sự khác nhau giữa AIDL và HIDL HAL

Trình soạn thảo AIDL mới HAL, có tên android.hardware.graphics.composer3 , được định nghĩa trong IComposer.aidl . Nó hiển thị một API tương tự như HIDL HAL android.hardware.graphics.composer@2.4 với các thay đổi sau:

  • Loại bỏ Hàng đợi Tin nhắn Nhanh (FMQ) để ưu tiên cho các lệnh có thể chuyển đổi.

    AIDL HAL xác định giao diện lệnh dựa trên các loại có thể phân loại được gõ mạnh trái ngược với các lệnh được tuần tự hóa trên FMQ trong HIDL. Điều này cung cấp một giao diện ổn định cho các lệnh và định nghĩa dễ đọc hơn về cách diễn giải tải trọng lệnh.

    Phương thức executeCommands được định nghĩa trong IComposerClient.aidl

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

    trong đó mỗi lệnh là một loại có thể phân loại được gõ mạnh được xác định trong DisplayCommand.aidl . Phản hồi lệnh là các gói tin được nhập mạnh được xác định trong CommandResultPayload.aidl .

  • Xóa IComposerClient.getClientTargetSupport vì không có ứng dụng khách nào đang hoạt động cho phương thức này.

  • Biểu thị màu sắc dưới dạng float thay vì byte để căn chỉnh tốt hơn với ngăn xếp đồ họa phía trên trong Android như được định nghĩa trong ASurfaceTransaction_setColor .

  • Bổ sung các trường mới để kiểm soát nội dung HDR.

    Trong AIDL HAL, các ngăn xếp lớp SDR/HDR hỗn hợp hỗ trợ làm mờ liền mạch các lớp SDR khi một lớp HDR xuất hiện đồng thời trên màn hình.

    Trường brightness trong LayerCommand cho phép SurfaceFlinger chỉ định độ sáng cho mỗi lớp để HWC làm mờ nội dung của lớp trong không gian ánh sáng tuyến tính, trái ngược với không gian gamma.

    Trường brightness trong ClientTargetPropertyWithBrightness cho phép HWC chỉ định không gian độ sáng cho thành phần máy khách và hướng dẫn RenderEngine có nên làm mờ các lớp SDR trong thành phần máy khách hay không.

    Trường dimmingStage cho phép cấu hình HWC khi RenderEngine làm mờ nội dung. Điều này phù hợp với ColorModes do nhà cung cấp xác định, có thể thích làm mờ hơn trong không gian gamma, để cho phép cải tiến độ tương phản do nhà cung cấp xác định trong đường dẫn màu của họ.

  • Bổ sung loại bố cục mới DISPLAY_DECORATION trong Composition.aidl để trang trí màn hình.

    Một số thiết bị có phần cứng chuyên dụng để tối ưu hóa việc vẽ mặt nạ alpha giúp làm mịn các góc tròn và đường cắt trên màn hình. Các thiết bị có phần cứng như vậy phải triển khai IComposerClient.getDisplayDecorationSupport để trả về cấu trúc DisplayDecorationSupport như được xác định trong DisplayDecorationSupport.aidl mới. Cấu trúc này mô tả các enum PixelFormatAlphaInterpretation mà thiết bị yêu cầu. Khi triển khai này, Giao diện người dùng hệ thống đánh dấu lớp mặt nạ alpha là DISPLAY_DECORATION , một loại thành phần mới tận dụng lợi thế của phần cứng chuyên dụng.

  • Bổ sung một expectedPresentTime mới vào DisplayCommand.aidl .

    TrườngexpectedPresentTime cho phép SurfaceFlinger đặt thời gian hiện tại dự kiến ​​khi nội dung hiện tại phải được expectedPresentTime thị trên màn hình. Với tính năng này, SurfaceFlinger sẽ gửi một lệnh hiện tại tới quá trình triển khai trước thời hạn, cho phép nó thực hiện nhiều công việc sáng tác hơn.

  • Bổ sung các API mới để kiểm soát cấu hình hiển thị khởi động.

    Sử dụng BOOT_DISPLAY_CONFIG , nhà cung cấp có thể chỉ định rằng cấu hình hiển thị khởi động được hỗ trợ. Các phương thức setBootDisplayConfig , clearBootDisplayConfiggetPreferredBootDisplayConfig sử dụng BOOT_DISPLAY_CONFIG như sau:

    • Sử dụng setBootDisplayConfig , khung thông báo cho nhà cung cấp về cấu hình hiển thị thời gian khởi động. Nhà cung cấp phải lưu trữ trong cấu hình hiển thị khởi động và khởi động trong cấu hình này trong lần khởi động lại tiếp theo. Nếu thiết bị không thể khởi động trong cấu hình này, nhà cung cấp phải tìm một cấu hình phù hợp với độ phân giải và tốc độ làm mới của cấu hình này. Nếu không có cấu hình như vậy tồn tại, nhà cung cấp nên sử dụng cấu hình hiển thị ưa thích của họ.

    • Sử dụng clearBootDisplayConfig , khung thông báo cho nhà cung cấp xóa cấu hình hiển thị khởi động và khởi động ở cấu hình hiển thị ưa thích của họ trong lần khởi động lại tiếp theo.

    • Sử dụng getPreferredBootDisplayConfig , khung truy vấn chế độ khởi động ưa thích của nhà cung cấp.

    Khi cấu hình hiển thị khởi động không được hỗ trợ, các phương thức này trả về giá trị UNSUPPORTED .

  • Bổ sung các API mới để kiểm soát bộ đếm thời gian chờ hiển thị.

    • Sử dụng DISPLAY_IDLE_TIMER , nhà cung cấp có thể chỉ định rằng bộ hẹn giờ không hoạt động được nhà cung cấp triển khai cho màn hình này. Khi không hoạt động, khả năng này sẽ thay đổi tốc độ làm mới thành cài đặt thấp hơn để tiết kiệm năng lượng. Nền tảng sử dụng setIdleTimerEnabled để kiểm soát thời gian chờ của bộ hẹn giờ và trong một số trường hợp, để tắt nó nhằm ngăn các chuyển đổi tốc độ làm mới không mong muốn khi không hoạt động.

    • Việc sử dụng lệnh gọi lại IComposerCallback.onVsyncIdle cho nền tảng biết rằng màn hình đang ở chế độ chờ và nhịp vsync đã thay đổi. Nền tảng phản hồi cuộc gọi lại này bằng cách đặt lại mô hình vsync của nó. Nó buộc đồng bộ lại vsync trên khung hình tiếp theo và tìm hiểu nhịp vsync mới.

Thực hiện

Các nhà cung cấp không bắt buộc phải triển khai AIDL HAL cho Android 13. Tuy nhiên, họ được khuyến khích triển khai AIDL composer HAL thay vì phiên bản HIDL để sử dụng chức năng và API mới.

Triển khai tham chiếu cho AIDL HWC HAL được triển khai trong trình giả lập Android.

thử nghiệm

Để kiểm tra triển khai của bạn, hãy chạy VtsHalGraphicsComposer3_TargetTest .