Display server

The basic components of a GUI: The display server implements the windowing system. A simple window manager merely draws the window decorations, but compositing window managers do more.

A display server or window server is a program whose primary task is to coordinate the input and output of its clients to and from the rest of the operating system, the hardware, and each other. The display server communicates with its clients over the display server protocol, a communications protocol, which can be network-transparent or simply network-capable.

The display server is a key component in any graphical user interface, specifically the windowing system.

Available display server communications protocols

X11

The X.Org Server communicates with its clients, e.g. Amarok, over the X11 protocol

One example of a display server is the X.Org Server, which runs on top of the kernel (usually a Unix-based kernel, such as Linux or BSD). It receives data from evdev and passes it to one of its clients. The display server also receives data from its clients; it processes the data, it does the compositing and passes the data to one of three kernel components – DRM, gem or KMS driver. The component writes the data into the framebuffer and content of the framebuffer is transmitted to the connected screen and displayed. X relies on GLX.

One of the implementations of display server concept is X Window System, in particular its actually used version – X.Org Server and Xlib and XCB client libraries. The X.Org Server is a display server, but in its current implementation it relies on a second program, the compositing window manager, to do the compositing. Examples are Mutter or KWin.

Notable examples of display servers implementing the X11 display server protocol are X.Org Server, XFree86, XQuartz and Cygwin/X, while client libraries implementing the X11 display server protocol are Xlib and XCB.

One tool called xev is a Unix command which creates a window and then asks the display server to send information of events every time something happens to the window (like if it's resized, if any keys are pushed, if it's clicked it etc.) to the console.

Wayland

The Wayland display server protocol

Display servers that implement the Wayland display server protocol, are called Wayland compositors. Like any display server, a Wayland compositor is responsible for handling input and output for its clients and – in contrast to X11 – additionally for the compositing. Examples are Weston, Mutter, KWin or Enlightenment.

Wayland compositors communicate with Wayland clients over the Wayland display server protocol. This protocol defines that clients can directly write data into the framebuffer using the EGL rendering API. The display server still gets to decide which window is on top and thus visible to the user and also still is responsible for passing data regarding to input devices from evdev to its clients.

Wayland is used to a certain degree in some Linux desktop distributions, such as Fedora.[1] It is also well suited for mobile computing and has been adopted, for example, by the smartphone- and tablet-focused projects Tizen and Sailfish OS.

An implementation of Wayland is available under the MIT License, the libwayland-client and libwayland-server libraries.

Mir

Main article: Mir (display server)

The Mir display server comes with its own Mir display server protocol different from the protocols X11 or Wayland. Mir will additionally support the X11 and maybe the Wayland protocol. It is developed by Canonical and is intended to be the display server of choice for Ubuntu.

There is an implementation of the Mir display server available under the GPLv3, the libmir-server and the libmir-client libraries.

SurfaceFlinger

For Android (another Linux kernel-based operating system primarily for mobile devices) Google developed a display server called SurfaceFlinger:[2]

Everything in Android is rendered to a "surface"; "surfaces" are produced by applications and placed into a queue that is managed by SurfaceFlinger.[3][4]

Yet another Android-specific solution is "Gralloc". Gralloc handles device memory i.e. it does allocation, arbitration, it handles synchronization via Android/Linux fence file descriptors (FDs). Gralloc competes with other solutions like e.g. Mesa's Generic Buffer Management (GBM) or Nvidia's EGLStreams. The gralloc hardware abstraction layer (HAL) is used to allocate the buffers that underly "surfaces".

For compositing in Android, Surfaces are sent to SurfaceFlinger, which uses OpenGL|ES to do the compositing.

Hardware Composer HAL (HWC) was introduced in Android 3.0 and has evolved steadily over the years. Its primary purpose is to determine the most efficient way to composite buffers with the available hardware. As a HAL, its implementation is device-specific and usually done by the display hardware OEM.

Quartz Compositor

Quartz Compositor is the name of the component that is fulfilling the tasks of a display server and of a window manager in the windowing system. It is being natively used by the macOS family of operating systems.

References

  1. ↑ "Why Wayland Anyway?". Goings On. Matthias Clasen. Retrieved 2016-06-17.
  2. ↑ "Android system architecture" (PDF). Archived from the original (PDF) on 2016-04-08.
  3. ↑ "Android Developer: Surface".
  4. ↑ "Android Developer: SurfaceFlinger and Hardware Composer".

See also

This article is issued from Wikipedia - version of the 11/14/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.