Android display SW架构分析（二）

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->device.common.tag = HARDWARE_DEVICE_TAG;

    ctx->device.common.version = 0;

    ctx->device.common.module = module;

    ctx->device.common.close = close_copybit;

    ctx->device.set_parameter = set_parameter_copybit; // 设置参数

    ctx->device.get = get;

    ctx->device.blit = blit_copybit; // 传送显示数据

    ctx->device.stretch = stretch_copybit;

    ctx->mAlpha = MDP_ALPHA_NOP;

    ctx->mFlags = 0;

    ctx->mFD = open("/dev/graphics/fb0 ", O_RDWR, 0); // 打开设备

     Kernel Space Display 功能介绍

这里的Kernel 空间（与Display 相关）是Linux 平台下的FB 设备（参考上图中的红色部分）。下面介绍一下FB 设备。

Fb 即FrameBuffer 的简称。framebuffer 是一种能够提取图形的硬件设备，是用户进入图形界面很好的接口。有了framebuffer ，用户的应用程序不需要对底层驱动有深入了解就能够做出很好的图形。对于用户而言，它和/dev 下面的其他设备没有什么区别，用户可以把

framebuffer 看成一块内存，既可以向这块内存中写入数据，也可以从这块内存中读取数据。它允许上层应用程序在图形模式下直接对显示缓冲区进行读写操作。这种操作是抽象的，统一的。用户不必关心物理显存的位置、换页机制等等具体细节。这些都是由Framebuffer 设备驱动来完成的。

从用户的角度看，帧缓冲设备和其他位于/dev 下面的设备类似，它是一个字符设备，通常主设备号是29 ，次设备号定义帧缓冲的个数。

在LINUX 系统中，设备被当作文件来处理，所有的文件包括设备文件，Linux 都提供了统一的操作函数接口。上面的结构体就是Linux 为FB 设备提供的操作函数接口。

1 ）、读写（read/write ）接口 ，即读写屏幕缓冲区（应用程序不一定会调用该接口）

2 ）、映射（map ）操作 （用户空间不能直接访问显存物理空间，需map 成虚拟地址后才可以）

由于Linux 工作在保护模式，每个应用程序都有自己的虚拟地址空间，在应用程序中是不能直接访问物理缓冲区地址的。为此，Linux 在文件操作 file_operations 结构中提供了mmap 函 数，可将文件的内容映射到用户空间。对于帧缓冲设备，则可通过映射操作，可将屏幕缓冲区的物理地址映射到用户空间的一段虚拟地址中，之后用户就可以通过读 写这段虚拟地址访问屏幕缓冲区，在屏幕上绘图了。实际上，使用帧缓冲设备的应用程序都是通过映射操作来显示图形的。由于映射操作都是由内核来完成，下面我 们将看到，帧缓冲驱动留给开发人员的工作并不多

       3 ）、 I/O 控制： 对于帧缓冲设备，对设备文件的 ioctl 操作可读取 / 设置显示设备及屏幕的参数，如分辨率，显示颜色数，屏幕大小等等。 ioctl 的操作是由底层的驱动程序来完成

Note ：上述部分请参考文件 fbmem.c 。