0x1 Weston简介

0x11 X系统

X即X11、X Window System，是用于在类UNIX的操作系统上的位图显示的窗口系统，提供了GUI环境的基本框架，可以在显示设备上绘制、移动窗口，通过鼠标、键盘、触摸屏与用户交互. X Server是X显示服务的一种开源实现，其系统结构如下图所示

0x12 Wayland系统

Wayland是一个显示服务协议，服务端为Wayland Compositor，服务端把把X系统中的X Server和Compositor合二为一，作为类Unix操作系统上更现代、简洁的窗口系统，旨在替换X系统。Weston是Wayland Compositor的参考实现。下面是Wayland官网文档给出的架构简图.

Wayland协议为Client/Server模式，客户端为图形应用程序，发送绘制命令，请求在各自输出缓冲区的显示，服务器为Compositor，控制各个客户端输出缓冲区的合成和显示。

Wayland参考实现Weston包括两层协议。

一个为底层IPC协议。采用Linux Domain Socket实现的IPC，这部分采用手动写的C语言实现。

另一个是上层消息协议。这部分采用libffi来实现，从规定格式的XML文件中自动生成，可以灵活地动态扩展或者用于错误验证。处理客户端和Weston之间的上层交互流程，以实现窗口系统的基本功能。

Wayland参考实现包括两部分，libwayland-client和libwayland-server，其架构简图如下所示。

0x2 Buffer管理

在Weston的实现中，客户端先把内容绘制到一个buffer中，然后weston把多个客户端绘制的buffer通过compositor模块合成在一起。这里面涉及到buffer在各个模块之间的传递，从性能的角度考虑，我们很自然地想到如何避免memory copy的问题。下来我们来看一下如何实现zero memory copy的。

Weston中的buffer用wl_buffer对象来描述。这个buffer需要在客户端和Compositor之间共享。目前有两种buffer的管理模式。

wl_shm
这种方式是通过共享内存的方式来实现客户端和Compositor之间的共享，通过这种方式分配的内存是物理不连续的，这种方式一般用于采用软件绘制的情况，当buffer在客户端绘制完成以后，Compositor得到通知开始合成的时候，需要通过glTexImage2D()函数把buffer作为纹理上传到GPU中，这样的话性能是会受到影响的，因为纹理上传一般是比较耗时的操作。
wl_drm
这种方式通过Wayland EGL中的相关机制来保证，客户端通过wayland-egl.h的相关接口EGLSurface来创建GPU的输出buffer，然后客户端开始绘制，绘制完成以后，客户端的GPU输出buffer通过eglCreateImageKHR()接口创建EGLImage，这个EGLImage可以直接作为Compositor的输入纹理来使用，不需要额外的拷贝工作。

开源的mesa drm实现定义了drm Wayland扩展, 这个时候客户端和Compositor之间可以共享drm (GEM) buffers。

下面介绍一下基于KMS BO buffer type的mesa wl_drm共享流程

0x3 与Android上图形系统的比较

Buffer的分配
Android上的buffer是在服务端（SurfaceFlinger）分配的，然后通过ION机制实现buffer的共享。
而Wayland系统中buffer是在客户端分配的，通过底层EGL驱动提供的buffer共享管理机制，再配合IPC机制实现客户端和服务端之间的buffer共享。
Window管理器的实现
Android上有单独的WMS(Window Manager Service)模块来做窗口管理的工作。而Wayland系统中在Weston中实现了窗口管理的工作，也就是是窗口管理和合成是在同一个进程中完成的。
Android on Wayland
把Android上的SurfaceFlinger作为一个Wayland Client，然后参与Weston的合成。架构图如下

上图的架构有点类似于把X Server作为一个Wayland Client，如下图所示