source code：https://git.sr.ht/~sircmpwn/wayland-book
本文内容均节选自 《The Wayland Book》
High-level design
Your computer has input and output devices, which respectively are responsible for receiving information from you and displaying information to you. These input devices take the form of, for example: ? Keyboards ? Mice ? Touchpads ? Touch screens ? Drawing tablets Your output devices generally take the form of displays, on your desk or your laptop or mobile device. These resources are shared between all of your applications, and the role of the Wayland compositor is to dispatch input events to the appropriate Wayland client and to display their windows in their appropriate place on your outputs. The process of bringing together all of your application windows for display on an output is called compositing - and thus we call the software which does this the compositor[weston...]
你的计算机有输入和输出设备，分别负责接收信息和显示信息。这些输入设备的形式，例如:键盘、鼠标、触控板、触摸屏、绘图板。你的输出设备通常采取显示器的形式，在你的桌面电脑，你的笔记本电脑或移动设备上。这些资源在所有应用程序之间共享，Wayland compositor的角色是将输入事件分派到适当的Wayland客户端，并在输出设备的适当位置显示它们的窗口。把你所有的应用窗口放在一起以显示在一个输出上的过程叫做合成——因此我们称做这个的软件为合成器
There are many distinct software components in desktop ecosystem. There are tools like mesa for rendering (and each of its drivers), the Linux KMS/DRM subsystem, buffer allocation with GBM, the userspace libdrm library, libinput and evdev, and much more still.
桌面生态系统中有许多不同的软件组件。有像mesa这样用于渲染的工具(以及它的每个驱动程序)、Linux KMS/DRM子系统、GBM的缓冲区分配、用户空间libdrm库、libinput和evdev等等。
The kernel
This responsibility falls onto the kernel. The kernel is a complex beast, so we'll focus on only the parts which are relevant to Wayland. Linux's job is to provide an abstraction over your hardware, so that they can be safely accessed by userspace - where our Wayland compositors run. For graphics, this is called DRM , or direct rendering manager , for efficiently tasking the GPU with work from userspace. An important subsystem of DRM is KMS , or kernel mode setting , for enumerating your displays and setting properties such as their selected resolution (also known as their "mode"). Input devices are abstracted through an interface called evdev . Most kernel interfaces are made available to userspace by way of special files in /dev . In the case of DRM, these files are in /dev/dri/ , usually in the form of a primary node (e.g. card0 ) for privileged operations like modesetting, and a render node (e.g. renderD128 ), for unprivileged operations like rendering or video decoding. For evdev, the "device nodes" are /dev/input/event*。
这个责任落到了内核身上。内核是一个复杂的怪兽，所以我们将只关注与Wayland相关的部分。Linux的工作是为你的硬件提供一个抽象，这样它们就可以被用户空间——我们的Wayland组合程序运行的地方——安全地访问。对于图形，这被称为DRM，或直接渲染管理器，有效地向GPU分配用户空间的工作。DRM的一个重要子系统是KMS，即内核模式设置，用于枚举显示和设置属性，比如它们所选择的分辨率(也称为它们的“模式”)。输入设备通过一个名为evdev的接口进行抽象。大多数内核接口通过/dev中的特殊文件对用户空间可用。在DRM的情况下，这些文件在/dev/dri/中，通常以主节点(例如card0)的形式，用于modesetting等特权操作，以及渲染节点(例如renderD128)，用于渲染或视频解码等非特权操作。对于evdev，“设备节点”是/dev/input/event*。
Userspace
Now, we enter userspace. Here, applications are isolated from the hardware and must work via the device nodes provided by the kernel.
- libdrm
- Most Linux interfaces have a userspace counterpart which provides a pleasant(ish) C API for working with these device nodes. One such library is libdrm, which is the userspace portion of the DRM subsystem. libdrm is used by Wayland compositors to do modesetting and other DRM operations, but is generally not used by Wayland clients directly.
- Mesa
- Mesa is one of the most important parts of the Linux graphics stack. It provides, among other things, vendor-optimized implementations of OpenGL (and Vulkan) for Linux and the GBM (Generic Buffer Management) library - an abstraction on top of libdrm for allocating buffers on the GPU. Most Wayland compositors will use both GBM and OpenGL via Mesa, and most Wayland clients will use at least its OpenGL or Vulkan implementations.
- libinput
- Like libdrm abstracts the DRM subsystem, libinput provides the userspace end of evdev. It's responsible for receiving input events from the kernel from your various input devices, decoding them into a usable form, and passing them on to the Wayland compositor. The Wayland compositor requires special permissions to use the evdev files, forcing Wayland clients to go through the compositor to receive input events - which, for example, prevents keylogging.
- (e)udev
- Dealing with the appearance of new devices from the kernel, configuring permissions for the resulting device nodes in /dev , and sending word of these changes to applications running on your system, is a responsibility that falls onto userspace. Most systems use udev (or eudev, a fork) for this purpose. Your Wayland compositor uses udev to enumerate input devices and GPUs, and to receive notifications when new ones appear or old ones are unplugged.[听起来就像android的eventhub/getevent]
- xkbcommon
- XKB, short for X keyboard, is the original keyboard handling subsystem of the Xorg server. Several years ago, it was extracted from the Xorg tree and made into an independent library for keyboard handling, and it no longer has any practical relationship with X. Libinput (along with the Wayland compositor) delivers keyboard events in the form of scancodes, whose precise meaning varies from keyboard to keyboard. It's the responsibility of xkbcommon to translate these scan codes into meaningful and generic key "symbols" - for example, converting 65 to XKB_KEY_Space . It also contains a state machine which knows that pressing "1" while shift is held emits "!".[听起来像是android里面的input mapper]
- pixman
- A simple library used by clients and compositors alike for efficiently manipulating pixel buffers, doing math with intersecting rectangles, and performing other similar pix el man ipulation tasks.
- libwayland
- libwayland the most commonly used implementation of the Wayland protocol, is written in C, and handles much of the low-level wire protocol. It also provides a tool which generates high-level code from Wayland protocol definitions (which are XML files).
- ...