summaryrefslogtreecommitdiff
path: root/linux-basics/graphics/graphics.tex
blob: c57aebf258addb4959bb4725dba37a63711ddd40 (plain)
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
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
\subsection{Graphics in Linux}

\begin{frame}
\frametitle{Framebuffer (DRM)}
The Linux kernel provides multiple interfaces for processes to draw/update a graphics framebuffer. The first is DRM.

\bigskip

Direct Rendering Manager (DRM), i.e. /dev/dri/cardX
\begin{itemize}
\item provides API for hardware features and acceleration
\item hardware acceleration implemented in kernel
\item manages graphics access by multiple processes
\item libdrm (userspace library)
\begin{itemize}
\item C library as wrapper over kernel interface (syscall API)
\item should be used instead of syscalls
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Framebuffer (fbdev)}
The second interface (fbdev) is obsolete, but is still used by many embedded applications.

\bigskip

fbdev, i.e. /dev/fbX
\begin{itemize}
\item hardware-independent abstraction layer
\item no hardware acceleration provided by kernel
\item DirectFB (userspace library, no longer maintained)
\begin{itemize}
\item C library that provides API similar to Microsoft's DirectX
\item implements some hardware acceleration in userspace
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{What is X?}
\begin{itemize}
\item a protocol providing an API to abstract graphics devices
\item current version: 11, release 7.7 (i.e X11R7.7)
\item client/server model (application is client)
\item network transparency
\item X.org
\begin{itemize}
\item server implementation of X11 protocol
\item current version: 1.20
\item implements X11 extensions
\begin{itemize}
\item GLX (OpenGL)
\item AIGLX (Accelerated Indirect OpenGL, hardware acceleration)
\item \dots
\end{itemize}
\item is part of the Direct Rendering Infrastructure (DRI)
\begin{itemize}
\item framework to allow access to hardware features and acceleration
\item typically available through OpenGL DRI (Mesa) drivers that translate the graphic API specifications
\end{itemize}
\item provides client libraries
\begin{itemize}
\item Xcb (implements the client-side of the X11 protocol)
\item \dots
\end{itemize}
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{X.org and Framebuffer}
\begin{center}
\includegraphics[height=6cm]{images/xorg_components.png}
\end{center}

{\scriptsize Image CC BY-SA 3.0, Shmuel Csaba Otto Traian}
\end{frame}

\begin{frame}
\frametitle{What is Wayland?}
\begin{itemize}
\item a protocol providing an API to abstract graphics devices
\item client/server model (application is client)
\item reference implementation libraries \\
(libwayland-client, libwayland-server)
\item designed for the graphic requirements of modern software
\item clients perform buffer rendering
\item server (compositor) manages/combines buffers
\item no remote display support
\item Weston
\begin{itemize}
\item reference compositor implementation of Wayland
\item uses shared memory between clients and compositor
\item handles all Kernel Mode-Setting (kms)
\item uses the Embedded-System Graphics Library (EGL) for direct rendering
\item much smaller and less overhead compared to X.org
\item used by many embedded Linux systems
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Wayland}
\begin{center}
\includegraphics[height=6cm]{images/wayland_components.png}
\end{center}

{\scriptsize Image CC BY-SA 3.0, Shmuel Csaba Otto Traian}
\end{frame}

\begin{frame}
\frametitle{Qt}
\begin{itemize}
\item Qt Platform Abstraction (QPA) is the platform abstraction layer available for Qt5
\item QPA provides a plugin architecture for graphic backends (platforms)
\begin{itemize}
\item qlinuxfb
\item qeglfs
\item qxcb
\item qwayland
\item qandroid
\item qwindows
\item qios
\item \dots
\end{itemize}
\item http://doc.qt.io/qt-5/qpa.html
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Qt with Framebuffer}
qeglfs (platform plugin)
\begin{itemize}
\item runs on top of EGL and OpenGL ES 2.0 without an actual windowing system
\item EGL is an interface between OpenGL and the native windowing system
\item Qt uses EGL for context and surface management
\item the EGL API contains no platform specifics
\begin{itemize}
\item \dots but the creation of a native window is still platform specific
\item so board or GPU-specific adaptation code is still needed
\end{itemize}
\item supports one main window for the entire application lifetime
\item recommended plugin for embedded devices with a GPU
\end{itemize}

\bigskip

qlinuxfb (platform plugin)
\begin{itemize}
\item writes directly to the framebuffer via Linux fbdev driver
\item only software rendered content is supported
\item has limited display performance
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Qt with X}
qxcb (platform plugin)
\begin{itemize}
\item the X11 plugin used on desktop platforms
\item also available on several embedded platforms that provide X
\item mandatory to have a running X server prior to starting the Qt application
\item hardware acceleration is handled by the X server
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Qt with Wayland}
qwayland (platform plugin)
\begin{itemize}
\item allows Qt application to connect to a Wayland compositor
\item Wayland is a protocol for clients to talk to a display server (compositor)
\item Wayland is a light-weight windowing system
\item future development moves in this direction, disfavoring X11
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{How to choose a Qt platform plugin?}
If you need hardware acceleration, you may not have a choice (depending on your hardware).

\bigskip

Can you deal with one main application window?
\begin{itemize}
\item yes: choose the qeglfs platform plugin
\item no: a windowing system must be used
\end{itemize}

\bigskip

Major Linux distributions still use X as the windowing system:
\begin{itemize}
\item many ready to use applications (and your Qt applications can interoperate with them)
\item Qt within Linux distributions is mostly configured for X (i.e. on Debian 9)
\item overall footprint is smaller without X but will require building/maintaining Qt libraries yourself
\item although Wayland is very attractive for embedded systems, it does not (yet) enjoy large scale adoption
\end{itemize}
\end{frame}