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
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
|
/****************************************************************************
**
** Copyright (C) 2015 The Qt Company Ltd.
** Contact: http://www.qt.io/licensing/
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see http://www.qt.io/terms-conditions. For further
** information use the contact form at http://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: http://www.gnu.org/copyleft/fdl.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page embedded-linux.html
\title Qt for Embedded Linux
With the release of Qt 5.0, Qt no longer contains its own window system
implementation: QWS is no longer a supported platform. For single-process use
cases, the \l{Qt Platform Abstraction} is a superior solution. Multiple
graphical processes will be supported through Wayland.
There are multiple platform plugins that are potentially usable on Embedded
Linux systems: EGLFS, LinuxFB, KMS, DirectFB, Wayland. The availability of
these depend on the configuration of Qt. The default platform plugin is also
device specific. For instance, on many boards eglfs will be chosen as the
default one. If the default is not suitable, the \c QT_QPA_PLATFORM
environment variable parameter can be used to request another
plugin. Alternatively, for quick tests, the \c -platform command-line can be
used with the same syntax.
\section1 Configuring for a Specific Device
Building Qt for a given device requires a toolchain and a
sysroot. Additionally, some devices require vendor specific adaptation code
for EGL and OpenGL ES 2.0 support. This is not relevant for non-accelerated
platforms, for example the ones using the LinuxFB plugin, however neither
OpenGL nor Qt Quick 2 will be functional in such a setup.
The directory \e qtbase/mkspecs/devices contains configuration and graphics
adaptation code for a number of devices. For example, \c linux-rasp-pi2-g++
contains build settings, such as the optimal compiler and linker flags, for
the \l {http://www.raspberrypi.org}{Raspberry Pi 2}, and either an
implementation of the eglfs hooks (vendor-specific adaptation code), or a
reference to a suitable eglfs device integration plugin. The device is
selected through the \l{Qt Configure Options}{configure} tool's \c -device
parameter. The name that follows after this argument must, at least partially,
match one of the subdirectories under \e devices.
Below is an example configuration for the Raspberry Pi 2. For most Embedded
Linux boards the configure command will look very similar.
\code
./configure -release -opengl es2 -device linux-rasp-pi2-g++ -device-option CROSS_COMPILE=$TOOLCHAIN/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf- -sysroot $ROOTFS -prefix /usr/local/qt5
\endcode
The most important parameters are \c -device and \c -sysroot. By specifying
\c -sysroot, the include files and libraries used by \c {configure}'s feature
detection tests, as well as Qt itself, will be taken from the specified
location, instead of the host PC's standard locations. This means that
installing development packages on the host machine has no relevance: for
example, to get libinput support it is not sufficient or necessary to have the
libinput development headers and libraries installed on the host
environment. Instead, the headers and the libraries for the target
architecture (e.g. ARM) have to be present in the sysroot.
\c pkg-config is supported also when performing cross-compilation.
\c configure will automatically set \c PKG_CONFIG_LIBDIR to make \c pkg-config
report compiler and linker settings based on the sysroot instead of the host
machine. This will usually function well without any further
adjustments. However, environment variables such as \c PKG_CONFIG_PATH should
be unset for the host machine before running \c configure. Otherwise the Qt
build may attempt to use inappropriate headers and libraries from the host
system.
See \l {Qt Configure Options} for more information.
\section1 Platform Plugins for Embedded Linux Devices
\section2 EGLFS
\l {http://www.khronos.org/egl}{EGL} is an interface between OpenGL and the
native windowing system. Qt can use EGL for context and surface management,
however the API contains no platform specifics: The creation of a \e {native
window} (which will not necessarily be an actual window on the screen) must
still be done by platform-specific means. Hence the need for the board or GPU
specific adaptation code. Such adaptations are provided either as \e {eglfs
hooks}, a single source file compiled in to the platform plugin, or as
dynamically loaded \e {EGL device integration} plugins.
EGLFS is a platform plugin for running Qt5 applications on top of EGL and
OpenGL ES 2.0 without an actual windowing system (like X11 or Wayland). In
addition to Qt Quick 2 and native OpenGL applications it supports
software-rendered windows (for example QWidget) too. In the latter case the
widgets' contents are rendered using the CPU into images which are then
uploaded into textures and composited by the plugin.
This is the recommended plugin for modern Embedded Linux devices that include
a GPU.
EGLFS forces the first top-level window (be it either a QWidget or a
QQuickView) to become fullscreen. This window is also chosen to be the \e root
widget window into which all other top-level widgets (for example dialogs,
popup menus or combobox dropdowns) are composited. This is necessary because
with EGLFS there is always exactly one native window and EGL window surface,
and these belong to the widget or window that is created first. This approach
works well when there is a main window that exists for the entire lifetime of
the application and all other widgets are either non top-levels or are created
afterwards, once the main window is shown.
There are further restrictions for OpenGL-based windows. As of Qt 5.3, eglfs
supports a single, fullscreen GL window (for example, an OpenGL-based QWindow,
a QQuickView or a QGLWidget). Opening additional OpenGL windows or mixing such
windows with QWidget-based content is not supported and will terminate the
application with an error message.
If necessary, eglfs can be configured via environment variables:
\list
\li \c {QT_QPA_EGLFS_FB} - Overrides the framebuffer device. The default is
\c /dev/fb0. On most embedded platforms this is not very relevant because the
framebuffer is used only for querying settings like the display dimensions.
On certain devices however this parameter provides the ability to specify
which display to use in multiple display setups, similarly to the \c fb
parameter in LinuxFB.
\li \c {QT_QPA_EGLFS_WIDTH} and \c {QT_QPA_EGLFS_HEIGHT} - Contain the screen
width and height in pixels. While eglfs will try to determine the dimensions
from the framebuffer device \e{/dev/fb0}, this will not always work and
manually specifying the sizes may become necessary.
\li \c {QT_QPA_EGLFS_PHYSICAL_WIDTH} and \c {QT_QPA_EGLFS_PHYSICAL_HEIGHT} -
Physical screen width and height in millimeters. On platforms where the
framebuffer device \e{/dev/fb0} is not available or the query is not
successful, the values are calculated based on a default DPI of 100. This
variable can be used to override any such defaults.
\li \c {QT_QPA_EGLFS_DEPTH} - Overrides the color depth for the screen. On
platforms where the framebuffer device \e{/dev/fb0} is not available or the
query is not successful, the default of 32 is used. This variable can be used
to override any such defaults. Note that this affects only the color depth
value reported by QScreen. It has no connection to EGL configurations and the
color depth used for OpenGL rendering.
\li \c {QT_QPA_EGLFS_SWAPINTERVAL} - By default a swap interval of \c 1 will
be requested. This enables synchronizing to the displays vertical refresh. The
value can be overridden with this environment variable. For instance, passing
0 will disable blocking on swap, resulting in running as fast as possible
without any synchronization.
\li \c {QT_QPA_EGLFS_FORCEVSYNC} - When set, eglfs requests
\c FBIO_WAITFORVSYNC on the framebuffer device.
\li \c {QT_QPA_EGLFS_FORCE888} - When set, the red, green and blue color
channel sizes are ignored whenever creating a new context, window or offscreen
surface. Instead, the plugin will request a configuration with 8 bits per
channel. This can be helpful on devices where configurations with less than 32
or 24 bits per pixel are chosen by default but are known not to be suitable,
for example, due to banding effects. Instead of changing all the applications,
this variable provides an easier shortcut to force 24/32 bpp configurations
for a given device.
\li \c {QT_QPA_EGLFS_DEBUG} - When set, some debugging information is printed
on the debug output. For example, the input QSurfaceFormat and the properties
of the chosen EGL configuration are printed whenever creating a new
context. Together with Qt Quick's \c {QSG_INFO} variable, this can provide
useful information for troubleshooting issues related to the EGL
configuration.
\li \c {QT_QPA_EGLFS_INTEGRATION} - In addition to the compiled-in \e hooks,
it is also possible to provide device or vendor-specific adaptation in the
form of dynamically loaded plugins. This environment variable enforces a
specific plugin. For example, setting it to \e{eglfs_kms} will use the KMS/DRM
backend. This is only an option when no static, compiled-in hooks were
specified in the device makespecs. In practice the traditional compiled-in
hooks are rarely used, almost all backends are now migrated to plugins. The
device makespecs still contain a relevant \c EGLFS_DEVICE_INTEGRATION entry:
the name of the preferred backend for that particular device. This is
optional, but very useful to avoid the need to set this environment variable
in case there are more than one plugins present in the target system. In a
desktop environment the KMS or the X11 backends are prioritized, depending on
the presence of the \c DISPLAY environment variable. Note that on some boards
the special value of \c none will be used instead of an actual plugin. This
indicates that no special integration is necessary to use EGL with the
framebuffer and so no plugins should be loaded.
\endlist
In addition to \c {QT_QPA_EGLFS_DEBUG}, eglfs also supports the more modern
categorized logging system of Qt. The following logging categories are
available:
\list
\li \c qt.qpa.egldeviceintegration – Enables logging for dynamically loaded
backends. Very useful to check what backend is in use.
\li \c qt.qpa.input – Enables debug output both from the evdev and libinput
input handlers. Very useful to check if a given input device was correctly
recognized and opened.
\li \c qt.qpa.eglfs.kms – Enables verbose logging in the KMS/DRM backend.
\endlist
\section2 LinuxFB
This plugin writes directly to the framebuffer. Only software-rendered content
is supported. Note that on some setups the display performance is expected to
be limited.
The \c linuxfb plugin allows specifying additional settings by passing them
in the \c QT_QPA_PLATFORM environment variable or \c -platform command-line
option. For example, \c {QT_QPA_PLATFORM=linuxfb:fb=/dev/fb1} specifies that
the framebuffer device \c /dev/fb1 should be used instead of the default
\c fb0. Multiple settings can be specfified by separating them with a colon.
\list
\li \c {fb=/dev/fbN} - Specifies the framebuffer devices. On multiple display
setups this will typically allow running the application on different
displays. For the time being there is no way to use multiple framebuffers from
one Qt application.
\li \c{size=}\e{<width>}\c{x}\e{<height>} - Specifies the screen size in
pixels. The plugin will try to query the display dimensions, both physical and
logical, from the framebuffer device. This may not always lead to proper
results however, and therefore it may become necessary to explicitly specify
the values.
\li \c{mmSize=}\e{<width>}\c{x}\e{<height>} - Physical width and height in
millimeters.
\li \c{offset=}\e{<width>}\c{x}\e{<height>} - Offset in pixels specifying the
top-left corner of the screen. The default position is at \c{(0, 0)}.
\li \c {nographicsmodeswitch} - Do not switch the virtual terminal to graphics
mode (\c KD_GRAPHICS). In addition to switching to graphics mode, the blinking
cursor and screen blanking are normally disabled too. When this parameter is
set, these are also skipped.
\li \c {tty=/dev/ttyN} - Overrides the virtual console. Only used when
\c{nographicsmodeswitch} is not set.
\endlist
\section2 KMS
An experimental platform plugin using kernel modesetting and \l
{http://dri.freedesktop.org/wiki/DRM}{drm} (Direct Rendering Manager).
\note This plugin is obsolete. eglfs has its own KMS/DRM support
which provides all the functionality of the kms plugin and also adds
features, like multiple display support, that were not previously
available in the standalone plugin. Using the kms plugin is
therefore strongly discouraged.
\section1 Input
When no windowing system is present, the mouse, keyboard and touch input are
read directly via \c evdev or using helper libraries like \c libinput or
\c tslib. Note that this requires that devices nodes \c {/dev/input/event*} are
readable by the user. eglfs and linuxfb have all the input handling code
compiled-in.
\section2 Using libinput
\l{http://www.freedesktop.org/wiki/Software/libinput}{libinput} is a library
to handle input devices. It offers an alternative to the Qt's own evdev input
support. To enable using libinput, make sure the development files for libudev
and libinput are available when configuring and building Qt. xkbcommon is also
necessary if keyboard support is desired. With eglfs and linuxfb no further
actions are necessary as libinput will be used by default. If libinput support
is not available or the environment variable \c QT_QPA_EGLFS_NO_LIBINPUT is
set, Qt's own evdev handlers will be used as described below.
\section2 Input on eglfs and linuxfb without libinput
Parameters like the device node name can be set in the environment variables
\c QT_QPA_EVDEV_MOUSE_PARAMETERS, \c QT_QPA_EVDEV_KEYBOARD_PARAMETERS and
\c QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS. Additionally, the built-in input handlers
can be disabled by setting \c QT_QPA_EGLFS_DISABLE_INPUT or
\c QT_QPA_FB_DISABLE_INPUT to \c 1. On some touch screens the coordinates will
need to be rotated. This can be enabled by setting
\c QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS to \c {rotate=180}.
\section2 Mouse
The mouse cursor will show up whenever \c QT_QPA_EGLFS_HIDECURSOR (for eglfs)
or \c QT_QPA_FB_HIDECURSOR (for linuxfb) is not set and Qt's libudev-based
device discovery reports that at least one mouse is available. When libudev
support is not present, the mouse cursor will always show up unless explicitly
disabled via the environment variable.
Hot plugging is supported, but only if Qt was configured with libudev support
(that is, if the \e libudev development headers are present in the sysroot at
configure time). This allows connecting or disconnecting an input device while
the application is running.
\section2 Keyboard
The evdev keyboard handler supports the following extra parameters:
\list
\li \c {/dev/input/...} - Specifies the name of the input device. When not
given, Qt will look for a suitable device either via \e libudev or by walking
through the available nodes.
\li \c {grab} - Enables grabbing the input device.
\li \c {keymap} - Specifies the name of a custom keyboard map file.
\li \c {enable-compose} - Enables compositing.
\li \c {repeat-delay} - Sets a custom key repeat delay.
\li \c {repeat-rate} - Sets a custom key repeat rate.
\endlist
On Embedded Linux systems that do not have their terminal sessions disabled,
the behavior when pressing a key can be confusing due to having the input
event processed both by the Qt application and the tty. To overcome this, the
following options are available:
\list
\li EGLFS, LinuxFB and KMS attempt to disable the terminal keyboard on
application startup by setting the tty's keyboard mode to \c K_OFF. This
prevents keystrokes from going to the terminal. If the standard behavior needs
to be restored for some reason, set the environment variable
\c QT_QPA_ENABLE_TERMINAL_KEYBOARD to \c 1. Note that this will not work when the
application is launched from a remote console (for example, via \c ssh) and
the terminal keyboard input will remain enabled.
\li An alternative approach is to use the evdev keyboard handler's \c grab
parameter by passing \e{grab=1} in \c QT_QPA_EVDEV_KEYBOARD_PARAMETERS. This
results in trying to get a grab on the input device which, if successful,
means that no other components in the system receive events from it as long as
the Qt application is running. This approach is more suitable for applications
started remotely as it does not need access to the tty device.
\li Finally, for many specialized Embedded Linux images it will not make sense
to have the standard terminal sessions enabled in the first place. Refer to
your build environment's documentation on how to disable them. For example,
when generating images using the \l {http://www.yoctoproject.org}{Yocto
Project}, unsetting \c SYSVINIT_ENABLED_GETTYS will result in having no
\c getty process running, and thus no input, on any of the virtual terminals.
\endlist
If the default, built-in keymap is not sufficient, a different one can be
specified either via the \c keymap parameter or by using the eglfs-specific
\l{QEglFSFunctions::loadKeymap()}{loadKeymap()} function. The latter allows
switching the keymap at runtime. Note however that this requires using eglfs'
built-in keyboard handler; it is not supported when the keyboard handler is
loaded via the \c -plugin command-line parameter.
\note Special system key combinations, such as console switching
(\e{Ctrl+Alt+Fx}) or zap (\e{Ctrl+Alt+Backspace}) are not currently supported
and will get ignored.
To generate a custom keymap, the \e kmap2qmap utility can be used. This can be
found in the \e qttools module. The source files have to be in standard Linux
\c kmap format that is e.g. understood by the kernel's \c loadkeys command.
This means one can use the following sources to generate \c qmap files:
\list
\li The \l {http://lct.sourceforge.net/}{Linux Console Tools (LCT)} project.
\li \l {http://www.x.org/}{Xorg} X11 keymaps can be converted to the
\c kmap format with the \c ckbcomp utility.
\li As \c kmap files are plain text files, they can also be hand crafted.
\endlist
\c kmap2qmap is a command line program, that needs at least 2 files as
parameters. The last one will be the generated \c .qmap file, while all the
others will be parsed as input \c .kmap files. For example:
\badcode
kmap2qmap i386/qwertz/de-latin1-nodeadkeys.kmap include/compose.latin1.inc de-latin1-nodeadkeys.qmap
\endcode
\note \c kmap2qmap does not support all the (pseudo) symbols that the Linux
kernel supports. When converting a standard keymap, a number of warnings will
be shown regarding \c Show_Registers, \c Hex_A, and so on; these messages can
safely be ignored.
\section2 Touch
For some resistive, single-touch touch screens it may be necessary to fall
back to using tslib instead of relying on the Linux multitouch protocol and
the event devices. For modern touch screens this should not be
necessary. tslib support can be enabled by setting the environment variable
\c QT_QPA_EGLFS_TSLIB or \c QT_QPA_FB_TSLIB to 1. To change the device, set the
environment variable \c TSLIB_TSDEVICE or pass the device name on the
command-line. Note that the tslib input handler generates mouse events and
supports single touch only, as opposed to evdevtouch which generates true
multi-touch QTouchEvent events too.
\section2 Pen-based tablets
The \c evdevtablet plugin provides basic support for Wacom and similar,
pen-based tablets. It will only generate QTabletEvent events. To enable it,
pass \c {QT_QPA_GENERIC_PLUGINS=evdevtablet} in the environment or,
alternatively, \c {-plugin evdevtablet} on the command-line. The plugin can
take a device node parameter, for example
\c{QT_QPA_GENERIC_PLUGINS=evdevtablet:/dev/event1}, in case the Qt's automatic
device discovery (based either on \e libudev or a walkthrough of
\c{/dev/input/event*}) is not functional or misbehaving.
\section2 Debugging Input Devices
It is possible to print some information to the debug output by enabling
the \c qt.qpa.input logging rule, for example by setting the \c QT_LOGGING_RULES
environment variable to \c{qt.qpa.input=true}. This is useful for detecting
which device is being used, or to troubleshoot device discovery issues.
\section2 Using custom mouse cursor images
eglfs comes with its own set of 32x32 sized mouse cursor images. If these are
not sufficient, a custom cursor atlas can be provided by setting the \c
QT_QPA_EGLFS_CURSOR environment variable to the name of a JSON file. The file
can also be embedded into the application via Qt's resource system.
For example, an embedded cursor atlas with 8 cursor images per row can be
specified like the following:
\badcode
{
"image": ":/cursor-atlas.png",
"cursorsPerRow": 8,
"hotSpots": [
[7, 2],
[12, 3],
[12, 12],
...
]
}
\endcode
Note that the images are expected to be tightly packed in the atlas: the
width and height of the cursors are decided based on the total image size and
the \c cursorsPerRow setting. Atlases have to provide an image for all the
supported cursors.
\section1 Display output
When having multiple displays connected, the level of support for targeting
one or more of these from one single Qt application varies between the
platform plugins and often depends on the device and its graphics stack.
\section2 eglfs
When the KMS/DRM backend is in use, eglfs will report all available screens in
QGuiApplication::screens(). Applications can target different screens with
different windows via QWindow::setScreen(). Note however that the restriction
of one single fullscreen window per screen still applies.
When getting started with developing on a given embedded device, it is often
necessary to verify the behavior of the device and drivers, and that the
connected displays are working as they should. One easy way is to use the
hellowindow example. Launching it with \c{-platform eglfs --multiscreen
--timeout} will show a rotating Qt logo on each connected screen for a few
seconds.
The KMS/DRM backend also supports custom configurations via a JSON file. Set
the environment variable \c QT_QPA_EGLFS_KMS_CONFIG to the name of the file to
enable this. The file can also be embedded in the application via the Qt
resource system. An example configuration is below:
\badcode
{
"device": "/dev/dri/card1",
"hwcursor": false,
"pbuffers": true,
"outputs": [
{
"name": "VGA1",
"mode": "off"
},
{
"name": "HDMI1",
"mode": "1024x768"
}
]
}
\endcode
Here we configure the specified device so that
\list
\li it will not use the hardware cursor (falls back to rendering the mouse
cursor via OpenGL; by default hardware cursors are enabled since they are more
efficient),
\li it will back QOffscreenSurface with standard EGL pbuffer surfaces (by
default this is disabled and a gbm surface is used instead),
\li output on the VGA connector is disabled, while HDMI is active with a
resolution of 1024x768.
\endlist
Additionally, such a configuration will also disable looking for a device via
\c libudev and instead the specified device will be used.
For troubleshooting it might be useful to enable debug logs from the KMS/DRM
backend. To do this, enable the categorized logging rule \c qt.qpa.eglfs.kms.
Other backends, that are typically based on targeting the framebuffer
directly via the vendor's EGL implementation, will usually provide limited or
no support for multiple displays. In some cases the \c {QT_QPA_EGLFS_FB}
environment variable can be used to control which framebuffer to target,
similarly to linuxfb. Alternatively, driver-specific environment variables or
kernel parameters may also be available to control the used framebuffer. Refer
to the embedded board's documentation.
\section2 Video Memory
Systems with a fixed amount of dedicated video memory may need extra care
before running Qt application based on Qt Quick or classes like
QOpenGLWidget. The default setting may be insufficient for such applications,
especially when they are displayed on a high resolution (for example, full HD)
screen. In this case they may start failing in unexpected ways. It is
therefore recommended to ensure that there is at least 128 MB of GPU memory
available. For systems that do not have a fixed amount of memory reserved for
the GPU this is not an issue.
\section2 linuxfb
Use the \c fb plugin parameter to specify the framebuffer device to use.
\section1 Platform Plugins for Windowing Systems on Embedded Linux Devices
\section2 XCB
This is the X11 plugin used on regular desktop Linux platforms. In some
embedded environments, that provide X and the necessary development files for
\l {http://xcb.freedesktop.org}{xcb}, this plugin will function just like it
does on a regular PC desktop.
\note On some devices there is no EGL and OpenGL support available under X
because the EGL implementation is not compatible with Xlib. In this case the
XCB plugin will be built without EGL support, meaning that Qt Quick 2 or other
OpenGL-based applications will not work with this platform plugin. It can
still be used however to run software-rendered applications (based on QWidget
for example).
As a general rule, the usage of XCB on embedded devices is not
advisable. Plugins like eglfs are likely to provide better performance, and
hardware acceleration.
\section2 Wayland
\l{http://wayland.freedesktop.org/}{Wayland} is a light-weight windowing
system; or more precisely, it is a protocol for clients to talk to a display
server.
The Qt Wayland module provides a \c wayland platform plugin that allows Qt
application to connect to a Wayland compositor.
\note Please note that you may experience issues with touch screen input with
the \l{http://wayland.freedesktop.org/}{Weston} reference compositor. Please
refer to the \l{https://wiki.qt.io/WestonTouchScreenIssues}{Qt Wiki} for
further information.
*/
|