Android上HDMI介绍（基于高通平台）

本文重点针对HDMI在android上的应用，而比较相关的就是overlay机制。overlay在这里只是简单的介绍，后续会有文章再专门详述。

我没记错的话，高通从7X30开始，平台就可以支持HDMI（1.3）输出了。只不过在7x30上通过RGB接口外接一颗HDMI的transmitter来实现；而到了8系列（8x60），高通把这颗IC也集成了，直接就提供HDMI的输出了。（这样下去，以后渐渐的把外围器件都集成了，做底层的估计要失业了，做硬件的似乎工作量也没多少了）。

先来看看HW的能力，下图是MDP4.0的结构图：

可以看到，MDP4内部有4个overlaypipe，2个是forUI（RGB）的，2个VG是forvideo和graphics的；另外有2个mixer，mixer1是forprimarydisplay的（可以是MDDI接口的，也可以是RGB接口的lcd、oled等）；mixer2是forexternaldisplay的，如通过RGBinterface2外接HDMItransmitter到TV，也可以是NTSC/PAL等模拟电视信号。

Note：VG1和RGB1被mixer1混合到primarylcd，VG2和RGB2被mixer2混合到externalLCD（如HDMITV）

如果是MDP4.1的话，MDDI接口被移除了，另外RGB接口只有一个，另一个内部集成为HDMI接口了。

上面提到的是硬件平台相关的，就是说硬件有支持HDMI输出的能力，但是软件的状况呢？我们来看看Android和高通的状况。

关于HDMI本身，我就不介绍了，网上随便找找都可以看明白。

研究过Android的都知道，surfacefinger负责管理应用程序的显示窗口，每个窗口可以由多个surface组成，surfaceflinger通过OpenGL（可以通过HW，也可以是SW）把所有的surface合成后，通过调用gralloc模块或是overlay模块（MDP4.X才支持）把整屏数据送到显示设备上。可是Android（截止到2.2，3.0的状况还未知）上目前只支持一个显示设备，也就是说在surfaceflinger只能固定一个显示设备，那么HDMI这个应用在android手机上如何应用呢？

这里介绍2个做法，一个是高通给做好的，叫做UImirroring和videomirroring；另一个就是我们自己添加接口，AP自己来实现想要的功能。

先来看高通在android中的做法，根据字面不难理解，UImirroring和videomirroring其实就是把原来显示在primaryLCD上的数据mirror到HDMI接口。下图为软件框架图：

先来看看HDMI的控制方面，上图的右侧，user空间中有一个HDMIservice，包含一个listener（都是java的），当HDMIcable插入后，底层HDMI的驱动检测到（HPD）后，通过kobject_uevent传送给HDMIdaemon，daemon再把event发送给HDMIservice，HDMIservice除了判断这个event（cable状态），另外还要判断qualcommsetting中HDMI的on/off选项，然后把判断结果broadcast给各个AP，各个AP也就知道当前是否要开启HDMI输出了

接着先看UImirroring（不含video的状况）的实现，它针对的是界面的操作，数据为RGB格式。我们知道在kernel中每个显示设备都对应一个fb，初始化时都会分配framebuffer，在这里，primarylcd对应fb0设备，HDMI对应fb1设备。正常情况下，surfaceflinger合成好一个mainsurface后，通过postbuffer（gralloc模块）把数据放入fb0，然后，通过overlay（kernel下做的，上层看到的还是通过IOCRL－FBIOPUT_VSCREENINFO命令实现）输出到primarylcd；当平台支持HDMI并且UImirroring开启时，gralloc中（framebuffer.cpp）初始化时会多创建一个task（hdmi_ui_loop），并新建一个overlay（主要是控制和数据，参考overlaylib.h），这个overlay对应的channel固定为fb1，srcfd就是fb0，也就是说这个overlay的源数据就是fb0，也就是primarylcd上的数据，通过rotator进行旋转（电视是横屏），然后在overlay中再scaleup后再通过HDMI送到TV。这样看来，送到HDMI上的数据其实就是把fb0中的数据copybit了一份并放大，多少会有些失真的，但对于UI界面来说是可以接受的。上述整个过程，surfaceflinger是不参与的。

再来看videomirroring是怎么做的？

先来看看什么是videomirroring，其实就是手机播放视频，同时通过HDMI输出到TV上，手机上的内容分为2个部分，一个是视频本身部分，另一个是UI，这已经占用2个overlaypipe了（一个VGpipe，一个RGBpipe），TV上视频部分肯定是需要一个VGpipe的,另外，由于视频大小问题，视频不可能正好为全屏模式，这样必须还需要一个RGBpipe来实现一个背景（全黑）。4个pipe都被占用了，没有多余的pipe来把UI部分传到TV上，所以再使用高通平台时候，进行videomirroring时，TV上只能播放视频画面，UI部分（如菜单）在TV上是无法显示的。

接着来看video部分是怎么处理的？首先手机端UI部分的处理模式不变，只不过上面提到的hdmi_ui_loop这个task会被停掉（UI不需要送到HDMI，原因上面已经解释过）；video部分的frame通过opencore解码出来后，首先会通过surfaceflinger来创建overlay（参考layerbuffer.cpp），当系统支持HDMI时通过createoverlay都会创建2个通道（这里是2个VG通道），其中包含2个controlchannel和2个datachannel，它们的HAL层接口都再overlaylib.cpp中，channel0forfb0；channel1forfb1，如果需要旋转，则从系统pmem中再分配对应的内存。AP中overlay基本上的流程是这样的（可以参考overlays.cpp，里面不全，我补充了一些):

sp<SurfaceComposerClient>client=newSurfaceComposerClient();//新建surface客户端

//createpushbuffersurface

sp<Surface>surface=client->createSurface(getpid(),0,320,240,

PIXEL_FORMAT_UNKNOWN,ISurfaceComposer::ePushBuffers);//创建一个surface

//gettotheisurface

sp<ISurface>isurface=Test::getISurface(surface);//得到surface相关接口

printf("isurface=%p\n",isurface.get());

//nowrequestanoverlay

sp<OverlayRef>ref=isurface->createOverlay(320,240,PIXEL_FORMAT_RGB_565);//创建overlay，并得到控制通道

sp<Overlay>overlay=newOverlay(ref);//初始化overlay并得到数据通道

overlay->setFd(mFd);//设置srcdata的fd

overlay->setCrop(x,y,w,h);//设置剪裁信息（根据需要）

overlay->queueBuffer(offset);//设置显示数据的偏移

这样videoplayer没解码出一个frame，都会调用quene函数把数据送入2个数据通道，overlayengine会把数据送到2个显示设备。

关于那个背景，暂时在code中还没发现，也许是因为目前的版本不是最终版本，后续还会更新。

上面的做法是高通的；但它是有限制的，比如说无法在2个屏幕上显示不同的内容。如果我们要做，也是可以的，主要就是看AP怎么定义规则了。另外framework中需要添加接口，主要是提供一个针对fb1设备的控制接口，同样也是绕过surfaceflinger。比如说手机在播放一个影片，通过HDMI把影片传送到TV上，同时手机端可以去浏览网页。这个功能可以这样做，AP背景播放影片，得到的frame不送到primarydisplay上，而是通过新加的接口输出到fb1设备上，而browser的UI正常显示即可。如果是在高通平台去实现的话，需要把qualcommsetting里面的HDMI选项关掉，否则高通的做法和你自己AP的做法就乱套了。不过目前看，高通提供的方式似乎也可以满足应用了，但应用是永无止境的，只要user有这样的需求，developer就要去做，呵呵！