Wayland Architecture _合成器

翻译于:
理解架构及其与X的不同之处的一种好方法是跟踪事件从"输入设备到屏幕上"出现的变化。
这就是我们现在使用的X的逻辑架构：

文章插图
内核从输入设备获取事件，然后通过evdev输入驱动程序将其发送到X 。内核通过驱动设备并将不同的设备事件转换为linux evdev输入标准事件来完成所有的艰难工作。X服务器确认事件影响哪个窗口，并将其发送到在该窗口上为该事件选择的客户端。X服务器实际上并不知道如何正确执行此操作，因为屏幕上的窗口位置是由合成器控制的，并且可能以X服务器无法理解的多种方式进行转换（缩小，旋转，摆动，等等）。客户端查看事件并决定要做什么。UI通常必须响应事件而改变-也许单击了复选框或指针输入了必须突出显示的按钮。因此，客户端将渲染请求发送回X服务器。X服务器接收到渲染请求后，会将其发送给驱动程序，以使其对硬件进行编程以进行渲染。X服务器还计算渲染的边界区域，并将其作为事件发送到合成器。//比麻烦的地方，绘画要通过传给事件告诉合成器窗口中发生了某些更改，并且必须重新合成可见该窗口的屏幕部分。合成器负责根据其场景图和X窗口的内容渲染整个屏幕内容。但是，它必须通过X服务器来呈现它。X服务器从合成器接收渲染请求，然后将合成器后缓冲区复制到前缓冲区或进行页面翻转。在一般情况下，X服务器必须执行此步骤，以便它可以考虑重叠的窗口，这可能需要裁剪并确定是否可以翻页。但是，对于始终为全屏显示的合成器，这是另一个不必要的上下文切换。
如上所述，这种方法存在一些问题。X服务器没有信息来决定哪个窗口应该接收事件，它也不能将屏幕坐标转换为窗口局部坐标。尽管X已将屏幕的最终绘制工作移交给了合成管理器，但X仍控制着前缓冲区和模式设置。X服务器用来处理的大多数复杂性现在都可以在内核或自包含的库中找到（KMS，evdev，mesa，，，cairo，Qt等）。通常，X服务器现在只是一个中间人，它在应用程序和合成器之间引入了一个额外的步骤，在合成器和硬件之间引入了一个额外的步骤。
【Wayland Architecture】在中，合成器是显示服务器。我们将KMS和evdev的控制权转移给合成器。协议允许合成器将输入事件直接发送到客户端，并让客户端将事件直接发送到合成器：

文章插图
内核获取一个事件，并将其发送到合成器。这与X情况类似，这非常好，因为我们可以重用内核中的所有输入驱动程序。合成器通过其场景图进行查看，以确定应该接收该事件的窗口。场景图与屏幕上的内容相对应，并且合成器了解它可能已应用于场景图中的元素的转换。因此，合成器可以选择右窗口，并通过应用逆变换将屏幕坐标转换为窗口局部坐标。可以应用于窗口的转换类型仅限于合成器可以执行的操作，只要它可以计算输入事件的逆转换即可。与X情况一样，当客户端收到事件时，它会更新UI作为响应。但是在中，渲染发生在客户端中，并且客户端只是向合成器发送请求以指示已更新的区域。合成器从其客户端收集请求，然后重新合成屏幕。然后，合成器可以直接发出ioctl来调度带有KMS的翻页。
在上面的概述中，我遗漏的细节之一是客户在下的实际渲染方式。通过从图片中删除X服务器，我们还删除了X客户端通常呈现的机制。但是，我们已经在X下的DRI2中使用了另一种机制：直接渲染。通过直接渲染，客户端和服务器共享内存缓冲区。客户端链接到诸如之类的渲染库，该库知道如何对硬件进行编程并将其直接渲染到缓冲区中。当合成器合成桌面时，合成器又可以获取该缓冲区并将其用作纹理。初始设置后，客户端仅需要告诉合成器要使用哪个缓冲区以及何时何地向其提交了新内容。