From bbb5fa66a7fe53c492e4cc2e616c4ada38712542 Mon Sep 17 00:00:00 2001 From: Sebastian Wick Date: Tue, 28 Oct 2025 00:36:53 +0100 Subject: doc: Refactor the build system for complete build dir docs By structuring things differently, it becomes possible to have a complete build of the docs in the build dir, without having to install anything. Signed-off-by: Sebastian Wick --- doc/publican/Introduction.xml | 116 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 doc/publican/Introduction.xml (limited to 'doc/publican/Introduction.xml') diff --git a/doc/publican/Introduction.xml b/doc/publican/Introduction.xml new file mode 100644 index 0000000..f2a8274 --- /dev/null +++ b/doc/publican/Introduction.xml @@ -0,0 +1,116 @@ + + +%BOOK_ENTITIES; +]> + + 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. Support for + things like PCI resource management, display configuration management, + direct rendering, and memory management has been integrated into the X + stack, imposing limitations like limited support for standalone + applications, duplication in other projects (e.g. the Linux fb layer + or the DirectFB project), and high levels of complexity for systems + combining multiple elements (for example radeon memory map handling + between the fb driver and X driver, or VT switching). + + + Moreover, 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. + + + + + + + + X architecture diagram + + + + + The diagram above illustrates the central role of the X server and + compositor in operations, and the steps required to get contents on to + the screen. + + + 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. + + +
+ +
+ The compositing manager as the display server + + 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. We are trying to distill out the functionality in + the X server that is still used by the modern Linux desktop. This + turns out to be not a whole lot. Applications can allocate their own + off-screen buffers and render their window contents directly, using + hardware accelerated libraries like libGL, or high quality software + implementations like those found in Cairo. In the end, what’s needed + is a way to present the resulting window surface for display, and a + way to receive and arbitrate input among multiple clients. This is + what Wayland provides, by piecing together the components already in + the eco-system in a slightly different way. + + + X will always be relevant, in the same way Fortran compilers and VRML + browsers are, but it’s time that we think about moving it out of the + critical path and provide it as an optional component for legacy + applications. + + + Overall, the philosophy of Wayland is to provide clients with a way to + manage windows and how their contents are displayed. Rendering is left + to clients, and system wide memory management interfaces are used to + pass buffer handles between clients and the compositing manager. + + + + + + + + Wayland architecture diagram + + + + + 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). + +
+ -- cgit v1.2.3-70-g09d2