Android-x86
Fork
捐款

  • R/O
  • HTTP
  • SSH
  • HTTPS

external-drmfb-composer: 儲存庫摘要

external/drmfb-composer


最新提交 RSS

修訂. 時間 作者 訊息
1897fd6 2021-04-11 04:07:51 Mauro Rossi r-x86 Link against android.hardware.graphics.composer@2.1-resou...
1eac35e 2021-04-11 04:04:56 Mauro Rossi Link against android.hardware.graphics.mapper@4.0
cd13934 2020-05-16 18:49:58 Mauro Rossi q-x86 Merge remote-tracking branch 'goffioul/master'
1ebf97d 2019-10-10 02:51:07 Michael Goffioul Add CAP_NET_ADMIN capability This is required to use uev...
2b29f0e 2019-10-10 00:58:16 Michael Goffioul Always enable vsync thread when requested by surfacefling...
d38f15c 2019-10-10 00:56:55 Michael Goffioul Link against android.hardware.graphics.mapper@3.0
f53f172 2019-06-10 07:26:46 Mauro Rossi pie-x86 disable drmfb-composer service by default In order to st...
9084741 2019-05-08 19:12:13 lambdadroid Android.mk: Allow setting a custom minigbm path
8f89cef 2019-04-21 21:56:24 lambdadroid sepolicy: Add simple sepolicy for drmfb-composer
d82ffb9 2019-01-17 03:10:39 lambdadroid Avoid logging handlePageFlip() warning after disconnect ...

分支

名稱 修訂. 時間 作者 訊息
r-x86 1897fd6 2021-04-11 04:07:51 Mauro Rossi Link against android.hardwa...
q-x86 cd13934 2020-05-16 18:49:58 Mauro Rossi Merge remote-tracking branc...
pie-x86 f53f172 2019-06-10 07:26:46 Mauro Rossi disable drmfb-composer serv...

README.md

drmfb-composer

drmfb-composer is a simple HIDL HAL implementation of [android.hardware.graphics.composer@2.1] using Linux DRM legacy Kernel Mode Setting. It specifically does not make use of Atomic Mode Setting to support older hardware and kernels.

Note: For newer devices with stable Atomic Mode Setting support, prefer using drm_hwcomposer. It is a more complete implementation that can offload parts of the composition from the GPU to hardware. (See Comparison to drm_hwcomposer)

Introduction

drmfb-composer is mostly a proof of concept: it is a Graphics Composer HAL that works very much like the old Framebuffer (FB) HALs. This allows implementing additional features like multiple display support, while still supporting all old hardware.

The main difference from implementations like drm_hwcomposer is that it does not do any composition in hardware. It only handles displaying the results of client (GPU) composition in SurfaceFlinger using Kernel Mode Setting. That makes it less efficient, but avoids use of Atomic Mode Setting and multiple planes that sometimes cause issues on older hardware.

It has also turned out to be a great learning experience, especially to understand which features are supposed to be provided by a Graphics Composer HAL, and how they can be implemented using DRM/KMS.

Features

  • Multiple displays and hotplug
    • Note: Although not limited in the Composer HAL, the current Android framework limits this to:
    • Only two displays working at the same time (one primary and one external)
    • Hotplugging the first (primary) display will result in crashes
  • Exposes all available displays modes (e.g. possible lower resolutions or refresh rates)
  • Hardware vertical sync (VSYNC) signals

Comparison to drm_hwcomposer (HWC2 HAL)

drm_hwcomposer is a more complete and efficient implementation of a HWC2 HAL implemented using Atomic Mode Setting. However, it does not run on older hardware without Atomic Mode Setting (e.g. radeon) in the kernel.

Features missing in drmfb-composer

Features missing in drm_hwcomposer

These are features that I would like to port to drm_hwcomposer eventually. (Still working on getting drm_hwcomposer working on my primary test device.)

Comparison to drm_gralloc (FB HAL)

drm_gralloc was one of the first Gralloc HAL implementations for DRM and used to implement a Framebuffer HAL that is still being used in Android-x86 today. drmfb-composer has a couple of advantages compared to drm_gralloc:

  • Modern implementation of a Graphics Composer HAL instead of a legacy FB HAL
  • PRIME file descriptors instead of GEM names
  • Works fully binderized and with DRM GPU authentication enabled
  • Multiple display support with different content instead of only screen mirroring

Comparison to drm_framebuffer (FB HAL)

drm_framebuffer was an earlier version of drmfb-composer implemented as a Framebuffer HAL (FB HAL). Implementing a proper Graphics Composer HAL has a couple of advantages:

  • Modern implementation of a Graphics Composer HAL instead of a legacy FB HAL
  • No need for changes in the Gralloc HAL (drm_framebuffer was a static library that required changes in the Gralloc HAL)
  • Supports both libdrm gralloc handle and minigbm at the same time (detected at runtime)
  • Multiple display support, hotplug and screen mirroring (by default extra screens are mirrored)

Requirements

  • Linux kernel with a GPU supported by DRM (e.g. i915, radeon, ...)
  • Android 9 (Pie) or newer
    • Necessary for properly working multiple display support and hotplugging
    • android.hardware.graphics.composer@2.1-hal (a header library drmfb-composer is built on) does not exist on previous Android versions
  • Gralloc HAL: libdrm gralloc handle compatible (e.g. gbm_gralloc) or minigbm (detected at runtime)

Usage

Add drmfb-composer to your Android build tree and build android.hardware.graphics.composer@2.1-service.drmfb.

drmfb-composer is a binderized HIDL HAL service. Ensure that the binary and init file is pushed to your device: - /vendor/bin/hw/android.hardware.graphics.composer@2.1-service.drmfb - /vendor/etc/init/android.hardware.graphics.composer@2.1-service.drmfb.rc

SELinux Policy

sepolicy contains a simple SELinux Policy definition for drmfb-composer. You can include it in the build by adding the directory to BOARD_SEPOLICY_DIRS.

License

drmfb-composer is licensed under the Apache License, Version 2.0. Contributions welcome!

Show on old repository browser