Wayland 1.3 官方文档：显示服务器与协议详解

5星 · 超过95%的资源需积分: 50 16 浏览量更新于2024-07-23 收藏 496KB PDF 举报

"wayland-1.3-doc是Wayland显示服务器的官方文档，由Kristian Høgsberg编写，涵盖了Wayland框架的详细介绍、协议定义以及相关函数的实现等内容。文档版本为1.3，提供了对软件使用的许可，允许在遵守版权条件下自由使用、复制、修改和分发。" Wayland是一个现代的图形显示服务器协议，它的设计目标是提供一个安全、高效且易于扩展的框架，用于管理操作系统中的图形输出、输入设备和其他相关的显示功能。与X Window System相比，Wayland通常被认为更加简洁和安全，因为它避免了X11中的一些安全问题，如权限过于开放和复杂的客户端-服务器通信模型。在Wayland协议中，核心概念是"显示服务器"（通常是名为Wayland的进程）和"客户端"应用程序之间的通信。协议定义了各种消息，这些消息允许客户端请求显示资源、接收用户输入事件并进行渲染。例如，Wayland协议包括创建窗口、处理键盘和鼠标事件、共享像素缓冲区以及实现复合窗口管理等操作。文档中的"函数实现"部分可能详细介绍了C语言库libwayland，它是开发Wayland客户端和服务器的基础。开发者可以使用这个库来实现与Wayland服务器的交互，包括创建和管理表面、交换缓冲区、处理事件等。libwayland还提供了对Wayland协议扩展的支持，允许添加自定义的协议元素以满足特定需求。 Wayland系统通常包含多个组件，如Wayland服务器、Wayland客户端、 compositor（组合器）和各种协议插件。Compositor负责将客户端的表面组合成最终的屏幕图像，并处理窗口管理任务，如排列、最大化、最小化等。Weston是Wayland的一个参考实现，它包含了基本的compositor功能，开发者可以基于Weston构建自己的定制化桌面环境。 Wayland的安全性体现在其严格的权限控制上。每个客户端都在自己的进程中运行，并且只能访问它被授权的资源。这有助于防止恶意软件通过图形接口获取系统敏感信息或进行攻击。 "wayland-1.3-doc"为开发者和系统集成者提供了深入理解Wayland协议及其实现所需的知识，是构建和维护Wayland环境的关键参考资料。通过学习这份文档，读者能够掌握如何有效地利用Wayland来构建安全、高效的图形用户界面。

Chapter 3. Wayland Architecture

rendering the entire screen contents based on its scenegraph and the contents of the X windows.

Yet, it has to go through the X server to render this.

6. The X server receives the rendering requests from the compositor and either copies the

compositor back buffer to the front buffer or does a pageflip. In the general case, the X server

has to do this step so it can account for overlapping windows, which may require clipping and

determine whether or not it can page flip. However, for a compositor, which is always fullscreen,

this is another unnecessary context switch.

As suggested above, there are a few problems with this approach. The X server doesn't have

the information to decide which window should receive the event, nor can it transform the screen

coordinates to window local coordinates. And even though X has handed responsibility for the final

painting of the screen to the compositing manager, X still controls the front buffer and modesetting.

Most of the complexity that the X server used to handle is now available in the kernel or self contained

libraries (KMS, evdev, mesa, fontconfig, freetype, cairo, Qt etc). In general, the X server is now just a

middle man that introduces an extra step between applications and the compositor and an extra step

between the compositor and the hardware.

In Wayland the compositor is the display server. We transfer the control of KMS and evdev to the

compositor. The Wayland protocol lets the compositor send the input events directly to the clients and

lets the client send the damage event directly to the compositor:

1. The kernel gets an event and sends it to the compositor. This is similar to the X case, which is

great, since we get to reuse all the input drivers in the kernel.

2. The compositor looks through its scenegraph to determine which window should receive the

event. The scenegraph corresponds to what's on screen and the compositor understands the

transformations that it may have applied to the elements in the scenegraph. Thus, the compositor

can pick the right window and transform the screen coordinates to window local coordinates,

by applying the inverse transformations. The types of transformation that can be applied to a

Wayland Rendering

window is only restricted to what the compositor can do, as long as it can compute the inverse

transformation for the input events.

3. As in the X case, when the client receives the event, it updates the UI in response. But in the

Wayland case, the rendering happens in the client, and the client just sends a request to the

compositor to indicate the region that was updated.

4. The compositor collects damage requests from its clients and then recomposites the screen. The

compositor can then directly issue an ioctl to schedule a pageflip with KMS.

3.2. Wayland Rendering

One of the details I left out in the above overview is how clients actually render under Wayland. By

removing the X server from the picture we also removed the mechanism by which X clients typically

render. But there's another mechanism that we're already using with DRI2 under X: direct rendering.

With direct rendering, the client and the server share a video memory buffer. The client links to a

rendering library such as OpenGL that knows how to program the hardware and renders directly into

the buffer. The compositor in turn can take the buffer and use it as a texture when it composites the

desktop. After the initial setup, the client only needs to tell the compositor which buffer to use and

when and where it has rendered new content into it.

This leaves an application with two ways to update its window contents:

1. Render the new content into a new buffer and tell the compositor to use that instead of the

old buffer. The application can allocate a new buffer every time it needs to update the window

contents or it can keep two (or more) buffers around and cycle between them. The buffer

management is entirely under application control.

2. Render the new content into the buffer that it previously told the compositor to to use. While it's

possible to just render directly into the buffer shared with the compositor, this might race with

the compositor. What can happen is that repainting the window contents could be interrupted by

the compositor repainting the desktop. If the application gets interrupted just after clearing the

window but before rendering the contents, the compositor will texture from a blank buffer. The

result is that the application window will flicker between a blank window or half-rendered content.

The traditional way to avoid this is to render the new content into a back buffer and then copy

from there into the compositor surface. The back buffer can be allocated on the fly and just big

enough to hold the new content, or the application can keep a buffer around. Again, this is under

application control.

In either case, the application must tell the compositor which area of the surface holds new contents.

When the application renders directly to the shared buffer, the compositor needs to be noticed that

there is new content. But also when exchanging buffers, the compositor doesn't assume anything

changed, and needs a request from the application before it will repaint the desktop. The idea that

even if an application passes a new buffer to the compositor, only a small part of the buffer may be

different, like a blinking cursor or a spinner.

3.3. Hardware Enabling for Wayland

Typically, hardware enabling includes modesetting/display and EGL/GLES2. On top of that Wayland

needs a way to share buffers efficiently between processes. There are two sides to that, the client side

and the server side.

On the client side we've defined a Wayland EGL platform. In the EGL model, that consists of the

native types (EGLNativeDisplayType, EGLNativeWindowType and EGLNativePixmapType) and

a way to create those types. In other words, it's the glue code that binds the EGL stack and its

Chapter 3. Wayland Architecture

buffer sharing mechanism to the generic Wayland API. The EGL stack is expected to provide an

implementation of the Wayland EGL platform. The full API is in the wayland-egl.h header. The open

source implementation in the mesa EGL stack is in wayland-egl.c and platform_wayland.c.

Under the hood, the EGL stack is expected to define a vendor-specific protocol extension that lets the

client side EGL stack communicate buffer details with the compositor in order to share buffers. The

point of the wayland-egl.h API is to abstract that away and just let the client create an EGLSurface

for a Wayland surface and start rendering. The open source stack uses the drm Wayland extension,

which lets the client discover the drm device to use and authenticate and then share drm (GEM)

buffers with the compositor.

The server side of Wayland is the compositor and core UX for the vertical, typically integrating

task switcher, app launcher, lock screen in one monolithic application. The server runs on top of a

modesetting API (kernel modesetting, OpenWF Display or similar) and composites the final UI using a

mix of EGL/GLES2 compositor and hardware overlays if available. Enabling modesetting, EGL/GLES2

and overlays is something that should be part of standard hardware bringup. The extra requirement

for Wayland enabling is the EGL_WL_bind_wayland_display extension that lets the compositor create

an EGLImage from a generic Wayland shared buffer. It's similar to the EGL_KHR_image_pixmap

extension to create an EGLImage from an X pixmap.

The extension has a setup step where you have to bind the EGL display to a Wayland display. Then

as the compositor receives generic Wayland buffers from the clients (typically when the client calls

eglSwapBuffers), it will be able to pass the struct wl_buffer pointer to eglCreateImageKHR as the

EGLClientBuffer argument and with EGL_WAYLAND_BUFFER_WL as the target. This will create an

EGLImage, which can then be used by the compositor as a texture or passed to the modesetting code

to use as an overlay plane. Again, this is implemented by the vendor specific protocol extension, which

on the server side will receive the driver specific details about the shared buffer and turn that into an

EGL image when the user calls eglCreateImageKHR.

Chapter 4.

Wayland Protocol and Model of

Operation

4.1. Basic Principles

The Wayland protocol is an asynchronous object oriented protocol. All requests are method

invocations on some object. The requests include an object ID that uniquely identifies an object on the

server. Each object implements an interface and the requests include an opcode that identifies which

method in the interface to invoke.

The server sends back events to the client, each event is emitted from an object. Events can be

error conditions. The event includes the object ID and the event opcode, from which the client can

determine the type of event. Events are generated both in response to requests (in which case the

request and the event constitutes a round trip) or spontaneously when the server state changes.

• State is broadcast on connect, events are sent out when state changes. Clients must listen for these

changes and cache the state. There is no need (or mechanism) to query server state.

• The server will broadcast the presence of a number of global objects, which in turn will broadcast

their current state.

4.2. Code Generation

The interfaces, requests and events are defined in protocol/wayland.xml. This xml is used to

generate the function prototypes that can be used by clients and compositors.

The protocol entry points are generated as inline functions which just wrap the wl_proxy_* functions.

The inline functions aren't part of the library ABI and language bindings should generate their own

stubs for the protocol entry points from the xml.

4.3. Wire Format

The protocol is sent over a UNIX domain stream socket, where the endpoint usually is named

wayland-0 (although it can be changed via WAYLAND_DISPLAY in the environment). The protocol

is message-based. A message sent by a client to the server is called request. A message from the

server to a client is called event. Every message is structured as 32-bit words, values are represented

in the host's byte-order.

The message header has 2 words in it:

• The first word is the sender's object ID (32-bit).

• The second has 2 parts of 16-bit. The upper 16-bits are the message size in bytes, starting at the

header (i.e. it has a minimum value of 8).The lower is the request/event opcode.

The payload describes the request/event arguments. Every argument is always aligned to 32-bits.

Where padding is required, the value of padding bytes is undefined. There is no prefix that describes

the type, but it is inferred implicitly from the xml specification.

The representation of argument types are as follows:

int, uint

The value is the 32-bit value of the signed/unsigned int.

Chapter 4. Wayland Protocol and Model of Operation

fixed

Signed 24.8 decimal numbers. It is a signed decimal type which offers a sign bit, 23 bits of integer

precision and 8 bits of decimal precision. This is exposed as an opaque struct with conversion

helpers to and from double and int on the C API side.

string

Starts with an unsigned 32-bit length, followed by the string contents, including terminating null

byte, then padding to a 32-bit boundary.

object

32-bit object ID.

new_id

The 32-bit object ID. On requests, the client decides the ID. The only events with new_id are

advertisements of globals, and the server will use IDs below 0x10000.

array

Starts with 32-bit array size in bytes, followed by the array contents verbatim, and finally padding

to a 32-bit boundary.

The file descriptor is not stored in the message buffer, but in the ancillary data of the UNIX domain

socket message (msg_control).

4.4. Interfaces

The protocol includes several interfaces which are used for interacting with the server. Each interface

provides requests, events, and errors (which are really just special events) as described above.

Specific compositor implementations may have their own interfaces provided as extensions, but there

are several which are always expected to be present.

Core interfaces:

wl_display - core global object

The core global object. This is a special singleton object. It is used for internal Wayland protocol

features.

wl_registry - global registry object

The global registry object. The server has a number of global objects that are available to all

clients. These objects typically represent an actual object in the server (for example, an input

device) or they are singleton objects that provide extension functionality. When a client creates a

registry object, the registry object will emit a global event for each global currently in the registry.

Globals come and go as a result of device or monitor hotplugs, reconfiguration or other events,

and the registry will send out global and global_remove events to keep the client up to date with

the changes. To mark the end of the initial burst of events, the client can use the wl_display.sync

request immediately after calling wl_display.get_registry. A client can bind to a global object by

using the bind request. This creates a client-side handle that lets the object emit events to the

client and lets the client invoke requests on the object.

wl_callback - callback object

Clients can handle the 'done' event to get notified when the related request is done.

wl_compositor - the compositor singleton

A compositor. This object is a singleton global. The compositor is in charge of combining the

contents of multiple surfaces into one displayable output.

剩余85页未读，继续阅读

madMrz

粉丝: 0
资源: 1

Wayland 1.3 官方文档：显示服务器与协议详解

awesome-wayland:精选的Wayland代码和资源清单

wayland v1.3协议说明

wayland-doc-1.15.0-1.el7.noarch.rpm

pkg-config --modversion wayland-server Package wayland-server was not found in the pkg-config search path. Perhaps you should add the directory containing `wayland-server.pc' to the PKG_CONFIG_PATH environment variable No package 'wayland-server' found

available platform plugins are: xcb, eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl.

available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, webgl, xcb.

ubuntu 如何 查看wayland-server wayland-client的版本

qt5-qtwayland-doc-5.9.7-1.el7.noarch.rpm

qtwayland-everywhere-src-6.6.0.zip

qtwayland-everywhere-src-6.8.0.zip

最新资源

ubuntu 如何查看wayland-server wayland-client的版本