244 lines
7.8 KiB
TeX
244 lines
7.8 KiB
TeX
|
\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}
|