高通Android平台下关于display部分的几个关键问题
显示部分的几个问题这几天通过实际测试澄清了一下，主要是下图中各个模块的使用状况以及HAL层几个模块的调用流程。以问题的方式描述如下：
1、 Ap是怎么进行显示的？
Surfaceflinger负责所有上层的显示处理，对于AP（2D或是3D的应用程序）而言，只要到surfaceflinger中创建surface，设置好参数，接下来都是统一交给surfaceflinger进行处理
2、 Surface是怎么管理多个surface的？
不管有多少个surface，最终送到显示部分的只能是屏幕大小数据，surfaceflinger中利用MDP或是GPU进行多个surface的合成处理，普通的合成MDP就可完成，但如果是复杂的比如3D的应用等就必须使用GPU，最终合成的好数据会被送到framebuffer中。
3、 Framebuffer是什么？
Framebuffer是Linux中为显示数据分配的一块显存（fb设备中），通常大小是一整个屏幕数据的两倍，对于上层AP而言，只需要将要显示的数据丢到framebuffer中就OK了，但此时显示数据并未真正的被送到LCD上，而是暂存在framebuffer中而已。
4、 上层是通过什么方式将显示内容送到framebuffer的？
有2个方式（二选一，不会同时在运行）：
A、 普通的显示，使用copybit（MDP）（未使用GPU）
Surfaceflinger通过copybit将要显示的数据送到framebuffer。
Note：copybit可以看做是MDP PPP的接口，它提供了MDP的功能，如多个layer合成，scale、rotate等。
其接口在：android/hardware/msm7k/libcopybit/copybit.cpp
B、 使用GPU（即使用图中的Graphics driver）
当进行复杂的显示处理时，比如3D的应用，GPU把处理好的数据直接丢到framebuffer中，和MDP没有任何关系
5、 Framebuffer中的数据是如何被送到LCD显示的？
图中的Gralloc完成的。
Gralloc有2个功能：
一个是和copybit相同的，里面有MDP PPP的接口（目前没有使用）
另一个则是刷屏（整屏刷）的接口，即将framebuffer中的数据送到lcd上，调用的是MDP DMA的接口
这部分的code在android/hardware/msm7k/libgralloc-qsd8k目录下，之前没有留意，以为没有使用。现在可以看出开机初始化后就创建了disp_loop thread，里面的操作就是调用系统接口
ioctl(m->framebuffer->fd, FBIOPUT_VSCREENINFO, &m->info)
将数据送到lcd
Note：送数据的时候是2个buffer切换的
另外，上层surfaceflinger也是通过Gralloc中的接口获知屏幕的大小，调用接口为
ioctl(fd, FBIOGET_VSCREENINFO, &info)，info中的屏幕宽高对应的就是底层driver设置的宽高值
6、 OpenGL是什么？
它是一个图像处理引擎，当需要一些复杂的显示（2D/3D）操作时会用到它。它分为SW方案和HW方案，软件方案就是图中的libagl.so,对应到目前项目中是libGLES_android.so，它可以完成简单的2D（文字，icon等）处理，通过trace看目前大部分显示操作都是它来完成的。
Note：它是软件方案，处理好的数据是通过copybit送到framebuffer的，而不是GPU。
其接口部分参考：android/frameworks/base/opengl/libagl
HW方案就是图中的Graphics driver，它通过使用GPU硬件来完成图像处理，处理后的数据直接送到framebuffer中。其接口部分参考：android/frameworks/base/opengl/libs（有几个版本）
7、 OpenGL在项目中是如何配置的？
在android/vendor/qcom/msm7627_ffa目录下有一个egl.cfg文件，里面指定了当前版本中的OpenGL信息，目前如下：
0 0 android
0 1 adreno200
第一行代表该codebase支持SW 方案的OpenGL，是android default的
第二行代表该codebase也支持HW方案的OpenGL，是高通的adreno引擎
如果该cfg文件为空，则只支持default的SW方案。
如果2个方案都在，上层将根据实际应用自行选择使用其一。
该部分请参考：android/frameworks/base/opengl/libs/EGL/loader.cpp