android display 框架分析Word文档下载推荐.docx

android display 框架分析Word文档下载推荐.docx

《android display 框架分析Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《android display 框架分析Word文档下载推荐.docx（29页珍藏版）》请在冰豆网上搜索。

mon.version=0;

mon.module=module;

mon.close=close_copybit;

device.set_parameter=set_parameter_copybit;

//设置参数

device.get=get;

device.blit=blit_copybit;

//传送显示数据

device.stretch=stretch_copybit;

mAlpha=MDP_ALPHA_NOP;

mFlags=0;

mFD=open（"

/dev/graphics/fb0"

O_RDWR,0）;

//打开设备

KernelSpaceDisplay功能介绍

这里的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。

Androiddisplay架构分析（三）

2010-04-1610:

53

KernelSpaceDisplay架构介绍

如上图所示，除了上层的图形应用程序外，和Kernel空间有关的包括LinuxFB设备层以及和具体HW相关的驱动层，对应的源文件分别是fb_mem.c、msm_fb.c、mddi_toshiba.c。

下面会一一介绍。

fb_mem.c函数和数据结构介绍

这个文件包含了LinuxFb设备的所有接口，主要函数接口和数据结构如下：

A、Fb设备的文件操作接口

B、3个重要的数据结构

FrameBuffer中有3个重要的结构体，fb.h中定义，如下：

1）、frame_var_screeninfo

该结构体定义了显卡的一些可变的特性，这些特性在程序运行期间可以由应用程序动态改变，比较典型的如xrex和yres表示在显示屏上显示的真实分辨率、显示的bit数等，该结构体userspace可以访问。

2）、frame_fix_screeninfo

该结构体定义了显卡的一些固定的特性，这些特性在硬件初始化时就被定义了以后不可以更改。

其中最重要的成员就是smem_len和smem_start，前者指示显存的大小（目前程序中定义的显存大小为整屏数据RGB565大小的2倍）,后者给出了显存的物理地址。

该结构体userspace可以访问。

smem_start是显存的物理地址，应用程序是不可以直接访问的，必须通过fb_ops中的mmp函数映射成虚拟地址后，应用程序方可访问。

3）、fb_info

FrameBuffer中最重要的结构体，它只能在内核空间内访问。

内部定义了fb_ops结构体（包含一系列FrameBuffer的操作函数，Open/read/write、地址映射等）.

C、其他

1）、一个重要的全局变量

structfb_info*registered_fb[FB_MAX];

这变量记录了所有fb_info结构的实例，fb_info结构描述显卡的当前状态，所有设备对应的fb_info结构都保存在这个数组中，当一个FrameBuffer设备驱动向系统注册自己时，其对应的fb_info结构就会添加到这个结构中，同时num_registered_fb为自动加1。

2）、注册framebuffer函数

register_framebuffer（structfb_info*fb_info）;

unregister_framebuffer（structfb_info*fb_info）;

这两个是提供给下层FrameBuffer设备驱动的接口，设备驱动通过这两函数向系统注册或注销自己。

几乎底层设备驱动所要做的所有事情就是填充fb_info结构然后向系统注册或注销它

Androiddisplay架构分析（四）

56

msm_fb.c函数和数据结构介绍

该文件为高通显卡的驱动文件，比较重要的函数接口和数据结构如下：

A、高通msmfb设备的文件操作函数接口

staticstructfb_opsmsm_fb_ops={

.owner=THIS_MODULE,

.fb_open=msm_fb_open,

.fb_release=msm_fb_release,

.fb_read=NULL,

.fb_write=NULL,

.fb_cursor=NULL,

.fb_check_var=msm_fb_check_var,/*参数检查*/

.fb_set_par=msm_fb_set_par,/*设置显示相关参数*/

.fb_setcolreg=NULL,/*setcolorregister*/

.fb_blank=NULL,/*blankdisplay*/

.fb_pan_display=msm_fb_pan_display,/*显示*/

.fb_fillrect=msm_fb_fillrect,/*Drawsarectangle*/

.fb_copyarea=msm_fb_copyarea,/*Copydatafromareatoanother*/

.fb_imageblit=msm_fb_imageblit,/*Drawsaimagetothedisplay*/

.fb_rotate=NULL,

.fb_sync=NULL,/*waitforblitidle,optional*/

.fb_ioctl=msm_fb_ioctl,/*performfbspecificioctl（optional）*/

.fb_mmap=NULL,

};

B、高通msmfb的driver接口

staticstructplatform_drivermsm_fb_driver={

.probe=msm_fb_probe,//驱动探测函数

.remove=msm_fb_remove,

#ifndefCONFIG_ANDROID_POWER

.suspend=msm_fb_suspend,

.suspend_late=NULL,

.resume_early=NULL,

.resume=msm_fb_resume,

#endif

.shutdown=NULL,

.driver={

/*Drivernamemustmatchthedevicenameaddedinplatform.c.*/

.name="

msm_fb"

},

C、msm_fb_init（）

向系统注册msmfb的driver，初始化时会调用

D、msm_fb_add_device

向系统中添加新的lcd设备，在mddi_toshiba.c中会被调用

mddi_toshiba.c函数和数据结构介绍

该文件包含了所有和具体LCD（Toshiba）相关的信息和驱动，重点的数据结构和函数结构如下：

A、LCD设备相关信息

staticstructplatform_devicethis_device_0={

.name="

mddi_toshiba_vga"

.id=TOSHIBA_VGA_PRIM,

.dev={

.platform_data=&

toshiba_panel_data0,

}

其中toshiba_panel_data0包含了硬件LCD的控制函数，如开关、初始化等等

B、LCDdriver接口

staticstructplatform_driverthis_driver={

.probe=mddi_toshiba_lcd_probe,

},

其中mddi_toshiba_lcd_probe中会调用msm_fb_add_device接口把具体LCD添加到系统中去。

C、mddi_toshiba_lcd_init

注册LCD设备及driver到系统中去，同时也把LCD的固有信息（大小、格式、位率等）一并注册到系统中去。

D、LCD相关控制函数

toshiba_common_initial_setup（）：

初始化MDDIbridge

toshiba_prim_start（）：

初始化LCD

DisplayKernel数据流分析

本部分来看一下应用层以下，显示数据的流程是怎样的。

先来分析一下传统的Linux平台下FB设备是如果调用的，如下图所示：

上层调用FBAPI（主要是fb_ioctl（）），fb_ioctl（）会调用具体显卡的驱动，这里是高通的显卡驱动，其实就是MDPDMA的驱动，通过MDPDMA把显示数据经MDDI接口送到外围LCD组件。

这里的MDPDMA并不对数据进行任何处理（可以完成简单的格式转换，如RGB565->

RGB666）。

接下来再分析一下Android平台下显示数据是如何处理的，如下图所示：

同样上层也是调用FBAPI，不过这里其实把FBbypass了，相当于直接调用的是高通MDPPPP的驱动，然后数据经PPP处理后再经MDDI接口送出到外围LCD组件。

这里的MDPPPP可以完成很多显示数据处理功能，如YUV->

RGB、Scale、Rotate、Blending等。

DisplayKernel初始化过程分析

Kernel部分display的初始化包含下面几个步骤：

1）、在linuxfb设备初始化时会向系统中注册msm_fb_driver。

Name为msm_fb。

msm_fb_init－>

msm_fb_register_driver->

platform_driver_register（&

msm_fb_driver）

其中的probe函数会对msmfb进行初始化，分配显存等（见msm_fb_probe函数）。

2）、在LCD模块初始化时会先向系统中注册驱动（在mddi_toshiba_lcd_init函数中）

platform_driver_register（&

this_driver）;

名字为mddi_toshiba_vga；

this_driver的probe函数为mddi_toshiba_lcd_probe，其内部会调用msm_fb_add_device向系统中添加MSMfb设备。

3）、调用platform_device_register（&

this_device_0）向系统中注册设备，名字为mddi_toshiba_vga，其中this_device_0包含了一些操作LCD的接口，如on/off。

Note:

设备和driver的name需要一致才可以绑定；

另外，如果某些设备不需要让platform的总线来管理，那么只需要注册驱动即可，而无须向系统中注册device，如msm_touch。

Androiddisplay架构分析（五）

2010-04-1611:

01

Display接口介绍

1、UserSpacedisplay接口

在Android平台下，应用程序面对的显示部分的接口就是HAL，参考copybit.c，具体接口如下介绍：

open_copybit

初始化相关变量，并调用open（"

打开fb设备。

set_parameter_copybit

设置各种操作参数，如rotate、alpha、dither等。

stretch_copybit

Copy一块数据（Rectangle）到显存，然后并命令msm_fb进行显示。

close_copybit

调用close（ctx->

mFD）;

关闭fb设备。

另外，应用程序在使用上面接口之前，需要调用mapFrameBuffer接口（EGLDisplaySurface.cpp），其功能如下：

1、初始化显示相关参数，并设置到底层。

2、映射出显存的虚拟地址。

2、Kerneldisplay接口

Kernel部分显示的接口全部都在fbmem.c中，这里详细介绍一下：

fb_open

打开Linux下fb设备。

fb_read/fb_write

读写显存中的数据

fb_ioctl

对显示设备的命令操作。

如get或set一些显示参数、通知底层进行刷屏等。

在典型应用中，画屏的一般步骤如下：

1．打开/dev/fb设备文件。

2．用ioctrl操作取得当前显示屏幕的参数，如屏幕分辨率，每个像素点的比特数。

根据屏幕参数可计算屏幕缓冲区的大小。

3．将屏幕缓冲区映射到用户空间。

4．映射后就可以直接读写屏幕缓冲区，进行绘图和图片显示了。

典型程序段如下：

#include<

linux/fb.h>

intmain（）

{

intfbfd=0;

structfb_var_screeninfovinfo;

structfb_fix_screeninfofinfo;

longintscreensize=0;

/*打开设备文件*/

fbfd=open（"

/dev/fb0"

O_RDWR）;

/*取得屏幕相关参数*/

ioctl（fbfd,FBIOGET_FSCREENINFO,&

finfo）;

ioctl（fbfd,FBIOGET_VSCREENINFO,&

vinfo）;

/*计算屏幕缓冲区大小*/

screensize=vinfo.xres*vinfo.yres*vinfo.bits_per_pixel/8;

/*映射屏幕缓冲区到用户地址空间*/

fbp=（char*）mmap（0,screensize,PROT_READ|PROT_WRITE,MAP_SHARED,fbfd,0）;

/*下面可通过fbp指针读写缓冲区*/

...

3典型应用flow分析

在不同应用程序中，上层的调用会有所不同，比如Andriod下会选择应用程序跳过Linuxfb操作层，直接操作显卡驱动层，称之为BLTaccelerator。

下面看一下Android平台下画屏的操作流程。

1、通过mapFrameBuffer直接把用户空间的数据映射到显存中。

2、调用HAL中的stretch函数直接命令MSM设备提取显存数据然后送入MDPPPP进行处理并经MDDI接口送到外围LCD组件。

具体的函数调用流程如下：

copybit_open（）；

//打开BlitEngine，同时也打开fb设备

mapFrameBuffer（）;

//设置显示参数，同时得到显存虚拟地址

copybit->

stretch（copybit,&

dst,&

src,&

sdrect,&

it）;

//通知底层去刷屏

接下的流程是：

Androiddisplay架构分析（六）

05

Surfacemanager介绍

本部分介绍的完全是用户空间显示部分的架构，与kernel并没有直接的联系，主要是JNI以下到HAL以上的部分。

1、Surfacemanager（surfaceflinger）简介

Surfacemanager是用户空间中framework下libraries中负责显示相关的一个模块。

如下：

当系统同时执行多个应用程序时，SurfaceManager会负责管理显示与存取操作间的互动，另外也负责将2D绘图与3D绘图进行显示上的合成。

surfacemanager可以准备一块surface（可以看作一个layer），把surface的fd（一块内存）传给一个app，让app可以在上面作画。

典型应用如下：

2、Surfacemanager架构分析

Android中的图形系统采用Client/Server架构，如下：

Client端：

应用程序相关部分。

代码分为两部分，一部分是由Java提供的供应用使用的api,另一部分则是由c++写成的底层实现。

Server端：

即SurfaceFlinger，负责合成并送入buffer显示。

其主要由c++代码编写而成。

Client和Server之前通过Binder的IPC方式进行通信，总体结构图如下：

如上图所示，Surface的client部分其实是提供给各应用程序进行画图操作的一个桥梁，该桥梁通过binder通向server端的Surfaceflinger，Surfaceflinger负责合成各个surface，然后把buffer传送到framebuffer端进行底层显示。

其中每个surface对应2个buffer，一个frontbuffer,一个backbuffer，更新时，数据更新在backbuffer上，需要显示时，则将backbuffer和frontbuffer互换。

下一部分我们重点研究一下Surfaceflinger。

Androiddisplay架构分析（七-1）

12

Surfaceflingerprocess流程分析

根据前面的介绍，surfaceflinger作为一个serverprocess，上层的应用程序（作为client）通过Binder方式与其进行通信。

Surfaceflinger作为一个thread，这里把它分为3个部分，如下：

1、Thread本身处理部分，包括初始化以及threadloop。

2、Binder部分，负责接收上层应用的各个设置和命令，并反馈状态标志给上层。

3、与底层的交互，负责调用底层接口（HAL）。

结构图如下：

注释：

a、Binder接收到应用程序的命令（如创建surface、设置参数等），