OpenHarmony 图形子系统（二）weston compositor分析 原创 精华

通过上一节，我们熟悉了基于 Linux DRM的基础显示平台，以及wayland 相关的几个基础概念。这节我们将对搭建在其上的 weston compositor 进行深入分析。

Weston 是基于Wayland 协议的 compositor 的参考实现。其它的实现比如 GNOME 和KDE 也默认提供了基于Wayland display server 协议建立的全功能桌面环境。OpenHarmony 标准系统目前采用的是weston 的实现。

了解weston compositor 有利于我们对OpenHarmony 图形子系统的移植适配及启动问题进行调试。

Weston 结构分析

下图是 OpenHarmony-3.0-LTS 版本的图形子系统 compositor server端的结构图。

compositor 上端通过 wayland 协议与client 进行通讯。

server 端除了 weston外，还加载了窗口管理服务(wmserver)模块和 vsync 模块。另外加载了一个 ivi-shell 模块，这个我们后面在分析client 端 WindowManager 时再说。

weston 下端依赖几个display hdi 层相关的库：

• libdisplay_gfx 实现图形的硬件加速接口。
• libdisplay_gralloc：负责显示模块内存的管理，包括内存的申请和释放、内存映射等操作。

drm backend 中 renderer模块通过 use_pixman 选项选择使用 pixman renderer 还是 egl。 egl 是 rendering API（如 OpenGL，OpenGL ES) 与底层原生平台窗口系统之间的接口。

pixman-render 中又通过 use_tde 变量来选择是否使用 tde 硬件加速模块。 TDE（Two Dimensional Engine）是海思的2D图形加速引擎。Rockchip 对应的叫 RGA (Raster Graphic Acceleration) 二维光栅图形加速单元，用来加速了二维图形操作。例如点/线绘制、图像缩放、旋转、位图、图像合成等。

目前 3.0-LTS 若是其它非海思平台，若检测不到tde 模块，则会默认使用 pixman 来进行软件渲染。

关于Wayland

要知道 wayland 协议是被设计成”异步的面向对象“（asynchronous object-oriented protocol）的协议。面向对象（Object-oriented）表示 compositor 所提供的服务是以一系列贮存在同一个compositor 中的对象的方式呈现。

各个对象实现了一个接口（interface)，接口有名字、若干的方法（request)及系列相关的events。接口协议可以在xml 文件中描述，编译时有脚本可将其自动生成C 代码（wayland_standard/wayland_scanner_wrapper.py）。

客户端可以给对象发送请求，如果对象的接口支持这个请求的话。

compositor 中有一些wayland 的核心接口（core interfaces) 是必须要具备的，定义在 wayland_standard/protocol/wayland.xml中。此外特定的compositor 可以实现它们自己的接口作为扩展协议。每个接口协议都有版本号，以保证版本的兼容性。

知道上面的前置知识后，我们就可以开始分析weston 的代码了。

weston 启动流程伪代码

weston 启动流程比较长，我们只挑出我们感兴趣的主干部分。整理一下流程，有助于后续调试的时候迅速回忆起看过的代码。

wet_main(args)
	weston_display_create()  //创建 display 对象
	load_configuration（&config） //根据启动参数，加载配置文件 weston.ini 中的配置
	weston_compositor_create()  //创建 compositor 实例
	load_backend()  //根据启动参数-b，显式加载后端显示接口 drm-backend.so
		WL_EXPORT weston_backend_init() //显示后端drm-bakcend.so 初始化入口
			drm_backend_create()
			if use_pixman:
				init_pixman()  //根据启动参数 use_pixman, 在renderer pixman 或者 egl 二选一
					pixman_render_init()  
						tde_renderer_alloc_hook()    
							tde_render_gfx_init()
								dlopen(”libdisplay_gfx.so”)    
							GrallocInitialize()    
							→ peripheral/display “libdisplay_gralloc.so”    
			else:
				init_egl()
	VsyncModuleStart() //依赖图形子系统中的 libvsync_module.so
		InitSA() //注册ID为VSYNC_MANAGER_ID的  Vsync Manager 服务
			RegisterSystemAbility(VSYNC_MANAGER_ID)
		VsyncMainThread()
	load_modules() //加载weston.ini 里配置的 modules 项，3.0-LTS版本里加载了 libivi-controller.z.so,libwmserver.z.so 。 后面介绍 wmserver 窗口管理器模块。
	wl_display_run() //进入事件等待及常规任务循环
		while(run)
			wl_display_flush_clients()
			wl_event_loop_dispatch()

然后来梳理一下我们最关心的 surface 提交， 然后重绘（repaint）及输出流程。

surface 接口绑定及 surface commit 流程

这里就会涉及到一些接口实现的绑定。伪代码中用 (->) 箭头表示我们所关注的其中一个接口方法的实现。方法调用是当client 端发送对应的 wl_xxx 请求事件时被调用。

weston_compositor_create()
	compositor_bind() //创建 compositor 时绑定 compositor_interface 接口实现
		struct wl_compositor_interface compositor_interface //compositor 接口实现
			→compositor_create_surface //创建surface 时绑定 surface 接口实现
				struct wl_surface_interface surface_interface //surface 接口实现
					→ surface_commit()  //在 client 端调用 wl_surface_commit() 提交至此接口
						weston_surface_commit_state（）
							pixman_render_attach() //若是新加入的surface 则会进行renderer attach
						weston_surface_schedule_repaint（surface）//标记 output 中 该surface 需要被 repaint

repaint 流程

当有surface 被标记成需要 repaint 时，repaint timer handler 会对这些surface 进行重绘后输出显示。

wl_event_loop //wayland 事件循环
	output_repaint_timer_handler
		backend→repaint_begin()  //开始调用后端 repaint 接口
				weston_output_repaint()
					→drm_output_repaint()
							drm_output_render() //渲染
								if use_pixman:
									drm_output_render_pixman()
											→pixman_renderer_repaint_output()
												repaint_surfaces()
													draw_view()
														repaint_region()
								else:
									drm_output_render_gl()
		drm_repaint_flush() //合成重绘后的画面刷新输出
			drm_pending_state_apply()  //kms

先更新这些，伪代码部分可以对照着源码多梳理几遍。后面将编写一个简单的client，熟悉其核心接口对象（core interfaces)。然后以其为基础分析图形子系统中如何对其进行封装适配，增加WM 窗口管理，Vsync 帧同步，内存管理等模块。