Wayland architecture
Introduction
Motivation
Most Linux and Unix-based systems rely on the X Window System (or simply X) as the low-level protocol for building bitmap graphics interfaces. On these systems, the X stack has grown to encompass functionality arguably belonging in client libraries, helper libraries, or the host operating system kernel.
X has grown to incorporate modern features like offscreen rendering and scene composition, but subject to the limitations of the X architecture. For example, the X implementation of composition adds additional context switches and makes things like input redirection difficult.
Over time, X developers came to understand the shortcomings of this approach and worked to split things up. Over the past several years, a lot of functionality has moved out of the X server and into client-side libraries or kernel drivers. One of the first components to move out was font rendering, with freetype and fontconfig providing an alternative to the core X fonts. Direct rendering OpenGL as a graphics driver in a client side library went through some iterations, ending up as DRI2, which abstracted most of the direct rendering buffer management from client code. Then cairo came along and provided a modern 2D rendering library independent of X, and compositing managers took over control of the rendering of the desktop as toolkits like GTK+ and Qt moved away from using X APIs for rendering. Recently, memory and display management have moved to the Linux kernel, further reducing the scope of X and its driver stack. The end result is a highly modular graphics stack.
Wayland
Wayland is a new display server and compositing protocol, and Weston is the implementation of this protocol which builds on top of all the components above.
Overall, the philosophy of Wayland is to provide clients with a way to manage windows and how their contents is displayed. Rendering is left to clients, and system wide memory management interfaces are used to pass buffer handles between clients and the compositing manager.
The figure above illustrates how Wayland clients interact with a Wayland server. Note that window management and composition are handled entirely in the server, significantly reducing complexity while marginally improving performance through reduced context switching. The resulting system is easier to build and extend than a similar X system, because often changes need only be made in one place. Or in the case of protocol extensions, two (rather than 3 or 4 in the X case where window management and/or composition handling may also need to be updated).
Wayland compositors
System Compositor
A system compositor can run from early boot until shutdown. It effectively replaces the kernel vt system, and can tie in with the systems graphical boot setup and multiseat support.
A system compositor can host different types of session compositors, and let us switch between multiple sessions (fast user switching, or secure/personal desktop switching).
A linux implementation of a system compositor will typically use libudev, egl, kms, evdev and cairo.
For fullscreen clients, the system compositor can reprogram the video scanout address to read directly from the client provided buffer.
Session Compositor
A session compositor is responsible for a single user session. If a system compositor is present, the session compositor will run nested under the system compositor. Nesting is feasible because the protocol is asynchronous; roundtrips would be too expensive when nesting is involved. If no system compositor is present, a session compositor can run directly on the hw.
X applications can continue working under a session compositor by means of a root-less X server that is activated on demand.
Possible examples for session compositors include
- gnome-shell
- moblin
- kwin
- kmscon
- rdp session
- Weston with X11 or Wayland backend is a session compositor nested in another session compositor.
- fullscreen X session under Wayland
Embedding Compositor
X11 lets clients embed windows from other clients, or lets clients copy pixmap contents rendered by another client into their window. This is often used for applets in a panel, browser plugins and similar. Wayland doesn't directly allow this, but clients can communicate GEM buffer names out-of-band, for example, using D-Bus, or command line arguments when the panel launches the applet. Another option is to use a nested Wayland instance. For this, the Wayland server will have to be a library that the host application links to. The host application will then pass the Wayland server socket name to the embedded application, and will need to implement the Wayland compositor interface. The host application composites the client surfaces as part of it's window, that is, in the web page or in the panel. The benefit of nesting the Wayland server is that it provides the requests the embedded client needs to inform the host about buffer updates and a mechanism for forwarding input events from the host application.
An example for this kind of setup is firefox embedding the flash player as a kind of special-purpose compositor.
Wayland Architecture
Figure 3.1. X architecture diagram
The kernel gets an event from an input device and sends it to X through the evdev input driver. The kernel does all the hard work here by driving the device and translating the different device specific event protocols to the linux evdev input event standard.
The X server determines which window the event affects and sends it to the clients that have selected for the event in question on that window. The X server doesn't actually know how to do this right, since the window location on screen is controlled by the compositor and may be transformed in a number of ways that the X server doesn't understand (scaled down, rotated, wobbling, etc).
The client looks at the event and decides what to do. Often the UI will have to change in response to the event - perhaps a check box was clicked or the pointer entered a button that must be highlighted. Thus the client sends a rendering request back to the X server.
When the X server receives the rendering request, it sends it to the driver to let it program the hardware to do the rendering. The X server also calculates the bounding region of the rendering, and sends that to the compositor as a damage event.
The damage event tells the compositor that something changed in the window and that it has to recomposite the part of the screen where that window is visible. The compositor is responsible for 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.
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:
Figure 3.2. Wayland architecture diagram
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.
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 window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
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.
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.
Wayland architecture的更多相关文章
- Linux Graphic DRI Wayland 显示子系统
转:https://blog.csdn.net/u013165704/article/details/80709547 1. 前言 上篇文章(Linux graphic subsytem(1)_概述) ...
- Undefined symbols for architecture arm64解决方案
在iOS开发中经常遇到的一个错误是Undefined symbols for architecture arm64,这个错误表示工程某些地方不支持arm64指令集.那我们应该怎么解决这个问题了?我们不 ...
- Optimal Flexible Architecture(最优灵活架构)
来自:Oracle® Database Installation Guide 12_c_ Release 1 (12.1) for Linux Oracle base目录命名规范: /pm/s/u 例 ...
- EF框架组件详述【Entity Framework Architecture】(EF基础系列篇3)
我们来看看EF的框架设计吧: The following figure shows the overall architecture of the Entity Framework. Let us n ...
- [Architecture] 系统架构正交分解法
[Architecture] 系统架构正交分解法 前言 随着企业成长,支持企业业务的软件,也会越来越庞大与复杂.当系统复杂到一定程度,开发人员会发现很多系统架构的设计细节,很难有条理.有组织的用一张大 ...
- Stack Overflow: The Architecture - 2016 Edition
To get an idea of what all of this stuff “does,” let me start off with an update on the average day ...
- ios build时,Undefined symbols for architecture xxx问题的总结
简单来说,Undefined symbols基本上等于JAVA的ClassNotFoundException,最常见的原因有这几种: build的时候没有加framework 比如说,有一段代码我用了 ...
- Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_The49DayPersonalFullscreenGiftModel", referenced from: objc-class-ref in The49DayPersonalRoomGiftModel.o ld: symbol(s) not found for a
Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_The49DayPersonalFullscreenGiftModel&q ...
- ios开发错误之: Undefined symbols for architecture x86_64
错误如下: Undefined symbols for architecture x86_64: "_OBJC_CLASS_$_RoutingHTTPServer", refere ...
随机推荐
- Java正则表达式解析网页源码
<!DOCTYPE html> <html lang="zh-Hans"> <head> <meta charset="utf- ...
- HDU-6704 K-th occurrence(后缀数组+主席树)
题意 给一个长度为n的字符串,Q次询问,每次询问\((l,r,k)\) , 回答子串\(s_ls_{l+1}\cdots s_r\) 第\(k\) 次出现的位置,若不存在输出-1.\(n\le 1e5 ...
- 2019 Multi-University Training Contest 1 A.Blank(dp)
题意:现在要你构造一个只有{0,1,2,3} 长度为n且有m个限制条件的序列 问你方案数 思路:dp[i][j][k][now]分别表示四个数最后出现的位置 最后可以滚动数组 优化一下空间 ps:我的 ...
- HDU2732 Leapin' Lizards 最大流
题目 题意: t组输入,然后地图有n行m列,且n,m<=20.有一个最大跳跃距离d.后面输入一个n行的地图,每一个位置有一个值,代表这个位置的柱子可以经过多少个猴子.之后再输入一个地图'L'代表 ...
- Codeforces Round #656 (Div. 3) C. Make It Good (贪心,模拟)
题意:给你一个数组\(a\),可以删除其前缀,要求操作后得到的数组是"good"的.对于"good":可以从数组的头和尾选择元素移动到新数组,使得所有元素移动后 ...
- 牛客编程巅峰赛S1第3场 - 青铜&白银 C.牛牛晾衣服(二分)
题意:有\(n\)件衣服,每件衣服都有\(a_{i}\)滴水,所有衣服每分钟都能自然烘干\(1\)滴水,或者用烘干机,每分钟可以烘干\(k\)滴水,问最快多少分钟可以使所有衣服都烘干. 题解:这题和之 ...
- 表达式目录树插件xLiAd.SqlEx.Core
表达式目录树使用时 引用xLiAd.SqlEx.Core ,是一个很好的插件 using xLiAd.SqlEx.Core.Helper; Expression<Func<Reported ...
- .Net Core 国际化
创建项目什么的就不说了吧 直接进入正题吧 我这里建的是个webapi 添加资源文件 1.首先我们创建一个Language文件夹,这就是我们在后面Startup类中需要配置的目录名. 2.然后我们在La ...
- Bing壁纸-20200417
- 牛客网多校第5场 F take 【思维+数学期望】
题目:戳这里 思路来源:视频讲解 题意:有n个箱子按1...n标号,每个箱子有大小为di的钻石概率为pi,我们初始有个大小为0的钻石,从1到n按顺序打开箱子,遇到比手中大的箱子就换,求交换次数的数学期 ...