本篇我们来聊聊关于图形系统的的源码与模块结构。

wayland/weston/libinput等项目源码位于http://cgit.freedesktop.org/wayland下。

Wayland的协议定义在protocol目录，通信协议实现在src目录。它主要编译出三个库，libwayland-client，libwayland-server和libwayland-cursor。第一个为协议的client端实现，第二个为协议的server端实现。第三个是协议中鼠标相关处理实现。编译时会首先编译出wayland-scanner这个可执行文件，它利用expat这个库来解析xml文件，将wayland.xml生成相应的wayland-protocol.c，wayland-client-protocol.h和wayland-server-protocol.h。它们会被Wayland的client和server在编译时用到。同时wayland-scanner也需要在生成Weston中的Wayland扩展协议中起同样作用。

Wayland主要依赖于两个库，一个上面提到的expat协议，另一个libffi用于在跨进程过程调用中根据函数描述生成相应calling convention的跳板代码。

Weston的主要实现在src目录下。与Wayland类似，protocol目录下放着Wayland协议定义。在clients目录下是一些client的例子，也包括了desktop-shell和keyboard等核心client的例子，也包含了如simple-egl, simple-shm, simple-touch等针对性的简单用例。Weston启动过程中会分别加载几个backend：shell backend， render backend和compositor backend。它们分别用于窗口管理，合成渲染和合成内容输出。

由于这些后端都可有不同的实现，为了逻辑上的独立性和结构上的灵活性，他们都编译成动态链接库从而可以在Weston初始化时被加载进来。这种方式在Weston中被广泛采用，一些功能比如屏幕共享等都是以这种形式加载的。

举例来说，compositor backend主要决定了compositor合成完后的结果怎么处置。从数据结构上，weston_output是output设备的抽象，而下面的backend会实现具体的output设备。
• fbdev：直接输出至linux的framebuffer设备。接口通用。
• headless：和noop-renderer配合使用，可以在没有窗口系统的机子（比如server上）测试逻辑。
• RPI：用于Raspberry Pi平台。
• RDP：合成后通过RDP传输到RDP peer显示，用于远程桌面。
• DRM：Direct redering manager，桌面上一般用这个。
• x11：Wayland compositor作为X server的client。它可以让Wayland client运行在X11上。
• wayland：Wayland composiotr作为server同时，也作为另一个Wayland compositor的client。用于nested compositor。

Renderer backend主要用于compositor的合成之用，除去noop-renderer外，有gl-renderer和pixman-renderer两种。前者为GPU硬件渲染，后者为软件渲染。shell backend用于实现具体的窗口管理。相应的实现分别在desktop-shell，fullscreen-shell和ivi-shell目录中。

Wayland/Weston运行时依赖的库主要有下面几个，其相互关系大体如下。

• libEGL, libGLES：本地窗口系统与图形driver的glue layer，mesa提供了开源版本的实现。
• libdrm：封装KMS，GEM等图形相关接口。平台相关。
• libffi：用于在运行时根据调用接口描述生成函数跳板并调用。
• pixman：用于像素操作的库，包括region, box等计算。用了许多平台相关的优化。
• cairo：软件渲染库，类似于skia。也有OpenGL后端。
• libinput：输入处理，依赖于mtdev, libudev, libevdev等库。
• libxkbcommon：主要用于键盘处理。
• libjpeg, libpng, libwebp：用于加载各种图片文件，像壁纸，面板和鼠标等都需要。

渲染流水线

一个Wayland client要将内存渲染到屏幕上，首先要申请一个graphic buffer，绘制完后传给Wayland compositor并通知其重绘。Wayland compositor收集所有Wayland client的请求，然后以一定周期把所有提交的graphic buffer进行合成。合成完后进行输出。本质上，client需要将窗口内容绘制到一个和compositor共享的buffer上。这个buffer可以是普通共享内存，也可以是DRM中的GBM或是gralloc提供的可供硬件（如GPU）操作的graphic buffer。在大多数移动平台上，没有专门的显存，因此它们最终都来自系统内存，区别在于图形加速硬件一般会要求物理连续且符合对齐要求的内存。如果是普通共享内存，一般是物理不连续的，多数情况用于软件渲染。有些图形驱动也支持用物理不连续内存做硬件加速，但效率相对会低一些。根据buffer类型的不同，client可以选择自己绘制，或是通过Cairo，OpenGL绘制，或是更高层的如Qt，GTK+这些widget库等绘制。绘制完后client将buffer的handle传给server，以及需要重绘的区域。在server端，compositor将该buffer转为纹理（如果是共享内存使用glTexImage2D上传纹理，硬件加速buffer用GL_OES_EGL_image_external扩展生成外部纹理）。最后将其与其它的窗口内容进行合成。下面是抽象的流程图。

注意Wayland设计中默认buffer是从client端分配的。这和Android中在server端分配buffer的策略是不同的。这样，client可以自行设计buffer的管理策略。理论上，client可以始终只用一块buffer，但因为这块buffer在client和server同时访问会产生竞争，所以一般client端都会实现buffer queue。流水线上比较关键的一环是buffer跨进程的传输，也就是client和server间的有效传递。buffer当然不可能通过拷贝传输，因此这里只会传handle，本质上是传buffer的fd。我们知道fd是per-process的。而可以传递fd的主要IPC机制有binder, domain socket和pipe等。Wayland底层用的是domain socket，因此可以用于传fd。

在这条流水线上，可以看到，client和server端都会发生绘制。client绘制本地的窗口内容，server端主要用于合成时渲染。注意两边都可独立选择用软件或者硬件渲染。现在的商用设备上，多是硬件加速渲染。和Android上的SurfaceFlinger和Ubuntu上的Mir一样，Wayland同样基于EGL接口。EGL用于将本地窗口系统与OpenGL关联起来，与WGL, GLX等作用类似，只是它是用于Embedded platform的。在Wayland/Weston系统中，Wayland定义了用于EGL的窗口抽象，来作为EGL stack（也就是厂商的图形驱动）和Wayland协议的glue layer。它对EGL进行了扩展，增加了比如eglBindWaylandDisplayWL, eglUnbindWaylandDisplayWL, eglQueryWaylandBufferWL等接口，对Wayland友好的EGL库应该提供它们的实现，也就是说要提供Wayland EGL platform，比如mesa（src/egl/main/eglapi.c中）。另一种做法是像libhybris中eglplatform一样通过EGL wrapper的方式加上这些支持（hybris/egl/platforms/common/eglplatformcommon.cpp）。同时，EGL stack需要提供厂商相关的协议扩展使client能与compositor共享buffer。wayland-egl库提供了Wayland中surface和EGL粘合的作用。一个要用硬件加速的EGL window可以基于Wayland的surface创建，即通过wayland-egl提供的接口创建wl_egl_window。wl_egl_window结构中包含了wl_surface，然后wl_egl_window就可以被传入EGL的eglCreateWindowSurface()接口。这样就将Wayland surface与EGL stack联系在一起了。

关于这模块整体部分介绍就先聊到这里，在后续的博客中我们会详细来介绍窗口管理相关内容。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。