Wayland 1.3协议详解及应用

wayland

weston

需积分: 30 123 浏览量更新于2024-06-27 1 收藏 498KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"wayland v1.3协议说明" Wayland是一个开源的显示服务器协议，由Kristian Høgsberg创建，旨在提供一种安全、高效且易于扩展的图形系统接口。它被设计用来替代X Window System，以解决X11在现代操作系统中的某些局限性，特别是在安全性、性能和用户体验方面。 Wayland协议是Wayland显示服务器的核心部分，它定义了客户端应用程序与显示服务器之间的通信方式。在v1.3版本中，这个协议已经相当成熟，包含了各种功能和改进，以支持更丰富的图形环境。协议文档详细介绍了Wayland协议的结构、消息交换机制以及如何处理各种图形和输入事件。 Weston是Wayland的参考实现，它是一个轻量级的桌面 compositor。Weston不仅用于测试和验证Wayland协议，还为其他桌面环境提供了基础，例如KDE Plasma和GNOME可以基于Weston构建自己的显示栈。Weston自身包含了对多种输入设备的支持，包括鼠标、键盘和触摸屏，并且能够处理窗口管理、图层合成和硬件加速等功能。在Wayland协议中，核心概念包括“席位”（Seat）和“表面”（Surface）。席位代表了一个或多个输入设备（如键盘和鼠标），而表面则代表了屏幕上的一块可绘图区域。客户端通过创建和操作表面来显示内容，而服务器则负责管理这些表面的排列、组合和渲染。此外，协议还定义了“缓冲区”（Buffer）的概念，缓冲区包含了要显示的实际像素数据，它们可以被绑定到表面，并通过同步机制确保正确地呈现。 Wayland协议的一个关键特性是其“安全”设计。它通过严格的权限控制和严格的对象所有权模型，防止了恶意软件可能利用的某些攻击途径。此外，Wayland还支持高效的GPU硬件加速，通过使用OpenGL或 Vulkan等图形API，可以显著提高图形性能。 Wayland v1.3协议还引入了一些新特性和改进，例如更好的多显示器支持、更精细的输入设备处理以及对高动态范围（HDR）显示的支持。这些更新使得Wayland更加适应现代操作系统的需求，为用户提供更流畅、更安全的图形体验。 Wayland v1.3协议是现代Linux系统中图形栈的重要组成部分，它的设计和实现对于理解现代桌面环境的底层工作原理至关重要。通过阅读其文档，开发者可以学习如何编写兼容Wayland的客户端应用，或者开发自己的Wayland compositor，以满足特定的桌面环境需求。

资源详情

资源推荐

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页未读，继续阅读

搬砖的日子～

粉丝: 8
资源: 13

会员权益专享

Wayland 1.3协议详解及应用

wayland-1.3-doc

Wayland的核心协议，xml

wayland 源码

Wayland协议的缺陷

wayland-scanner升级版本

wayland又怎么将数据传递到framebuffer？

wayland可能存在的问题

wayland+to+run+on+wayland+way

qtwayland历史

驱动通过input子系统上传数据，中间是怎么跟udev和wayland作交互的？怎么才能到达QT应用？

支持wayland的浏览器

rustdesk wayland

ubuntu的wayland-scanner版本升级

wayland怎么将触摸屏上传的数据转换成QT需要的格式？

QT开发怎么使用Wayland编写

Chromium与weston以及wayland的关系

解释：export WAYLAND_DISPLAY=wayland-1

Linux的Wayland协议和Weston怎么设置使用触屏输入

linux安装wayland

wayland在上述过程有参与数据交互吗

会员权益专享

最新资源