一种在Linux上兼容运行Android应用的图形显示方法与装置与流程

一种在linux上兼容运行android应用的图形显示方法与装置
技术领域
[0001]
本发明涉及计算机技术领域，特别是涉及一种在linux兼容android运行领域中融合图形的显示方法与装置。


背景技术：

[0002]
通常来说android的图形显示机制是在android系统内部完成的，android为了解决在gpu能力较弱的嵌入式设备上的图形显示问题，采用了嵌入式图形gpu，同时采用了opengl es图形显示接口库。图3显示了android的图形显示机制，具体来说，android的图形显示是通过android中的surfaceflinger来完成图形绘制的总体绘制过程，surfaceflinger是一个控制单元，对于上层应用需要显示的图形图层，surfaceflinger会选择相应的显示设备，同时通过egl接口来调用opengl es图形库接口完成相应的绘制，并输出给framebuffernativewindow来进行gralloc对显示设备和gpu设备的调用，由gpu设备完成图形的绘制渲染过程。最后通过对linux内核中的显示设备进行送显工作，从而完成图形的绘制到送显的全过程。
[0003]
这与linux的图形显示机制以及linux的图形显示框架有较大的不同，linux的图形显示是面对gpu能力较强的独立显卡或者集成显卡，同时采用的是opengl图形显示库接口。具体来说，linux的图形显示是依据x协议，x协议是以位图图像显示图形化界面的一套软件规范及协议。目前x window system使用最广的软件实现是xorg，它采用了c/s架构，服务端和客户端可以基于网络通信。图4显示了linux的图形显示机制，linux应用通过图形绘制接口调用opengl图形库，opengl通过基层直接渲染dri(direct rendering infrastructure)图形渲染框架调用直接渲染管理器drm(direct rendering manager)完成对应用内各种图层的绘制工作，其中基层直接渲染dri在具体图形绘制时会负责完成对硬件gpu的调用，gpu完成相应的图形绘制渲染后存入framebuffer中，framebuffer中的数据通过kms(kernel mode-setting)传送给显示控制器lcdc，完成送显的工作。至此完成全部图形绘制到送显的全流程。
[0004]
很明显，android与linux的显示机制和面向的硬件都有较大的差异性，当在linux系统上兼容运行android应用时，面临不同类型的gpu物理设备，而不同类型的gpu设备本身对操作系统的支持是不同的，例如：原先linux上可以直接运行的gpu并不支持android，而原先android系统上支持的gpu又不支持linux的图形显示。因此想要android以兼容层的方式运行在linux操作系统之上，就必须打通两者的图形显示机制。
[0005]
此外，如果要在linux上直接运行android应用，还必须面对各种不同类型的显卡问题。目前，还有一部分老式显卡，在运行android兼容的时候由于显卡本身的原因不能支持open gl图形库的高版本，而部分android应用依赖于高版本的图形库，因此会导致应用无法运行的情况，针对这种无法使用图形硬件加速的设备，需要另外提供图形加速方案。


技术实现要素：

[0006]
本发明所要解决的主要技术问题在于，针对当android应用以容器方式兼容运行在linux系统中时，由于android图形显示和linux图形显示机制的较大的差异性，导致出现无法正常完成图形显示功能的问题，以及由于面临不同类型的gpu物理设备而产生的不兼容问题，提出一种在linux上兼容运行android操作系统的图形显示方法与装置，可以统一android和linux的图形显示机制，并且根据当前系统环境中的不同显卡的gpu种类，分别采取不同的策略以完成图形显示的整个过程，以达到融合图形显示的目的，并且相对于单一策略而言，能够降低系统资源的消耗，提高图形显示的效率。另外还通过图形软加速的方法解决老式显卡不支持应用所需图形库的情况。
[0007]
根据本发明一个方面，提供了一种在linux上兼容运行android应用的图形显示方法，其中所述android应用以容器方式兼容运行在linux系统中，所述linux系统gpu硬件类型能够支持所述android应用所需的图形库，该方法包括：
[0008]
s1：由图形绘制控制进程判断所述容器android侧是否支持所述gpu硬件类型，如是则启动s2步骤，如果否且所述容器linux侧支持所述gpu硬件类型，则启动s3步骤；
[0009]
s2：由所述容器android侧调用opengl es，所述opengl es根据图形绘制请求调用gpu生成第一图形数据，由所述图形绘制控制进程将所述第一图形数据传递给所述容器linux侧的基层直接渲染dri，所述基层直接渲染dri获取所述第一图形数据并完成图形的合成绘制，生成第二图形数据；所述基层直接渲染dri将所述第二图形数据送显至当前linux系统显示硬件；
[0010]
s3：由所述容器android侧调用opengl es，所述opengl es将所述图形绘制请求传递给所述图形绘制控制进程；所述图形绘制控制进程将所述图形绘制请求从opengl es接口格式转换为opengl接口格式后，由opengl调用gpu生成第一图形数据；所述图形绘制控制进程将所述第一图形数据传递给所述容器linux侧的基层直接渲染dri，所述基层直接渲染dri获取所述第一图形数据并完成图形的合成绘制，生成第二图形数据，所述基层直接渲染dri将所述第二图形数据通过linux内核送显至当前linux系统显示硬件。
[0011]
作为本发明的进一步改进，所述linux系统gpu硬件类型不能支持所述android应用所需的图形库时，执行步骤：
[0012]
s4：由图形绘制控制进程判断所述容器android侧是否支持所述gpu硬件类型，如是则执行步骤s5；
[0013]
s5：由所述容器android侧调用图形软加速进程，所述图形软加速进程根据所述图形绘制请求调用cpu生成第一图形数据，所述第一图形数据由android硬件抽象层存入所述容器android侧的虚拟显示屏中；所述图形绘制控制进程将所述第一图形数据传递给所述容器linux侧的基层直接渲染dri；所述基层直接渲染dri将所述第一图形数据送显至当前linux系统显示硬件；
[0014]
作为本发明的进一步改进，所述opengl es调用gpu生成所述第一图形数据包括：opengl es调用framebuffernativewindow接口，所述framebuffernativewindow接口把所述图形绘制请求交由所述gpu，所述gpu根据所述图形绘制请求生成所述第一图形数据并写入到所述gpu的帧缓存中。
[0015]
作为本发明的进一步改进，所述opengl调用所述gpu生成所述第一图形数据包括：
所述open gl调用直接渲染管理器drm，所述直接渲染管理器drm把所述图形绘制请求传递给所述gpu，所述gpu生成所述第一图形数据。
[0016]
作为本发明的进一步改进，所述图形软加速进程模拟实现open gl和open gl es的图形接口。
[0017]
根据本发明的另一个方面，提供了一种在linux上兼容运行android应用的图形显示装置，其中所述android应用以容器方式兼容运行在linux系统中，所述linux系统gpu硬件类型能够支持所述android应用所需的图形库，该装置包括：
[0018]
图形绘制控制模块，获取所述gpu硬件类型，判断android是否支持所述gpu硬件类型，如是则启动第一绘制模块；如果否且所述容器linux侧支持所述gpu硬件类型，则启动第二绘制模块；
[0019]
第一绘制模块，所述第一绘制模块中由所述容器android侧调用opengl es，所述opengl es根据获取的图形绘制请求调用gpu生成第一图形数据，由所述图形绘制控制模块把所述第一图形数据传递给所述容器linux侧的基层直接渲染dri，所述基层直接渲染dri获取所述第一图形数据并完成图形的合成绘制，生成第二图形数据；所述基层直接渲染dri将所述第二图形数据通过linux内核送显至当前linux系统显示硬件；
[0020]
第二绘制模块，所述第二绘制模块中由所述容器android侧调用opengl es，所述opengl es将所述图形绘制请求传递给所述图形绘制控制模块，所述图形绘制控制模块将所述图形绘制请求从opengl es接口格式转换为opengl接口格式，由opengl调用gpu生成所述第一图形数据，由所述图形绘制控制模块把所述第一图形数据传递给所述容器linux侧的所述基层直接渲染dri，所述基层直接渲染dri获取所述第一图形数据并完成图形的合成绘制，生成第二图形数据，所述基层直接渲染dri将所述第二图形数据通过linux内核送显至所述当前linux系统显示硬件。
[0021]
作为本发明的进一步改进，所述linux系统gpu硬件类型不能支持所述android应用所需的图形库时，所述图形绘制控制模块判断所述容器android侧是否支持所述gpu硬件类型，如是则由所述容器android侧调用：
[0022]
图形软加速模块，所述图形软加速模块根据所述图形绘制请求调用cpu生成第一图形数据，所述第一图形数据由android硬件抽象层存入所述容器android侧的虚拟显示屏中；
[0023]
所述图形绘制控制模块从所述虚拟显示屏中获取所述第一图形数据，并将所述第一图形数据传递给所述容器linux侧的基层直接渲染dri；所述基层直接渲染dri将所述第一图形数据送显至当前linux系统显示硬件；
[0024]
作为本发明的进一步改进，还包括翻译模块，所述图形绘制控制模块调用所述翻译模块将所述图形绘制请求从opengl es接口格式转换为opengl接口格式。
[0025]
作为本发明的进一步改进，所述opengl es调用gpu生成所述第一图形数据包括：所述图形软加速模块模拟实现open gl和open gl es的图形接口。
[0026]
本发明的有益效果在于：
[0027]
(1)统一android和linux的图形显示机制；
[0028]
android图形显示和linux图形显示机制和两者所面向的硬件都有较大的差异性，导致android以兼容层的方式运行在linux操作系统之上时，出现无法正常完成图形显示功
能的问题，本发明所提供的方法统一了android和linux的图形显示机制，解决了兼容性的问题。
[0029]
(2)分别采取不同的策略支持不同类型的显卡；
[0030]
android以兼容层的方式运行在linux操作系统之上时，会面临各种不同类型的显卡问题，本发明所提供的方法可以让android的图形绘制根据当前系统环境中的不同显卡的gpu种类，分别采取不同的策略以完成图形显示的整个过程，以达到融合图形显示的目的，并且相对于单一策略而言，能够降低系统资源的消耗，提高图形显示的效率。
[0031]
(3)在linux系统的老式显卡不能支持android应用所要求的open gl图形库高版本的情况下，实现图形软加速。
[0032]
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
[0033]
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
[0034]
图1示出了本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的实现原理图；
[0035]
图2示出了本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的流程图；
[0036]
图3示出了android图形显示机制原理图；
[0037]
图4示出了linux图形显示机制原理图；
[0038]
图5示出了本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的图形软加速实现原理图；
[0039]
图6示出了本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的图形软加速实现流程图。
具体实施方式
[0040]
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
[0041]
可以理解的是，本发明的说明书和权利要求书及附图中的方法与装置中的相关特征可以相互参考。另外，本发明的说明书和权利要求书及附图中的“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。
[0042]
首先，在对本发明实施例进行描述的过程中出现的部分名词或者术语适用于如下
解释：
[0043]
hal：hal是hardware abstraction layer硬件抽象层的缩写，是建立在linux驱动之上的一套动态库，具有标准的调用接口。这套动态库不属于linux内核，而是属于linux内核层之上的系统运行库层。由于hal具有标准的硬件调用接口，可以屏蔽linux驱动复杂、不统一的接口。
[0044]
容器技术：容器有效地将由单个操作系统管理的资源划分到孤立的组中，以更好的在孤立的组之间平衡有冲突的资源使用需求。
[0045]
jstack：包含有容器的android运行环境。
[0046]
egl：opengl es和底层平台视窗系统之间的接口。
[0047]
dri(direct rendering infrastructure)基层直接渲染。
[0048]
drm：direct rendering manager直接渲染管理器，是给予dri客户端直接访问硬件的内核模块。
[0049]
kms：kernel mode-setting内核模式设置。
[0050]
lcdc：显示控制器。
[0051]
对于在linux操作系统上兼容运行android运行环境来说，android运行环境是运行在容器中的。将在现有linux操作系统上通过容器技术启动android的运行环境，记为jstack，在jstack内将android应用框架与运行环境作为linux的一个系统进程运行起来。
[0052]
本发明要解决的核心技术问题为，当android以兼容层的方式运行在linux操作系统之上时，由于android图形显示和linux图形显示机制的较大的差异性，导致出现无法正常完成图形显示功能的问题，以及由于面临不同类型的gpu物理设备而产生的不兼容问题。
[0053]
针对上述技术问题，本发明提出一种在linux上兼容运行android操作系统的图形显示方法与装置，第一对于android本身支持的gpu，通过修改android的送显机制，让android中已经存入framebuffer中绘制好的图形，直接导入到linux的dri中，把linux图形和安卓图形进行合成，然后让linux的dri可以直接完成送显工作；第二对于linux支持而android不支持的gpu，则通过图形库转换接口，让android图形库opengles直接转换成linux的opengl库接口，然后通过linux的drm调用gpu进行图形渲染、图形合成，再调用dri完成送显工作；第三对于老式显卡不能支持android应用所要求的open gl图形库高版本的情况，调用模拟实现open gl/es的图形接口的图形软加速软件，由图形软加速软件调用cpu进行具体的图形绘制，再调用dri完成送显工作。
[0054]
本发明的方法与装置可以让android的图形绘制根据当前系统环境中的不同的gpu种类，分别采取不同的策略以完成图形显示的整个过程，以达到融合图形显示的目的，并且相对于单一策略而言，能够降低系统资源的消耗，提高图形显示的效率。
[0055]
实施例1
[0056]
下面通过两个应用场景来具体说明在linux系统gpu硬件类型能够支持android应用所需的图形库的情况下，本发明的实现步骤。
[0057]
应用场景一：
[0058]
图2是本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的流程图，由图中可以看出在该实施例的方法中，具有以下步骤：
[0059]
s1：由图形绘制控制进程判断所述容器android侧是否支持所述gpu硬件类型，具
体来说有以下步骤：
[0060]
1.1：linux启动后，自动启动jstack中的图形绘制控制模块graphic controller进程，作为整个图形兼容显示的核心控制器；graphic controller会获取当前系统gpu硬件信息，同graphic controller中的配置文件相比较，决定图形绘制的方式。图1显示了本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的实现原理图，如图1的左侧分支所示，当android支持所述当前linux系统gpu硬件类型时，决定执行步骤s2。
[0061]
1.2：用户点击打开android应用，应用向surfaceflinger发出绘制图形的请求，surfaceflinger向egl发送图层绘制信息，egl调用opengl es图形库接口，进行具体的图形绘制工作。
[0062]
s2：如图1的左侧分支所示，当android支持所述当前linux系统gpu硬件类型时，opengl es根据获取的图形绘制请求调用gpu生成第一图形数据，将第一图形数据传递给基层直接渲染dri，基层直接渲染dri获取第一图形数据并完成图形的合成渲染，生成第二图形数据；基层直接渲染dri将第二图形数据通过linux内核送显至当前linux系统gpu硬件，结合图2流程图显示，具体来说有以下步骤：
[0063]
2.1：opengl es调用framebuffernativewindow接口；
[0064]
2.2：framebuffernativewindow把图层图形详细信息交由gpu进行具体图形绘制，并把绘制生成的第一图形数据写入到gpu帧缓存中；
[0065]
2.3：向图形绘制控制进程graphic controller发送图形绘制传递请求，并把gpu帧缓存中的显存起始地址发送给graphic controller；
[0066]
2.4：graphic controller控制把gpu帧缓存中的第一图形数据传递给基层直接渲染dri；
[0067]
2.5：基层直接渲染dri进行图形合成完成图形绘制工作，生成第二图形数据并传递给kms，完成送显过程，把图形显示在linux桌面端的窗口中。
[0068]
应用场景二：
[0069]
s1：由图形绘制控制进程判断所述容器android侧是否支持所述gpu硬件类型，具体来说有以下步骤：
[0070]
1.1：linux启动后，自动启动jstack中的图形绘制控制模块graphic controller进程，作为整个图形兼容显示的核心控制器；graphic controller会获取当前系统gpu硬件信息，同graphic controller中的配置文件相比较，决定图形绘制的方式。图1显示了本发明实施例提供的一种在linux上兼容运行android操作系统的图形显示方法的实现原理图，如图1的右侧分支所示，当android不支持所述当前linux系统gpu硬件类型时，则决定执行步骤s3。
[0071]
1.2：用户点击打开android应用，应用向surfaceflinger发出绘制图形的请求，surfaceflinger向egl发送图层绘制信息，egl调用opengl es图形库接口，进行具体的图形绘制工作。
[0072]
s3：如图1的右侧分支所示，当android不支持所述当前linux系统gpu硬件类型时，将获取的图形绘制请求从opengl es接口格式转换为opengl接口格式后，由opengl调用gpu生成所述第一图形数据，将第一图形数据传递给基层直接渲染dri，基层直接渲染dri获取第一图形数据并完成图形的合成绘制，生成第二图形数据，基层直接渲染dri将第二图形数
据通过linux内核送显至当前linux系统gpu硬件，结合图2流程图显示，具体来说有以下步骤：
[0073]
3.1：opengl es不进行图形绘制工作，而是把需要绘制的图形工作传递给图形绘制控制模块graphic controller；
[0074]
3.2：图形绘制控制进程graphic controller调用翻译模块opengl translator进行图形接口转换工作，完成从opengl es到opengl的图形转换，此时所有图形的绘制请求已经转换为open gl接口格式；
[0075]
3.3：open gl调用drm，drm把图形绘制传递给gpu，完成具体的图形绘制工作，生成第一图形数据并存入到gpu的帧缓存中；
[0076]
3.4：基层直接渲染dri进行图形合成完成图形绘制工作，生成第二图形数据并传递给kms，完成送显过程，把图形显示在linux桌面端的窗口中。
[0077]
下面通过一个应用场景来具体说明在linux系统gpu硬件类型不能支持android应用所需的图形库的情况下，本发明的实现步骤。
[0078]
应用场景三：
[0079]
图5是本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的图形软加速实现原理图。
[0080]
如图5所示，linux系统启动后，通过图形绘制控制进程graphic controller进行显卡类型的甄别，并通过接口通知android的图形绘制层针对某些类型的gpu需要启用图形软加速功能。
[0081]
当graphic controller识别当前显卡为android已经支持的显卡，则通过android的surfaceflinger进行native的图形绘制，在图形绘制过程中通过窗口绘制接口egl调用图形软加速进程，图形软加速进程模拟实现open gl/es的图形接口，调用cpu进行具体的图形绘制，然后把绘制好的图形输出到android hal中的虚拟显示屏上，再之后通过接口把该显示屏的图形起始地址指针发送给graphiccontroller，graphiccontroller把图形送给linux dri相应的接口，并告诉dri直接送显，从而完成android应用的图形显示工作。
[0082]
上述图形软加速进程可采用目前linux世界有部分开源的图形软加速软件实现，比如谷歌的swiftshader，这类软件可以实现opengl图形库的能力。
[0083]
图6是本发明实施例提供的一种在linux上兼容运行android应用的图形显示方法的图形软加速实现流程图，由图中可以看出在该实施例的方法中，具有以下步骤：
[0084]
s4：由图形绘制控制进程判断所述容器android侧是否支持所述gpu硬件类型，具体来说有以下步骤：
[0085]
1.1：linux启动后，自动启动jstack中的图形绘制控制模块graphic controller进程，作为整个图形兼容显示的核心控制器；graphic controller会获取当前系统gpu硬件信息，同graphic controller中的配置文件相比较，决定图形绘制的方式；
[0086]
s5：由容器android侧调用图形软加速进程，图形软加速进程根据图形绘制请求调用cpu生成第一图形数据，第一图形数据由android硬件抽象层存入容器android侧的虚拟显示屏中；图形绘制控制进程将第一图形数据传递给容器linux侧的基层直接渲染dri；基层直接渲染dri将第一图形数据送显至当前linux系统显示硬件；
[0087]
由图6中可以看出，具体来说绘图有以下步骤：
[0088]
1.2：用户点击打开android应用，应用向surfaceflinger发出绘制图形的请求，surfaceflinger根据1.1中获取的图形绘制的方式，通知egl启用图形软加速流程；
[0089]
1.3：egl启动图形软加速模块，并把需要绘制的图形信息通过接口发送给图形软加速模块；
[0090]
1.4：图形软加速模块模拟open gl/es图形库相应api，把具体需要绘制的要求发送给cpu，cpu根据要求进行图形绘制，生成第一图形数据并返回给图形软件加速模块；
[0091]
1.5：图形软加速模块通知android hal向虚拟显示屏幕送显；
[0092]
1.6：android hal把第一图形数据写入虚拟显示屏中；
[0093]
1.7：android hal通知graphic controller图形已经绘制完毕并送显到虚拟显示屏中。
[0094]
由图6中可以看出，具体来说送显有以下步骤：
[0095]
2.1：graphic controller通知drm需要进行图形送显工作，并传递已经绘制完毕的图形内存中起始地址指针；
[0096]
2.2：drm根据内存中起始地址指针向虚拟显示屏获取第一图形数据；
[0097]
2.3：drm调用dri gem准备开始送显工作；
[0098]
2.4：dri gem传递第一图形数据到kms；
[0099]
2.5：kms控制箱显示屏幕指定区域进行图像刷新，完成送显工作。
[0100]
实施例2
[0101]
进一步的，作为对上述实施例所示方法的实现，本发明另一实施例还提供了一种在linux上兼容运行android操作系统的图形显示装置。该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。在该实施例的装置中，具有以下模块：
[0102]
一：图形绘制控制模块graphic controller(对应于实施1中的图形绘制控制进程)，获取当前linux系统gpu硬件类型，判断android是否支持所述当前linux系统gpu硬件类型，如是则启动第一绘制模块，如果否则启动第二绘制模块；具体来说有以下步骤：
[0103]
1.1：linux启动后，自动启动jstack中的图形绘制控制模块graphic controller进程，作为整个图形兼容显示的核心控制器；graphic controller会获取当前系统gpu硬件信息，同graphic controller中的配置文件相比较，决定图形绘制的方式。如图1的左侧分支所示，具体来说当android支持所述当前linux系统gpu硬件类型时，则决定调用第一绘制模块进行绘制工作；如图1的右侧分支所示，当android不支持所述当前linux系统gpu硬件类型时，则决定调用第二绘制模块进行绘制工作；
[0104]
1.2：用户点击打开android应用，应用向surfaceflinger发出绘制图形的请求，surfaceflinger向egl发送图层绘制信息，egl调用opengl es图形库接口，进行具体的图形绘制工作。
[0105]
二：第一绘制模块(对应于实施1中的s2)，如图1的右侧分支所示，opengl es根据获取的图形绘制请求调用gpu生成第一图形数据，由图形绘制控制模块把所述第一图形数据传递给基层直接渲染dri，基层直接渲染dri获取所述第一图形数据并完成图形的合成绘制，生成第二图形数据；基层直接渲染dri将所述第二图形数据通过linux内核送显至所述
当前linux系统gpu硬件。结合图2流程图显示，具体来说有以下步骤：
[0106]
2.1：opengl es调用framebuffernativewindow接口；
[0107]
2.2：framebuffernativewindow把图层图形详细信息交由gpu进行具体图形绘制，并把绘制后的第一图形数据写入到gpu framebuffer中；
[0108]
2.3：向图形绘制控制模块graphic controller发送图形绘制传递请求，并把framebuffer中的显存起始地址发送给图形绘制控制模块graphic controller；
[0109]
2.4：图形绘制控制模块graphic controller控制把gpu framebuffer数据传递给基层直接渲染dri；
[0110]
2.5：基层直接渲染dri进行图形合成完成图形绘制工作，生成第二图形数据，并传递给kms，完成送显过程，把图形显示在linux桌面端的窗口中。
[0111]
三：第二绘制模块(对应于实施例1中的s3)，如图1的右侧分支所示，opengl es将图形绘制请求发送到图形绘制控制模块graphic controller，图形绘制控制模块将所述图形绘制请求从opengl es接口格式转换为opengl接口格式，由opengl调用gpu生成第一图形数据，由图形绘制控制模块把第一图形数据传递给基层直接渲染dri，基层直接渲染dri获取第一图形数据并完成图形的合成绘制，生成第二图形数据，基层直接渲染dri将第二图形数据通过linux内核送显至当前linux系统gpu硬件。结合图2流程图显示，具体来说有以下步骤：
[0112]
3.1：opengl es不进行图形绘制工作，而是把需要绘制的图形工作传递给graphic controller；
[0113]
3.2：graphic controller调用翻译模块opengl translator进行图形接口转换工作，完成从opengl es到opengl的图形转换，此时所有图形的绘制请求已经转换为open gl接口格式；
[0114]
3.3：open gl调用drm，drm把图形绘制传递给gpu，完成具体的图形绘制工作，生成第一图形数据并存入到gpu的frambuffer中；
[0115]
3.4：基层直接渲染dri进行图形合成完成图形绘制工作，生成第二图形数据并传递给kms，完成送显过程，把图形显示在linux桌面端的窗口中。
[0116]
四：图形软加速模块(对应于实施1中的图形软加速进程)根据图形绘制请求调用cpu生成第一图形数据，第一图形数据由android硬件抽象层存入容器android侧的虚拟显示屏中；图形绘制控制模块将第一图形数据传递给容器linux侧的基层直接渲染dri；基层直接渲染dri将第一图形数据送显至当前linux系统显示硬件。
[0117]
结合图6流程图显示，具体来说绘图有以下步骤：
[0118]
1.2：用户点击打开android应用，应用向surfaceflinger发出绘制图形的请求，surfaceflinger根据1.1中获取的图形绘制的方式，通知egl启用图形软加速流程；
[0119]
1.3：egl启动图形软加速模块，并把需要绘制的图形信息通过接口发送给图形软加速模块；
[0120]
1.4：图形软加速模块模拟open gl/es图形库相应api，把具体需要绘制的要求发送给cpu，cpu根据要求进行图形绘制，并把绘制完成第一图形数据返回给图形软件加速模块；
[0121]
1.5：图形软加速模块通知android hal向虚拟显示屏幕送显；
[0122]
1.6：android hal把第一图形数据写入虚拟显示屏中；
[0123]
1.7：android hal通知graphic controller图形已经绘制完毕并送显到虚拟显示屏中。
[0124]
结合图6流程图显示，具体来说送显有以下步骤：
[0125]
2.1：graphic controller通知drm需要进行图形送显工作，并传递已经绘制完毕的图形内存中起始地址指针；
[0126]
2.2：drm根据内存中起始地址指针向虚拟显示屏获取第一图形数据；
[0127]
2.3：drm调用dri gem准备开始送显工作；
[0128]
2.4：dri gem传递第一图形数据到kms；
[0129]
2.5：kms控制箱显示屏幕指定区域进行图像刷新，完成送显工作。
[0130]
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实装置施例的相关描述。
[0131]
可以理解的是，上述方法和中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。
[0132]
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
[0133]
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
[0134]
类似地，应当理解，为了精简本发明并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
[0135]
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
[0136]
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项
来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。