Wayland架构、渲染、硬件支持

简 述：　翻译一篇关于和 wayland 有关的技术文章, 其英文标题为Wayland Architecture .

Wayland 架构

若是想要更好的理解 Wayland 架构及其与 X (X11 or X Window System) 结构；一种很好的方法是将事件从输入设备就开始跟踪, 查看期间所有的屏幕上出现的变化。

这就是我们现在对 X 的理解。

1. 内核是从一个输入设备中获取一个事件，并通过 evdev 输入驱动将其发送到 X。内核通过驱动设备将不同设备的事件协议翻译成 linux evdev 输入事件标准，依靠此来完成所有的工作。
2. X 服务器确定事件影响到哪个窗口，并将其发送给在该窗口上选择了相关事件的客户端。X 服务器实际上并不知道如何正确地做这件事，因为窗口在屏幕上的位置是由合成器控制的，并且可能会以很多 X 服务器不理解的方式进行转换（缩小、旋转、晃动等）。
3. 客户端依据这个事件决定该如何操作。通常情况下，UI 通常根据事件来改变，也许是一个复选框被点击了，或者指向了一个必须被显示的按钮。因此，客户端会向X服务器发送一个渲染请求。
4. 当X服务器收到渲染请求时，它将其发送给驱动程序，让它对硬件进行编程以进行渲染。X服务器还计算出渲染的边界区域，并将其作为damage事件发送给合成器。
5. damage事件告诉合成器，窗口中发生了一些变化，它必须重新合成该窗口可见的屏幕部分。合成器负责根据它的场景图和X窗口的内容来渲染整个屏幕内容。且它是必须通过X服务器来渲染。
6. X服务器接收到来自合成器的渲染请求后，要么将合成器的后缓冲区复制到前缓冲区，要么进行翻页。在一般情况下，X服务器必须做这一步，这样它就可以考虑到重叠的窗口，这可能需要剪接，并确定是否可以翻页。然而，对于一个总是全屏的合成器来说，这又是一个不必要的上下文切换。

如上所述，这种方法都有瑕疵。X服务器没有信息来决定哪个窗口应该接收事件，也不能将屏幕坐标转换为窗口局部坐标。而且即使X已经把最终绘制屏幕的责任交给了合成管理器，X仍然控制着前面的缓冲区和模式设置。过去X服务器处理的大部分复杂问题，现在都可以在内核或自带的库中找到（KMS、evdev、mesa、fontconfig、freetype、cairo、Qt等）。总的来说，X服务器现在只是一个中间人，在应用程序和合成器之间多引入了一步，在合成器和硬件之间多引入了一步。

在wayland中，合成器就是显示服务器。我们把KMS和evdev的控制权转移到合成器上。wayland协议让合成器直接向客户端发送输入事件，让客户端直接向合成器发送损坏事件。

1. 内核获得一个事件并将其发送到合成器。这类似于X的情况，这很好，因为我们可以重复使用内核中所有的输入驱动。
2. 合成器通过它的场景图来决定哪个窗口应该接收这个事件。场景图对应于屏幕上的内容，而合成器了解它可能已经对场景图中的元素转换。因此合成器可以选择合适的窗口，并通过应用逆向变换，将屏幕坐标转换为窗口局部坐标。只要能计算出输入事件的逆向变换，就可以应用于窗口的变换类型只限于合成器能做的事情。
3. 如在X案例中，当客户端接收到事件时，它会更新UI作为响应。但在wayland的情况下，渲染发生在客户端，客户端只需向合成器发送一个请求，指示被更新的区域。
4. 合成器收集客户端的damage请求，然后重新合成屏幕效果。且合成器可以直接发出ioctl，与KMS一起进行翻页。

Wayland 渲染

在上面的概述中，有漏掉了一个细节，那就是客户端在wayland下究竟是如何渲染的。通过将X服务器从画面中移除，我们也移除了X客户端通常的渲染机制。但是我们在X下的DRI2已经使用了另一种机制：直接渲染。通过直接渲染，客户端和服务器共享一个视频内存缓冲区。客户端链接到一个渲染库，比如OpenGL，它知道如何对硬件进行编程，并直接渲染到缓冲区。而合成器则可以在合成桌面时，将缓冲区作为纹理使用。在初始设置之后，客户端只需要告诉合成器使用哪个缓冲区，以及何时何地的将新内容渲染到缓冲区中。

这就给应用程序留下了两种更新窗口内容的方法：

1. 把新的内容渲染到一个新的缓冲区里 然后告诉合成器使用哪个缓冲区来代替旧的缓冲区。应用程序可以在每次需要更新窗口内容时分配一个新的缓冲区，也可以保留两个（或更多）缓冲区并在它们之间循环。缓冲区的管理完全由应用程序控制。
2. 将新的内容渲染之前告诉合成器使用的缓冲区。虽然可以直接渲染到合成器共享的缓冲区中，但这可能会与合成器发生竞赛。可能发生的情况是，重新绘制窗口内容可能会被合成器重新绘制桌面所中断。如果应用程序在清除窗口后但在渲染内容之前被打断，那么合成器将从一个空白缓冲区中进行纹理处理。其结果是，应用程序窗口将在空白窗口或半渲染的内容之间闪烁。避免这种情况的传统方法是将新的内容渲染到后置缓冲区，然后从那里复制到合成器表面。后面的缓冲区可以即时分配，并且刚好足够容纳新内容，或者应用程序可以保留一个缓冲区。同样这也是由应用程序所控制的。

无论在哪种情况下，应用程序都必须告诉合成器表面的哪个区域存放新内容。当应用程序直接渲染到共享缓冲区时，需要注意到合成器有新内容。但在交换缓冲区时，合成器也不会认为有什么变化，只有需要应用程序提出请求才会重新绘制桌面。即使应用程序传递给合成器一个新的缓冲区，也可能只有一小部分缓冲区是不同的，比如一个闪烁的光标或一个旋转器。

Wayland的 硬件支持

通常情况下，硬件启用包括 modesetting / display 和 EGL / GLES2。除此之外，Wayland还需要一种在进程之间高效共享缓冲区的方式。这有两个方面，客户端和服务器端。

在客户端，我们定义了一个Wayland EGL平台。在EGL模型中，它由原生类型（EGLNativeDisplayType、EGLNativeWindowType和EGLNativePixmapType）和创建这些类型的方法组成。换句话说，它是将EGL栈及其缓冲区共享机制与通用Wayland API绑定的耦合代码。EGL堆栈有望提供Wayland EGL平台的实现。完整的API在wayland-egl.h头中。mesa EGL协议栈中的开源实现在platform_wayland.c中

在引擎下，EGL堆栈寄希望于被一个特定厂商的协议扩展所定义，让客户端EGL堆栈与合成器通信缓冲区细节，以及共享缓冲区。wayland-egl.h API的意义在于将这些抽象掉，让客户端为Wayland曲面创建一个EGLSurface并开始渲染。开源栈使用了 drm Wayland 扩展，让客户端发现要使用的 drm 设备并进行认证，然后与合成器共享 drm（GEM）缓冲区。

Wayland的服务器端是垂直领域的合成器和核心用户体验，典型的是将任务切换器、应用启动器、锁屏整合在一个单体应用中。服务器运行在模式设置 API（内核模式设置、OpenWF Display或类似）之上，并使 EGL / GLES2 合成器和硬件覆盖（如果有的话）混合合成最终的UI。启用模式设置、EGL/GLES2和覆盖是标准硬件启动的一部分。启用Wayland的额外要求是EGL_WL_bind_wayland_display扩展，它允许合成器从通用Wayland共享缓冲区创建EGLImage。它类似于EGL_KHR_image_pixmap扩展，可从X像素图创建EGLImage。

该扩展有一个设置步骤，您必须将EGL显示与Wayland显示绑定。然后当合成器从客户端接收通用的Wayland缓冲区时（通常在客户端调用eglSwapBuffers时），它将能够将结构wl_buffer指针传递给eglCreateImageKHR作为EGLClientBuffer参数，并以EGL_WAYLAND_BUFFER_WL作为目标。这将创建一个EGLImage，它可以被合成器用作纹理，或传递给模式设置代码作为覆盖平面使用。同样这是由厂商特定的协议扩展来实现的，在服务器端，它将接收驱动程序关于共享缓冲区的具体细节，并在用户调用eglCreateImageKHR时将其转化为EGL图像。