--- /dev/null
+\documentclass{article}
+\usepackage{palatino}
+
+\author{Kristian Høgsberg\\
+\texttt{krh@bitplanet.net}
+}
+
+\title{The Wayland Display Server}
+
+\begin{document}
+
+\maketitle
+
+\section{Wayland Overview}
+
+ - wayland is a protocol for a new display server.
+
+ - wayland is an implementation
+
+\subsection{Replacing X11}
+
+Over the last 10 years, a lot of functionality have slowly moved out
+of the X server and into libraries or kernel drivers. It started with
+freetype and fontconfig providing an alternative to the core X fonts
+and direct rendering OpenGL as a graphics driver in a client side
+library. 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. Recently with GEM and KMS in the Linux
+kernel, we can do modesetting outside X and schedule several direct
+rendering clients. The end result is a highly modular graphics stack.
+
+Wayland is a new display server building on top of all those
+components. We’re 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 by themselves. In the end,
+what’s needed is a way to present the resulting window surface to a
+compositor and a way to receive input. 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.
+
+
+\section{Wayland protocol}
+
+\subsection{Basic Principles}
+
+The wayland protocol is a asynchronous object oriented protocol. All
+requests are method invocations on some object. The request 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 wire protocol is determined from the C prototypes of the requests
+and events. There is a straight forward mapping from the C types to
+packing the bytes in the request written to the socket. It is
+possible to map the events and requests to function calls in other
+languages, but that hasn't been done at this point.
+
+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 repsonse to a request
+(in which case the request and the event constitutes a round trip) or
+spontanously when the server state changes.
+
+ - state is broadcast on connect, events sent out when state
+ change. client must listen for these changes and cache the state.
+ no need (or mechanism) to query server state.
+
+ - server will broadcast presence of a number of global objects,
+ which in turn will broadcast their current state
+
+\subsection{Connect Time}
+
+ - no fixed format connect block, the server emits a bunch of events
+ at connect time
+
+ - presence events for global objects: output, compositor, input devices
+
+\subsection{Security and Authentication}
+
+ - mostly about access to underlying buffers, need new drm auth
+ mechanism (the grant-to ioctl idea), need to check the cmd stream?
+
+ - getting the server socket depends on the compositor type, could be
+ a system wide name, through fd passing on the session dbus. or the
+ client is forked by the compositor and the fd is already opened.
+
+\subsection{Creating Objects}
+
+\begin{itemize}
+\item client allocates object ID, uses range protocol
+\item server tracks how many IDs are left in current range, sends new
+ range when client is about to run out.
+\end{itemize}
+
+\subsection{Compositor}
+
+\begin{itemize}
+\item a global object
+\item broadcasts drm file name, or at least a string like drm:/dev/card0
+\item commit/ack/frame protocol
+\end{itemize}
+
+\subsection{Surface}
+
+created by the client
+\begin{itemize}
+\item attach
+\item copy
+\item damage
+\item destroy
+\item input region, opaque region
+\item set cursor
+\end{itemize}
+
+\subsection{Input Group}
+
+global object
+
+\begin{itemize}
+\item - input group, keyboard, mouse
+\item keyboard map, change events
+\item pointer motion
+\item enter, leave, focus
+\item xkb on wayland
+\item multi pointer wayland
+\end{itemize}
+
+
+\subsection{Output}
+
+ - global objects
+ - a connected screen
+ - laid out in a big coordinate system
+ - basically xrandr over wayland
+
+\section{Types of compositors}
+
+\subsection{System Compositor}
+
+ - ties in with graphical boot
+ - hosts different types of session compositors
+ - lets us switch between multiple sessions (fast user switching,
+ secure/personal desktop switching)
+ - multiseat
+ - linux implementation using libudev, egl, kms, evdev, cairo
+ - for fullscreen clients, the system compositor can reprogram the
+ video scanout address to source fromt the client provided buffer.
+
+\subsection{Session Compositor}
+
+ - nested under the system compositor. nesting is feasible because
+ protocol is async, roundtrip would break nesting
+ - gnome-shell
+ - moblin
+ - compiz?
+ - kde compositor?
+ - text mode using vte
+ - rdp session
+ - fullscreen X session under wayland
+ - can run without system compositor, on the hw where it makes
+ sense
+ - root window less X server, bridging X windows into a wayland
+ session compositor
+
+\subsection{Embbedding Compositor}
+
+X11 lets clients embed windows from other clients, or lets client 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 as 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.
+
+ - firefox embedding flash by being a special purpose compositor to
+ the plugin
+
+\section{Implementation}
+
+what's currently implemented
+
+\subsection{Wayland Server Library}
+
+\texttt{libwayland-server.so}
+
+ - implements protocol side of a compositor
+
+ - minimal, doesn't include any rendering or input device handling
+
+ - helpers for running on egl and evdev, and for nested wayland
+
+\subsection{Wayland Client Library}
+
+\texttt{libwayland.so}
+
+ - minimal, designed to support integration with real toolkits such as
+ Qt, GTK+ or Clutter.
+
+ - doesn't cache state, but lets the toolkits cache server state in
+ native objects (GObject or QObject or whatever).
+
+\subsection{Wayland System Compositor}
+
+ - implementation of the system compositor
+
+ - uses libudev, eagle (egl), evdev and drm
+
+ - integrates with ConsoleKit, can create new sessions
+
+ - allows multi seat setups
+
+ - configurable through udev rules and maybe /etc/wayland.d type thing
+
+\subsection{X Server Session}
+
+ - xserver module and driver support
+
+ - uses wayland client library
+
+ - same X.org server as we normally run, the front buffer is a wayland
+ surface but all accel code, 3d and extensions are there
+
+ - when full screen the session compositor will scan out from the X
+ server wayland surface, at which point X is running pretty much as it
+ does natively.
+
+\end{document}
projects / platform / upstream / weston.git / commitdiff