Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.
A collection of tips & tricks for using Qt on embedded systems. They are usually tested on a TI SoC such as AM35/AM37x, DM816x, etc.
Enabling SGX PowerVR Acceleration
SGX PowerVR OpenGLES acceleration for Qt is available as a plugin graphics driver in Qt. This needs to be enabled both during Qt configuration and Qt application execution. The EZSDK 5.03 released in 4Q11 has out of box support for OpenGLES acceleration in Qt.
If you are using an older SDK release, please refer to Building Qt with OpenGLES acceleration wiki page for building Qt with OpenGLES.
Configuring the SGX PowerVR to recognize QWS EGL
The default WindowSystem for SGX is set to front mode or flip mode. To enable OpenGLES acceleration for a specific Qt application, add the exact binary name to /etc/powervr.ini as follows:
# cat >> /etc/powervr.ini << _EOF [hellogl_es2] WindowSystem=libpvrQWSWSEGL.so.1 [animatedtiles] WindowSystem=libpvrQWSWSEGL.so.1 _EOF
Runing Qt applications with OpenGLES acceleration
To verify Qt is indeed accelerated by OpenGLES, run the hellogl_es2 application on the target.
# cd /usr/bin/qtopia/examples/opengl/hellogl_es2 # ./hellogl_es2 -qws -display powervr
If the application runs correctly, you should see both a 3D Qt logo rendered by SGX via OpenGLES over which 2D bubbles are painted by the Raster Paint Engine.
This acceleration is applicable not only for QGLWidget based applications. Other Qt applications using QWidgets can also be accelerated by adding "-display powervr" while launching as follows:
# cd /usr/bin/qtopia/examples/animation/animatedtiles # ./animatedtiles -qws -display powervr
- The acceleration is not applicable for all 2D painting paths. It' applies mainly to blending and blitting as implemented in PVR2D interface
- The acceleration has been verified only when one Qt application is running at a time. QWS client-server scenarios have not been verified
Using Multiple Displays
High end SoCs support multiple display connectivity options such as HDMI, component, composite. In addition, each interface could have multiple instances. With such devices, it would be possible to connect multiple TVs and drive them individually.
Qt-embedded uses /dev/fb0 as the default framebuffer. To redirect the output to a different display with framebuffer /dev/fb1, do the following:
# ./deform -qws -display LinuxFb:/dev/fb1
You can associate one Qt application per display and run them separately as follows:
# ./affine -qws -display LinuxFb:/dev/fb0 & # ./deform -qws -display LinuxFb:/dev/fb1
The Qt Window System supports a Multi Screen driver - QMultiScreen. With this driver, you can display the same output on both the TVs. The command below runs the deform demo and writes the same image onto both the framebuffers.
# ./deform -qws -display "Multi: LinuxFb:/dev/fb0 LinuxFb:/dev/fb1"
The examples above could be extended for multiple displays.
Using Virtual Display
This requires that Qt was configured with the option '-plugin-gfx-vnc'. Now start any Qt application as follows:
#./deform -qws -display "VNC"
Then connect a remote VNCviewer to your target (of course you need to know the IP address of the target in that case).
You may also use the default display and VNC at the same time:
#./deform -qws -display "VNC:LinuxFb"
Alternatively you can set the display using an environment variable before starting Qt.
#export QWS_DISPLAY="VNC" #export QWS_SIZE="1920x1080"
And yes, you can get real big displays on OMAP3 that way...
If you have a screen supporting touch you need to follow below steps to make this available to your Qt applications.
Make sure you have Tslib installed to your platform. This will provide basic touchscreen support for a couple of devices. We have tested with the TSC2046 that is used on the TI/Mistral OMAP3 EVM for example.
Add dependencies to your mkspec gmake.conf accordingly:
#modifications to include ts-lib QMAKE_INCDIR += /home/omap3/hd/workdir/filesys/usr/share/include QMAKE_LIBDIR += /home/omap3/hd/workdir/filesys/lib
Run Qt configure again with option 'qt-mouse-tslib' (touch as primary mouse device) or '--plugin-mouse-tslib' (touch as optional mouse device). Now recompile Qt base libs.
Finally you need to modify your target environment with the following variables (path and device names are examples):
QWS_MOUSE_PROTO='Tslib:/dev/input/event1' TSLIB_CALIBFILE='/etc/pointercal' TSLIB_CONFFILE='/etc/ts.conf' TSLIB_CONSOLEDEVICE='none' TSLIB_FBDEVICE='/dev/fb0' TSLIB_PLUGINDIR='/lib/ts' TSLIB_TSDEVICE='/dev/input/event1'
You may have to call 'ts_calibrate' once to get your touch screen calibrated. Redo this if you change the rotation or screen size configuration.
QWT (http://qwt.sourceforge.net/) is a useful extension to Qt. To avoid linker issues use the define QWT_DLL when linking a QWT DLL.
Using an USB Keyboard
If you find that an USB Keyboard is not being detected by QT, then you will need to export QWS_KEYBOARD to point to the input devnode. E.g if the USB Keyboard shows up on /dev/input/event1, then run the following
target $ export QWS_KEYBOARD="USB:/dev/input/event1" target $ ./<your-qt-application>
- Use QStaticText for mostly static text items (50% performance impact compared to QText !!) - needs Qt 4.7
- Analyse widget “rendering” performance separately from “screen blitting” performance using “livemem” plugin
- Pre-render large VG images to a bitmap - use optimised class QSvgNativeItem till issue is resolved (reduces CPU load by ~30%)
- Ensure CPU load for UI operations is < 25-40 %
- Do not keep changing large background images
- If using QGraphicsView, do not update all items. Update only when needed and in specific locations
- Avoid Animation in QGraphicsView especially for large images, use optimised classes