Wayland架构、渲染、硬件支持

文章目录

Wayland 架构
Wayland 渲染
Wayland的硬件支持

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

Wayland 架构

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

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

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

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

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

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

Wayland 渲染

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

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

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

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

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图像。