顯示部分的幾個問題這幾天通過實際測試澄清了一下，主要是下圖中各個模塊的使用狀況以及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個方案都在，上層將根據實際應用自行選擇使用其一。
