android display框架分析.docVIP

Android display架构分析（一） 2010-04-16 10:41 高通7系列硬件架构分析 如上图，高通7系列 Display的硬件部分主要由下面几个部分组成： A、MDP 高通MSM7200A内部模块，主要负责显示数据的转换和部分图像处理功能理，如YUV转RGB，放大缩小、旋转等。MDP内部的MDP DMA负责数据从DDR到MDDI Host的传输（可以完成RGB之间的转换，如RGB565转成RGB666，这个转换工能载目前的code 中没有使用）。 B、MDDI 一种采用差分信号的高速的串行数据传输总线，只负责数据传输，无其它功能；其中的MDDI Hosat提供并行数据和串行数据之间的转换和缓冲功能。由于外面是VGA的屏幕，数据量较大，为了减少对EBI2总线的影响，传输总线使用MDDI，而非之前的EBI2。 C、MDDI Bridge 由于现在采用的外接LCD并不支持MDDI接口，故需要外加MDDI转换器，即MDDI bridge，来把MDDI数据转换成RGB接口数据。这里采用的EPSON MDDIBridge还有LCD Controller功能，可以完成其它一些数据处理的功能，如数据格式转换、支持TV-OUT、PIP等；并且还可以提供一定数量的GPIO。目前我们主要用它把HOST端MDDI传递过来的显示数据和控制数据（初始化配置等）转换成并行的数据传递给LCD。 D、LCD module 主要是LCD Driver IC 和TFT Panel，负责把MDDI Bridge传来的显存中的图像示在自己的 Panel上。 Android display架构分析（二） 2010-04-16 10:45 Android display SW架构分析 下面简单介绍一下上图中的各个Layer： *蓝色部分－用户空间应用程序 应用程序层，其中包括Android应用程序以及框架和系统运行库，和底层相关的是系统运行库，而其中和显示相关的就是Android的Surface Manager, 它负责对显示子系统的管理，并且为多个应用程序提 供了2D和3D图层的无缝融合。 *黑色部分－HAL层，在2.2.1部分会有介绍 *红色部分－Linux kernel层 Linux kernel，其中和显示部分相关的就是Linux的FrameBuffer，它是Linux系统中的显示部分驱动程序接口。Linux工作在保护模式下，User空间的应用程序无法直接调用显卡的驱动程序来直接画屏，FrameBuffer机制模仿显卡的功能，将显卡硬件结构抽象掉，可以通过 Framebuffer的读写直接对显存进行操作。用户可以将Framebuffer看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以直接进行读写操作，而写操作可以立即反应在屏幕上。这种操作是抽象的，统一的。用户不必关心物理显存的位置、换页机制等等具体细节。这些都是由 Framebuffer设备驱动来完成的。 *绿色部分－HW驱动层 该部分可以看作高通显卡的驱动程序，和高通显示部分硬件相关以及外围LCD相关的驱动都被定义在这边，比如上述的显卡的一些特性都是在这边被初始化的，同样MDP和MDDI相关的驱动也都定义在这里 ???? ???? User Space Display功能介绍 这里的User Space就是与应用程序相关的上层部分（参考上图中的蓝色部分），其中与Kernel空间交互的部分称之为HAL－HW Abstraction Layer。 HAL其实就是用户空间的驱动程序。如果想要将 Android 在某硬件平台上执行，基本上完成这些驱动程序就行了。其内定义了 Android 对各硬件装置例如显示芯片、声音、数字相机、GPS、GSM 等等的需求。 HAL存在的几个原因： 1、 并不是所有的硬件设备都有标准的linux kernel的接口。 2、 Kernel driver涉及到GPL的版权。某些设备制造商并不原因公开硬件驱动，所以才去HAL方式绕过GPL。 3、 针对某些硬件，Android有一些特殊的需求。 在display部分，HAL的实现code在copybit.c中，应用程序直接操作这些接口即可，具体的接口如下： struct copybit_context_t *ctx = malloc(sizeof(struct copybit_context_t)); memset(ctx, 0, sizeof(*ctx)); ctx-mon.tag = HARDWARE_DEVICE_TAG; ctx-mon.version = 0; ctx-mon.module = module; ctx-mon.close = close