The OpenSTLinux distribution enables the generation of example images based on the QT framework (st-example-image-qt and, for ecosystem release ≥ v2.1.0 , st-example-image-qtwayland) for demonstration purposes, not for developing products.
This article provides information on how to create the SDK for building QT applications based on the above example images.
1. Prerequisites[edit source]
Be able to rebuild an OpenSTLinux image
2. OpenSTLinux QT images and SDK[edit source]
OpenSTLinux distribution provides two examples of images based on the QT framework:
- st-example-image-qt (requires 'openstlinux-eglfs' distro): only one QT application can access the screen. It is displayed in full-screen mode. This provides the best performance because the QT application accesses the screen without the overhead of a window manager.
- st-example-image-qtwayland (requires 'openstlinux-weston' distro and ecosystem release ≥ v2.1.0 ): thanks to weston window management, QT applications are displayed in independent windows and can coexist on the same screen with other non-QT applications. The window management adds extra overhead, decreasing the overall performance of the QT application. If the QT application has to run in full-screen mode, prefer the previous image
To build the images and the associated SDK, first install the OpenSTLinux distribution by following the procedure described in chapter Installing the OpenSTLinux distribution.
2.1. QT image and SDK with EGLFS[edit source]
The QT image and SDK use QT back-end to run single QT applications in full-screen mode.
Initialize the OpenEmbedded build environment for the openstlinux-eglfs distro:
DISTRO=openstlinux-eglfs MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh
Read and accept EULA. Refer to Initializing the OpenEmbedded build environment for further details.
Then build the image and the SDK:
bitbake st-example-image-qt bitbake st-example-image-qt -c populate_sdk
Refer to Generating your own Starter and Developer Packages and How to create an SDK for OpenSTLinux distribution for further details.
Note: the legacy command bitbake meta-toolchain-qt5 is not recommended because the resulting SDK would miss some target packages.
The image can be flashed on the target board as in Flashing the built image.
The generated SDK is available in the tmp-glibc/deploy/sdk/ folder. It can be installed as described in Run the SDK installation script, using the following command:
./tmp-glibc/deploy/sdk/st-example-image-qt-openstlinux-eglfs-stm32mp1-x86_64-toolchain-unknown revision-snapshot.sh -y -d <working directory absolute path>/Developer-Package/SDK
2.1.1. Selecting the display resolution and size in EGLFS[edit source]
When using a display that accepts multiple resolutions, the preferred resolution can be specified by editing the board file /usr/share/qt5/cursor.json. For example, for an HDMI display, change the line
{ "name": "HDMI1", "mode": "1280x720" },
and enter one of the valid resolutions reported by the command
modetest
If the current display resolution is higher than the resolution requested by the QT application, QT expands the application to run it in full screen. This can produce blurred images on the display and can impact the system performance.
The QT framework can be configured to use only one part of the overall display. For example, to use only an area of 400x300 pixels, add:
{ "name": "HDMI1", "mode": "1280x720", "size": "400x300" },
2.2. QT image and SDK with weston/wayland[edit source]
The QT image and SDK use QTwayland back-end to run QT applications in independent windows managed by weston. This requires ecosystem release ≥ v2.1.0 .
Initialize the OpenEmbedded build environment for the openstlinux-weston distro:
DISTRO=openstlinux-weston MACHINE=stm32mp1 source layers/meta-st/scripts/envsetup.sh
Read and accept EULA. Refer to Initializing the OpenEmbedded build environment for further details.
Then build the image and the SDK:
bitbake st-example-image-qtwayland bitbake st-example-image-qtwayland -c populate_sdk
Refer to Generating your own Starter and Developer Packages and How to create an SDK for OpenSTLinux distribution for further details.
Note: the legacy command bitbake meta-toolchain-qt5 is not recommended because the resulting SDK would miss some target packages.
The image can be flashed on the target board as in Flashing the built image.
The generated SDK is available in the tmp-glibc/deploy/sdk/ folder. It can be installed as described in Run the SDK installation script, using the following command:
./tmp-glibc/deploy/sdk/st-example-image-qtwayland-openstlinux-weston-stm32mp1-x86_64-toolchain-unknown revision-snapshot.sh -y -d <working directory absolute path>/Developer-Package/SDK
3. Building a QT application[edit source]
Pre-existing QT applications are usually deployed as "project" with one or more .pro file. In such case QT application can be easily build by qmake command.
Open the folder that contains the application, enable the QT SDK and compile the application:
cd <path_of_app> . <install_path_sdk>/environment-setup-cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi qmake && make
If the application does not provide the .pro file, it can be created through the command qmake -project. Please check qmake documentation for more information.
For your information, CMake tool begins to replace qmake tool, and we can see it used more and more in different projects.
4. Hints to get better performance on embedded platforms[edit source]
Embedded platforms don't share the same high performance of general purpose personal computers (PC); QT applications that runs flawless on a PC could require some adaptation and optimization to run on an embedded platform. Below there are few examples and suggestion to develop or port a QT application to an embedded platform:
- Designers should have an understanding the performance implications of their designs, and avoid creating solutions that end up being very expensive to render.
- Prefer to use Qt Quick instead of Qt Widget, because it makes it very easy for designers to not just provide assets, layouts, etc., but to actually develop the relevant QML code, either by hand or by using the Designer integrated into Qt Creator. The resulting code is still code, and therefore should be reviewed.
- Avoid having artwork that needs to be resized at runtime (for instance, a full-HD background image, used on a 800x480 display). Instead, prepare all the artwork in the right sizes. In the same way, avoid multiplying opacity level between elements, or big transparent areas in artwork.
- Avoid overdrawing. Sometimes designs stack a lot alpha-blended visual elements on top of each other. This should be avoided as much as possible. When using OpenGL, QtQuick (directly, by setting QSG_VISUALIZE=overdraw, or through GammaRay) can visualize the amount of overdraw in a given scene.
- Avoid too much clipping. Similarly, (ab)using clipping can reduce performances drastically. When disabling the depth/stencil buffers, only screen-aligned clipping is possible (because scissoring is used instead). Generally speaking the problem with clipping is that it might get used inside reusable UI components like buttons, dials and so on, and one might have many of them on the screen at the same time. (QSG_VISUALIZE=clip).
These examples are some good practices when you are hardware-limited but also for any QT applications. That is what explains Giuseppe D'ANGELO from KDAB, in this very good presentation.