devutils/ATFQ/book ATFQ git

Part I · How it works

5.3 How a picture reaches the screen: KMS, Wayland and X11

alsowaylandx11xorgxwaylandkmsmodesettingnomodesetcompositordisplay serverscreen resolutionrefresh ratetearingvsyncblack screen

TL;DR

  • The kernel sets up the screen itself (KMS: kernel mode setting): resolution, refresh rate, which output shows which image.
  • Each window draws into its own buffer. A compositor combines them into one image and asks the kernel to show it at the next refresh.
  • On Wayland the compositor is the display server (GNOME, KDE, Sway). On X11, the X server sits in between. Old X11 apps run on Wayland through XWayland.
echo $XDG_SESSION_TYPE                 # wayland or x11
cat /sys/class/drm/*/status            # which outputs have a screen

On your machine

alice@laptopexample
$ atfq 5.3
  card0     Intel, driver i915, shows the boot screen
  Screens   eDP-1 1920x1200 · free: DP-1, HDMI-A-1
  Compute   /dev/dri/renderD128

An example: Alice's laptop, one of the test machines. In your terminal, this block shows your own machine, read live.

Pitfalls

Deep dive 2 questions

What happens 60 times a second?

When a window has a new frame, it hands the compositor a buffer, often already in GPU memory. The compositor draws all visible windows into a new screen buffer with the GPU, then asks the kernel to flip: show this buffer from the next vertical blank, the pause between two refreshes. The kernel tells it when the flip happened, and the cycle starts again.

Why did Wayland replace X11?

X11's design dates from 1984: the server drew everything itself, over the network if needed. Modern desktops bypassed most of it, leaving a complex middleman with weak isolation: any X11 app can read the keyboard and the screen of every other. Wayland makes the compositor the server, and each app sees only its own windows.

Commands
echo cat
Paths
/sys/class/drm/
See also
5.2 GPU drivers: the kernel, Mesa and NVIDIA
20.2 The kernel command line