Design of touch screen Driver Based on QT/embeded in Embedded Linux

Summary: This article mainly introduces the design of the touch screen Driver Based on QT/embeded in the embedded Linux system, and introduces the working principle and mechanism of the driver interface of the Linux device and the QT/embedded device, combined with a large amount of source code for analysis, the development scheme of touch screen Driver Based on QT/embeded is proposed.

With its open source, kernel robustness, stability, and scalability, as well as the support and maintenance of professional commercial companies and the world's top free software developers, it attracts the attention of embedded system developers and has become a new favorite of embedded operating systems. The touch screen is widely used because of its friendly human-computer interaction, simple and flexible operations, and fast input speed, which greatly simplifies the input of embedded systems. This article introduces the design of the touch screen Driver Based on QT/embedded on the embedded Linux system platform. This solution has been successfully applied to engineering machinery safety instruments and power quality monitor projects. It provides GUI (graphical user operation interface) Support for touch screens and can be customized based on different touch screens.

1. Introduction to QT/embedded
QT/Embedded is a well-known development library for GUI and application development for Embedded Systems released by trolltech. It is a comprehensive C ++ graphic interface application development architecture that inherits all the standard APIs of QT and provides a more compact window generation system than xlib and xwindows systems, directly operate framebuffer (see figure 1 ). The fully modular design and efficient compilation system reduce memory consumption. These make QT/embedded a powerful and comprehensive GUI development tool in an embedded environment. Due to the powerful functions of QT/embedded, it is widely used in various fields, from Consumer Electronics (mobile phones, handheld computers, set-top boxes) to industrial control (medical imaging devices, mobile information systems ).

2. Device Driver basics in Linux
In Linux, devices are divided into character devices, Block devices, and network interfaces. Each module is usually implemented in one type. The corresponding modules can be divided into character modules, block modules, and network modules. However, this classification method is not very strict. programmers can construct a large module to implement different types of device drivers. To achieve good scalability and scalability, we usually need to create a different module for each function.
A character device is a device that can be accessed like a byte stream. It is implemented by the character device driver. It usually requires at least the open, close, read, and write system calls. Character devices can be accessed through file system nodes. For example, character terminals (/dev/console) and serial ports (/dev/ttys0) are examples of character devices. The block device is also accessed through the file system node in the/dev directory. Block devices can accommodate file systems. Linux allows applications to read and write Block devices like character devices and transmit any multibyte data at a time. Therefore, the difference between a block device and a character device lies in the way data is managed within the kernel. That is, the interfaces of the kernel and the driver are different. In addition, block device interfaces must support mounted file systems.
A network interface is a device that can exchange data with other hosts. It is driven by the network subsystem in the kernel and is responsible for sending and receiving data packets. It does not need to know how each transaction maps to actually transmitted data packets.
Other types of driver modules exist in Linux. These modules use the public services provided by the kernel to process specific types of devices. Therefore, we can communicate with the Universal Serial Bus (USB) module and serial port module.
In this system, the Controller converts the original voltage signal collected by the touch screen to the coordinate data through A/D and transmits it to the embedded system through the RS-232 bus (see figure 2 ). Linux uses the serial port module provided by the kernel to process touch screen devices and stores the devices in the/dev directory as files/dev/ttys0, provides open, read, write, close and other system calls. We only need to perform operations on serial devices like operating common data files, and send the touch screen coordinate data to the upper-layer QT/embedded application layer.
 

3. QT touch screen driver
The signal related to user input events in QT/Embedded is built on the Interface call to the underlying input device. It is generally implemented through I/O read/write to the device file. Most of these drivers have been encapsulated in the QT library to form the corresponding device driver interfaces, such as the display card driver, mouse, keyboard, serial port and parallel port. The abstract base class of the mouse device is qwsmouse handler, and some specific implementation classes of the mouse device are derived from this class. In the QT/Embedded series of version 3.3.4, the derived structure of the mouse device 3 is shown.
 
Figure 3 derived structure of a mouse-Type Device)

The loading method of a mouse device is similar to that of a keyboard device. When the system constructs a qwsserver object, it calls the qwsserver: openmouse function :: the openmouse function then calls qmousedriverfactory: Create () or qmousedriverplugin: Create (). This function obtains the device type and node of the mouse device based on the environment variable qws_mouse_proto in Linux. Open and return the base class pointer qwsmousehandler of the corresponding device to the system. The system operates the sub-class device pointer qwscustommousehandler derived from the base class, obtain the call operation for a specific mouse device (see figure 4 ).

Figure 4 software flowchart

Touch screen and mouse are basically the same in terms of functions. Because of this, in the QT library, the touch screen is generally simulated as a mouse device to perform operations on the touch screen device. However, the underlying interfaces of the touch screen and the mouse are not the same, resulting in inconsistent interfaces on the upper layer. For example, the mouse driver interface does not obtain absolute location information, and generally only reads the relative movement. In addition, the acceleration of mouse movement also needs to be taken into account, while the touch screen interface is almost clear absolute bit confidence and pressure information. For such differences, QT/Embedded distinguishes and abstracts the interfaces of the same class of devices and implements them in the qmousedriverinterface class.
In this system, the Linux System reads the touch screen from the COM1 port
But because it is inconsistent with the underlying interface of the touch screen, you need to add the qwscustommousehandler program interface class to control the touch screen. Check the source code qwsmouselinuxtp_qws.cpp and qwsmousevr41xx_qws.cpp of QT/Embedded. We can see that QT provides drivers for linuxtp and vr41xx touch screens. If you are using these two touch screen interfaces, you can directly add the configuration option-QT-mouse-<driver> when executing the configure configuration of QT. Because we do not have the above two touch screens, we need to add driver interfaces.
According to the derived structure of the driver class of the mouse device, you must call the qmousedriverfactory or qmousedriverplugin class to generate a corresponding qwscustommousehandler object based on the corresponding device name, these specific device driver interface classes are derived from the qwsmousehandler class and all inherit the qwsmousehandler class. Then the system calls qwscustommousehandler: readmousedata (). The obtained touch screen positioning and status information are directly sent to the qwsmousehandler class in the abstract layer of the driver class of the mouse device, QT/Embedded uses the qwsmousehandler class to operate the mouse device.
You can add the device driver interface class in two ways. One is to call qmousedriverfactory to generate the corresponding qwscustommousehandler, and the other is to generate the corresponding qwscustommousehandler by adding qmousedriverplugin. We adopt the first scheme to modify the original interface qwsmouselinuxtp_qws.cpp to adapt to the driver interface of the new touch screen device.
First, modify qwsmouselinuxtp_qws.cpp and change the ts_event structure to the data structure of the corresponding device, change the device file node opened in the qwslinuxtpmousehandlerprivate function from/dev/ts to your device file/dev/ttys1. Then modify the readmousedata () function, read the device file according to the data structure, and pass it to the qpoint class to locate the mouse or switch to the mouse button status. The operation of this function can refer to the mouse driver source code in windows.
In fact, after this modification, the touch screen device can be used normally, but two steps must be completed to simultaneously use the mouse and touch screen on the system platform: one is to correctly set the qws _ mouse_proto environment variable. Read qwindowsystem _ qws. the qwsserver: openmouse () function in CPP shows that the environment variable can be set to multiple devices <driver> [: <device>] at the same time. Multiple devices are separated by spaces, therefore, you can set qws_mouse_proto = "auto linuxtp". QT/Embedded generates the corresponding mouse and touch screen driver interfaces through this environment variable to operate the device. Then, modify the source code of the mouse-driven interface class of QT/embedded. Because the touch screen uses the system serial port, and QT/Embedded automatically searches for the mouse interface and finds that the serial port is working, it will be operated as a mouse device, this causes a device conflict. Therefore, we need to remove the serial mouse sub-driver from the qmousepc_qws.cpp file, find the code in the qwspcmousehandlerprivate: opendevices () function, and comment it out.
Else if (driver = "Microsoft "){
Qstring Dev = "device". isempty ()? Qstring ("/dev/ttys0"): device;
FD = open (Dev. Latin1 (), o_rdwr | o_ndelay );
If (FD> = 0)
Sub [nsub ++] = newqwspcmousesubhandler_ms (FD );
} Else if (driver = "mousesystems "){
Qstringdev = "device". isempty ()? Qstring ("/dev/ttys0").: device;
FD = open (Dev. Latin1 (), o_rdwr | o_ndelay );
If (FD> = 0) sub [nsub ++] = new qwspcmousesubhandler_mous esystems (FD );
}

For touch screen calibration, read the qwsmouselinuxtp_qws.h file (the Code is as follows). We can see that the coordinates have been calibrated in qwsmouselinuxtphandler. Generally, you can directly read the coordinates and their statuses.
Class qwslinuxtpmousehandler:
Public qwscalibratedmousehandler
{
};
Finally, you only need to add the option-QT-mouse-<linuxtp> In the configure configuration of QT/embedded and re-compile, applications on the QT/embedded platform can provide touch screen support according to customized requirements.

4. Conclusion
This scheme is consistent with the frame used by the common mouse driver in QT, and the design is concise and clear. It has been successfully applied to the power quality monitor platform, and is stable in operation, accurate in positioning, and responsive. The user-friendly GUI and convenient man-machine interface make the energy quality detector more attractive. At the same time, the advantages of Open Source Code are fully reflected in this solution. by reading a lot of source code, you can fully understand the software working mechanism and customize it according to user requirements, make products that are truly suitable for users.