1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
# Architecture
This document describes the high-level design of wlroots. wlroots is modular:
each module can be used mostly independently from the rest of wlroots. For
instance, some wlroots-based compositors only use its backends, some only use
its protocol implementations.
## Backends
Backends are responsible for exposing input devices and output devices.
wlroots provides DRM and libinput backends to directly drive physical
devices, Wayland and X11 backends to run nested inside another compositor,
and a headless backend. A special "multi" backend is used to combine together
multiple backends, for instance DRM and libinput. Compositors can also
implement their own custom backends if they have special needs.
Input devices such as pointers, keyboards, touch screens, tablets, switches
are supported. They emit input events (e.g. a keyboard key is pressed) which
compositors can handle and forward to Wayland clients.
Output devices are tasked with presenting buffers to the user. They also
provide feedback, for instance presentation timestamps. Some backends support
more advanced functionality, such as displaying multiple buffers (e.g. for the
cursor image) or basic 2D transformations (e.g. rotation, clipping, scaling).
## Renderers
Renderers provide utilities to import buffers submitted by Wayland clients,
and a basic 2D drawing API suitable for simple compositors. wlroots provides
renderer implementations based on OpenGL ES 2, Vulkan and Pixman. Just like
backends, compositors can implement their own renderers, or use the graphics
APIs directly.
To draw an image onto a buffer, compositors will first need to create a
texture, representing a source of pixels the renderer can sample from. This can
be done either by uploading pixels from CPU memory, or by importing already
existing GPU memory via DMA-BUFs. Compositors can then create a render pass
and submit drawing operations. Once they are done drawing, compositors can
submit the rendered buffer to an output.
## Protocol implementations
A number of Wayland interface implementations are provided.
### Plumbing protocols
wlroots ships unopinionated implementations of core plumbing interfaces, for
instance:
- `wl_compositor` and `wl_surface`
- `wl_seat` and all input-related interfaces
- Buffer factories such as `wl_shm` and linux-dmabuf
- Additional protocols such as viewporter and presentation-time
### Shells
Shells give a meaning to surfaces. There are many kinds of surfaces:
application windows, tooltips, right-click menus, desktop panels, wallpapers,
lock screens, on-screen keyboards, and so on. Each of these use-cases is
fulfilled with a shell. wlroots supports xdg-shell for regular windows and
popups, Xwayland for interoperability with X11 applications, layer-shell for
desktop UI elements, and more.
### Other protocols
Many other protocol implementations are included, for instance:
- xdg-activation for raising application windows
- idle-inhibit for preventing the screen from blanking when the user is
watching a video
- ext-idle-notify for notifying when the user is idle
## Helpers
wlroots provides additional helpers which can make it easier for compositors to
tie everything together:
- `wlr_output_layout` organises output devices in the physical space
- `wlr_cursor` stores the current position and image of the cursor
- `wlr_scene` provides a declarative way to display surfaces
## tinywl
tinywl is a minimal wlroots compositor. It implements basic stacking window
management and only supports xdg-shell. It's extensively commented and is a
good learning resource for developers new to wlroots.
|
