Commit f476148c authored by Daniel Stone's avatar Daniel Stone

Add all files from annarchy.fd.o

Pull the files from annarchy.fd.o, which was serving wayland.fd.o, which
were on the disk and served by Apache but not in the repository.
Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
parent 008647c3

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

This source diff could not be displayed because it is too large. You can view the blob instead.
This source diff could not be displayed because it is too large. You can view the blob instead.
This source diff could not be displayed because it is too large. You can view the blob instead.
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 1. Introduction</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="pr02.html" title="Acknowledgments"><link rel="next" href="ch02.html" title="Chapter 2. Types of Compositors"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. Introduction</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pr02.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch02.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Introduction"></a>Chapter 1. Introduction</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch01.html#sect-Motivation">Motivation</a></span></dt><dt><span class="section"><a href="ch01.html#sect-Compositing-manager-display-server">The compositing manager as the display server</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Motivation"></a>Motivation</h2></div></div></div><p>
Most Linux and Unix-based systems rely on the X Window System (or
simply <span class="emphasis"><em>X</em></span>) 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).
</p><p>
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.
</p><div class="mediaobject"><img src="images/x-architecture.png" alt="X architecture diagram"></div><p>
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.
</p><p>
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.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositing-manager-display-server"></a>The compositing manager as the display server</h2></div></div></div><p>
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.
</p><p>
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.
</p><p>
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.
</p><div class="mediaobject"><img src="images/wayland-architecture.png" alt="Wayland architecture diagram"></div><p>
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).
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pr02.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Acknowledgments </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Types of Compositors</td></tr></table></div></body></html>
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 2. Types of Compositors</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch01.html" title="Chapter 1. Introduction"><link rel="next" href="ch03.html" title="Chapter 3. Wayland Architecture"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Types of Compositors</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch01.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch03.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Compositors"></a>Chapter 2. Types of Compositors</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch02.html#sect-Compositors-System-Compositor">System Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Session-Compositor">Session Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Embedding-Compositor">Embedding Compositor</a></span></dt></dl></div><p>
Compositors come in different types, depending on which
role they play in the overall architecture of the OS.
For instance, a
<a class="link" href="ch02.html#sect-Compositors-System-Compositor" title="System Compositor">system compositor</a>
can be used for booting the system, handling multiple user switching, a
possible console terminal emulator and so forth. A different compositor, a
<a class="link" href="ch02.html#sect-Compositors-Session-Compositor" title="Session Compositor">session compositor</a>
would provide the actual desktop environment. There are many ways for
different types of compositors to co-exist.
</p><p>
In this section, we introduce three types of Wayland compositors relying
on <a class="link" href="apc.html" title="Appendix C. Server API">libwayland-server</a>.
</p><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-System-Compositor"></a>System Compositor</h2></div></div></div><p>
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.
</p><p>
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).
</p><p>
A linux implementation of a system compositor will typically
use libudev, egl, kms, evdev and cairo.
</p><p>
For fullscreen clients, the system compositor can reprogram the
video scanout address to read directly from the client provided
buffer.
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-Session-Compositor"></a>Session Compositor</h2></div></div></div><p>
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.
</p><p>
X applications can continue working under a session compositor
by means of a root-less X server that is activated on demand.
</p><p>
Possible examples for session compositors include
</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
gnome-shell
</p></li><li class="listitem"><p>
moblin
</p></li><li class="listitem"><p>
kwin
</p></li><li class="listitem"><p>
kmscon
</p></li><li class="listitem"><p>
rdp session
</p></li><li class="listitem"><p>
Weston with X11 or Wayland backend is a session compositor nested
in another session compositor.
</p></li><li class="listitem"><p>
fullscreen X session under Wayland
</p></li></ul></div><p>
</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-Embedding-Compositor"></a>Embedding Compositor</h2></div></div></div><p>
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.
</p><p>
An example for this kind of setup is firefox embedding the flash
player as a kind of special-purpose compositor.
</p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch01.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. Introduction </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. Wayland Architecture</td></tr></table></div></body></html>
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
/*headings*/
h1, h2, h3, h4, h5, h6,
div.producttitle,
div.subtitle,
div.author div.author,
div.translator div.translator,
div.othercredit div.othercredit,
div.editor div.editor,
div.contrib div.contrib,
.title,
.titlepage .edition,
.titlepage .releaseinfo {
color: #336699;
}
This diff is collapsed.
@import url("common.css");
@import url("overrides.css");
@import url("lang.css");
/*headings*/
h1, h2, h3, h4, h5, h6,
div.producttitle,
div.subtitle,
div.author div.author,
div.translator div.translator,
div.othercredit div.othercredit,
div.editor div.editor,
div.contrib div.contrib,
.title,
.titlepage .edition {
}
div.para {
margin-top: 1em;
}
/* inline syntax highlighting */
.perl_Alert {
color: #0000ff;
}
.perl_BaseN {
color: #007f00;
}
.perl_BString {
color: #5C3566;
}
.perl_Char {
color: #ff00ff;
}
.perl_Comment {
color: #888888;
}
.perl_DataType {
color: #0000ff;
}
.perl_DecVal {
color: #00007f;
}
.perl_Error {
color: #ff0000;
}
.perl_Float {
color: #00007f;