Graphical development of QT/embedded

Embedded GUI provides a human-computer interaction interface for embedded systems, which greatly facilitates the Human-Computer Interaction of embedded systems and accelerates the popularity of embedded systems. Embedded GUI is indispensable for the popularity of smartphones, PDAs, MP4 and PMP (personal media players. To adapt to embedded systems with limited resources, embedded GUI usually requires a simple, intuitive, reliable, and fast response. In addition, to adapt to the diversity of embedded system hardware, embedded GUI requires high portability and reduction to meet different hardware conditions and requirements. Because of the high requirements on Embedded GUI, so far, there are not many embedded guis available in embedded Linux. This article will introduce some development knowledge of QT/embedded, a widely used embedded GUI.

Basic knowledge
An embedded GUI system that can be transplanted to multiple hardware platforms must at least abstract two types of devices, that is, the graphic abstraction layer gal (graphic abstract layer) that is responsible for displaying graphical interfaces) and the input abstraction layer ial (input abstract layer) responsible for receiving and processing input (generally the input device is a keyboard or touch screen ). On the gal and ial layers, perform specific operations on specific display devices and input devices, and shield the upper-layer software from the technical implementation details of different hardware as much as possible, this provides unified programming interfaces for upper-layer application developers. The design concepts of GAL and ial layers greatly improve the portability of Embedded GUI.
Currently, framebufer is used in the QT/embeddedgal layer technology.
QT is a cross-platform C ++ application development framework. Programmers can use it to write applications with a single code, and can run locally on different platforms such as Windows, Linux, UNIX, MacOS X, and embedded Linux. Currently, QT has been successfully applied to thousands of commercial applications. In addition, QT is the foundation of the open-source KDE Desktop Environment.
QT/Embedded (hereinafter referred to as QT/E) is an embedded Linux version of QT. QT/e continues the powerful functions of QT, and now a large number of heavyweight applications such as KDE are developed based on QT. Therefore, by using QT/E on embedded systems, desktop applications can be easily transplanted to a variety of embedded platforms, which greatly simplifies the application software development of embedded systems, QT/E is widely supported. QT/e can develop various types of products and devices on the market, from consumer appliances (mobile phones and PDAs) to industrial control devices (such as medical imaging devices and mobile information systems ).
On top of QT/e, qtopia is the first comprehensive application development platform for Embedded Linux. It can and has been applied to many Linux-based PDAS (Personal Digital Assistant) devices and smart phones.
Similar to QT, the QT/E Class Library fully adopts the C ++ encapsulation, but the X-window is discarded at the underlying layer. Instead, the frame buffer is used as the underlying graphic interface. Therefore, QT/E has rich control resources and good portability.
.

Compile and install
A large number of Linux BSP (Linux board-level support packages) are developed on Red Hat 9.0. So for convenience, I use red
Hat 9.0 is used as the development platform. In addition, as a development machine, you often do not need to consider security issues. To prevent unnecessary troubles, you can directly use root login.
During the establishment of the QT/e development environment, the software and code used can be obtained from the trolltech official site for free, using the 3.3.4 installation package of QT/e.
Many companies still use the QT/e 2.x version, because 2.x appeared earlier, so the support in various aspects is relatively complete and stable. But the new version of installation configuration is easier, do not need to manually configure tmake, do not install the configuration Qt-X11 can also be used normally, so here we recommend that you use a newer version. During use, I found that the cross-compilation environment provided by many companies can be used normally during version 2.x compilation, but compilation errors may occur during version 3.x compilation. For this problem, it can only be returned to version 2. x.

1. Install QT/e 3.3.4
Run the following command in Linux:
# Tar xfz qt-embedded-eval-3.3.4.tar.gz
For convenience, rename the decompressed folder as a qt-3.3.4
# Cd qt-3.3.4
Follow the install prompt and enter the following content:
# Export qtdir = ~ Qt-3.3.4
# Export LD_LIBRARY_PATH = ~ /Qt-3.3.4/lib: $ LD_LIBRARY_PATH
#./Configure
Configure the compilation options as prompted. Note that ". the/configure script is compiled for the current Linux platform version by default. To compile the version running on the embedded platform, configure the cross-compilation environment, run the following command to configure the compilation options:
#./Configure -- embedded xxx
For more information, use the "./configure-help" script to print all available configuration options and specific usage.
Here we can see some default configuration information (marked with an asterisk ). If you want to change the default configuration, you can add the corresponding parameters directly after./configure. After the configuration is complete, you can use the make command to compile the entire project.

2. Run demo
After compilation, you can run a demo to check whether the above work is correct. At this time, you need to check whether the computer supports framebuffer (frame buffer). The simplest way is to use the command:
# Cat/dev/FBO
If garbled characters are output, you can directly use "Ctrl" + "Alt" + "f1" to switch to the console and run the command directly ~ /Qt-3.3.4/examples/Under the demo to see the effect, if the computer does not support framebuffer, that is, the machine output "cannot find the fb0 file or directory ". Don't worry if you don't support it, because the kernel of the current release version basically supports frame buffer during compilation, but this option is not enabled, in this case, you need to open the menu under/boot/grub. find the option corresponding to the operating system in the LST file. For example, the author's machine is as follows:
Title Fedora Core (2.6.11-1.1369_fc4)
Root (hd0, 0)
Kernel/vmlinuz-2.6.11-1.1369_FC4 Ro root =/dev/volgroup00/logvol00 rhgb quiet
Initrd/initrd-2.6.11-1.1369_FC4.img
Modify the line of the kernel:
Kernel/vmlinuz-2.6.11-1.1369_FC4 Ro root =/dev/volgroup00/logvol00 rhgb
Quiet VGA = 0x317.
The values after VGA = 0x can be found in the following table.

Color count	640x480	800x600	1024x768	1280x1024
256	Zero X 301	Zero X 303	Zero X 305	Zero X 307
32 K	Zero X 310	Zero X 313	Zero X 316	Zero X 319
64 K	Zero X 311	Zero X 314	Zero X 317	0x31a
16 m	Zero X 312	Zero x 315	Zero X 318	0x31b

Below are several demo outputs that the author compiled and run.
# Cd examples/laucher
#/Launcher

# Cd examples/Hello
#./Hello-qws

# Cd examples/demo
#./Demo-qws
Note the following when running the demo:

• QT/e embedded applications need to output the display results to framebuffer. When running this program on the command line, add the-qws option after the program name. -The qws option indicates that the application becomes a server.
• After performing the preceding operations, QT/e does run normally on the screen and the application interface appears, however, when you move the mouse or use the keyboard to enter commands, some abnormal displays are displayed. This is because the mouse and keyboard are not properly configured. Find the device file corresponding to the mouse and keyboard, use the following command to configure:
  # Export qws_mouse_proto = <type >:< devioe>
  For example, "Microsoft:/dev/ttys0" or "mouseman:/dev/input/mouse0.
  # Export qws_keyboard = <device> such as/dev/tty.

Install and run qvfb
If the framebuffer module is not selected during kernel compilation, you can also see the running result of QT/E through qvfb, which requires Qt-X11 installation. It should be noted that qvfb cannot be used when QT/E is transplanted to the embedded platform, that is, qt_no_qws_vfb should be defined in the product library.
Virtual frame buffering (qvfb) uses the shared storage area to simulate frame buffering (that is, a virtual frame buffering) and displays frame buffering in a window (the main window of the qvfb program. The displayed area is changed and updated cyclically. Therefore, we can see discontinuous snapshots of frame buffering, rather than each individual painting operation. For this reason, some problems occur during painting, such as flickering. When the program uses a real frame to slow down the operation, it will not appear again.
Qvfb can set the target refresh speed through the "View"-"refresh rate" menu item. In this way, you can control the qvfb check speed and the speed of the region to be refreshed. The refresh speed is just a metric. If a small painting operation has been completed, frame buffering will no longer be updated between painting events. If an application displays an animation, the update will be more frequent, and the application and qvfb will compete for the processor time.
Mouse and keyboard events are passed to the QT/e embedded main program for processing through the naming pipeline.
Virtual frame buffering is just a development tool. No security issues are taken into account in the design of virtual frame buffering. This problem should be avoided in the product environment.
1. Install
Qvfb is a Linux program. You only need to compile it as a common application without having to consider cross-compilation and transplantation. The steps are as follows:

• Decompress qt-x11-eval-3.3.4.tar.gz to the/usr/local/directory and rename it to QT.
• Run the following command:
  # Export qtdir =/usr/local/QT
  # Export Path = $ qtdir/bin: $ path
  # Export manpath = $ qtdir/MAN: $ manpath
  # Export LD_LIBRARY_PATH = $ qtdir/lib: $ LD_LIBRARY_PATH
• Configuration and compilation
  #./Configure
  # Make
• Compile qvfb
  # Cd tools/qvfb/
  # Make

Then you can directly run qvfb.
In this case, if you want the Q/e demo to run in qvfb, add the qvfb Option When configuring Q/e compilation.
#./Conligure-qvfb
Then run the "make" command again to compile the file. (If the file has already been compiled, run the "make clean" command first ). Before running the demo, start qvfb and make the following Configuration:
#./Qvfb
Select the "file"-"Configure" menu. Note that the color digits here must be the same as the ones used to compile QT/e.
When the program on QT/E is running, it will find the resolution and other attributes supported by frame bufer. Although it can also obtain the number of color digits supported by the frame buffer device, however, during QT/e compilation, you must specify the supported color digits. If the device does not support the corresponding color digits, the program will not be able to run.

2. Run
After the configuration is complete, you can execute it to see the effect.
# Cd examples/Launcher
#./Launcher

# Cd examples/Hello
#./Hello-qws

# Cd examples/demo
#./Demo-qws
All the work has been compiled and tested in the author's PC Fedora Core 4 environment.
As a user-layer platform, QT/e interacts with devices only through device files of input/output devices and frame bufer devices. On an embedded platform that can already run, as long as the driver is complete. QT/e can run normally without making any adjustments. Development and debugging of applications on QT/e can be performed on the developer's PC, applications on QT/e that can be normally executed on the PC are basically normal on the embedded platform (there may be some differences in the display effect of qvfb virtual frame buffering ), this greatly reduces the difficulty of development on the embedded platform, thus providing a powerful guarantee for the efficient development of embedded programs.