summaryrefslogtreecommitdiff
path: root/linux-basics/graphics/graphics.tex
diff options
context:
space:
mode:
authorHolger Dengler <dengler@linutronix.de>2019-01-11 10:37:08 +0100
committerJohn Ogness <john.ogness@linutronix.de>2019-01-11 11:13:25 +0106
commite1a6fd1839f3960286811d9a2b2fe9dd2ef9bddd (patch)
tree3112c39f7d308690883d14a2294a5bf16120c367 /linux-basics/graphics/graphics.tex
parentbf7bd4abcdd1e9ae1030c7a9dfae70c35791d771 (diff)
linux-basic: Add Linux Graphics Overview slides
Signed-off-by: John Ogness <john.ogness@linutronix.de> [integration, presentation header] Signed-off-by: Holger Dengler <dengler@linutronix.de>
Diffstat (limited to 'linux-basics/graphics/graphics.tex')
-rw-r--r--linux-basics/graphics/graphics.tex200
1 files changed, 200 insertions, 0 deletions
diff --git a/linux-basics/graphics/graphics.tex b/linux-basics/graphics/graphics.tex
new file mode 100644
index 0000000..c57aebf
--- /dev/null
+++ b/linux-basics/graphics/graphics.tex
@@ -0,0 +1,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}