LG L1730SF touch screen display in Ubuntu Linux 8.04 Hardy Heron, part 2

Let’s continue with setting up the touch feature. In the end of part 1, we managed to rotate and mirror the display properly and just started calibrating it, when we encountered a problem where the cursor at first does not seem to follow the finger, and then suddenly jumps ahead. Let’s solve that next.

Note: You should only read this through, you don’t need to repeat everything I did. The actual solution is in the end of the text, so there’s what you need to do.

Since we now have two drivers in the system for the touch feature, usbtouchscreen for the display device and evtouch for converting the input events to a suitable format for X, the first question that comes to mind is, which one of the drivers is causing the jumpiness? We should go to the source of the information first, i.e. usbtouchscreen.

When you move your finger on the screen, does the data that is output from the usbtouchscreen driver actually change continuously, or does it first stay the same and then suddenly change when the jump occurs? One test could be to type sudo cat /dev/input/eventX, where X represents the event number in your system (recall that you can use cat /proc/bus/input/devices to find it out), but its output is all gibberish. A better alternative is to use a tool that decrypts the event data to plain text. One suitable tool is evtest, which can be found in dvb-utils (yes, tools for watching TV!) package. That package is located in Ubuntu universe repository that we have already enabled. To install it, type

sudo apt-get install dvb-utils

Now you can observe the output of the driver as informative textual message by typing

sudo evtest /dev/input/eventX

(replace X with your event number).

This test reveals for example that 1) as long as you keep your finger on the screen, new data keeps coming in, 2) the display reports the pressure too, although it seems to me somewhat random, 3) when you keep your finger still, you’ll get mainly events with all fields zeros, whereas when you keep moving your finger, values seem to be more reasonable, and 4) the X and Y coordinate values are quite hard to pick from the information stream. Press CTRL+C to stop now.

To get a better idea of the actual coordinates, we can filter the output to only contain Y coordinates with the following command:

sudo evtest /dev/input/eventX/ | grep Y

(replace X with your event number). However, when you are testing, remember that X and Y axels are swapped! When tapping the left edge, the values are near 3950. Right edge yields 200. You can use the same technique to observe the X axel (grep X). When tapping the bottom edge, I got values near 340, and when tapping the top edge, it was somewhere near 3850. These values are very useful for calibration (you can use them in your xorg.conf file), but what is even more important is that when you move your finger, the values seem to grow gradually and continuously. Now we can be sure that usbtouchscreen driver is working just fine, and the jumpiness problem is somehow caused by evtouch.

When using the values from the previous step for calibration settings in the xorg.conf file (instead of the max range values 0, 4095), I got better coverage of the whole screen area with the touch control, although it is still jumpy. I calculated that there are 20 locations along X axel and also 20 locations along Y axel, or 20×20 grid of which intersections the mouse cursor will stop. This is interesting: same amount of stops for both axels, although the screen is not square! Another thing is that when you draw back and forth for a couple of times, possibly sometimes lifting your finger for a while, the cursor does not return to exactly same spots on the screen (you can test that easily with a piece of paper, do not use a marker pen on your screen . In other words, the grid is not fixed but seems to drift a little. This also means that it does not start from 0 coordinate points at the sides of the screen. So, what is going on here? We need to dive in to evtouch…

Evtouch torn open

Next, we can try to find out more about the evtouch driver to learn why it makes the cursor to jump. In console, type command

sudo updatedb

and then

locate evtouch

to find out what files have been installed to the system that include the term evtouch. This reveals for example that there is some readme files in /usr/share/doc/xserver-xorg-input-evtouch folder, which describe the calibration procedure etc. – we will get back to that later. It also reveals that the Debian style package that contained the driver has been cached in the system here: /var/cache/apt/archives/xserver-xorg-input-evtouch_0.8.7-3ubuntu1_i386.deb. The package itself can be manipulated with dpkg-deb tool to list its contents:

dpkg-deb --contents /var/cache/apt/archives/xserver-xorg-input-evtouch_0.8.7-3ubuntu1_i386.deb

This reveals that in addition to readme etc. informational files, the driver package contains these files:

• calibrate.sh and ev_calibrate scripts in /usr/lib/xf86-input-evtouch
• evtouch_drv.so driver in /usr/lib/xorg/modules/input
• empty_cursor.xbm image in /usr/share/xf86-input-evtouch

However, anything in these files could not reveal what is causing the jumpiness. So, once again, let’s look at the source code.

You can download source code for evtouch driver from http://www.conan.de/touchscreen/evtouch.html. At the bottom of the page, there are many download links. Use this one: X driver sources V0.8.7      xf86-input-evtouch-0.8.7.tar.bz2. Download the package and extract it somewhere so that you can look at the files that it contains. There are a lot of files, but only a few with .h and .c filename extensions; these are the source files. As files related to calibration are not necessary for normal operation, you are left with these four files: evtouch.h, evtouch.c, libtouch.h, and libtouch.c. So, there are basically two modules: one is the actual driver, the other contains a state machine for converting taps to mouse clicks. Also, there is INSTALL.txt file that describes a) how to compile the driver and install it, and b) how to turn debug printing on. Let’s do these steps next, so that we can begin testing and modifying the driver.

First, because we’re going to compile the driver, we need the build tools:

sudo apt-get build-essential

Let’s also download and extract the driver source package to a suitable folder:

cd ~

mkdir Source

cd Source

mkdir evtouch

cd evtouch

wget http://www.conan.de/touchscreen/xf86-input-evtouch-0.8.7.tar.bz2

tar -xjf xf86-input-evtouch-0.8.7.tar.bz2

cd xf86-input-evtouch-0.8.7

INSTALL.txt, which contains instructions for compiling and installing from source, says that we need to have sources also for XFree86. However, in Ubuntu we have X.org, which is a newer fork of XFree86 (you can read more about this here: http://ubuntuforums.org/showthread.php?t=87794). The installation instructions seem somewhat outdated, so we will not follow them exactly. To check X.org version, you can type this:

cat /var/log/Xorg.0.log | grep "X.Org X Server"

I got this line: X.Org X Server 1.4.0.90. Note that the debug output of the driver will go to this same file, /var/log/Xorg.0.log – we’ll come back to that later. Assuming you are still in the folder that contains the driver source files, type

./configure

to prepare for building the driver. You may get errors, for example: No package ‘xorg-server’ found, No package ‘xproto’ found. To solve these, you need to install related source packages and try to configure the driver again:

sudo apt-get install xserver-xorg-dev
./configure

This time I got no errors and a ready makefile as output:
config.status: creating Makefile
config.status: creating config.h
config.status: executing depfiles commands

Next, let’s compile the driver with debug output and raw packets output turned on:

make DEBUG=y LOGRAW=y

Unfortunately, I got compilation errors: evtouch.c: In function ‘DeviceOn’: evtouch.c:495: error: invalid use of void expression. If you google around, you’ll notice that other people have had the same problem, apparently because the driver is compatible with Xorg 6.8.x and we have 7.3 in Ubuntu Hardy Heron. Someone even went on to create a new driver (http://www.plop.at/en/touchscreen.html), I haven’t tested that as currently I prefer to get the most common driver, evtouch to work.

So, let’s fix the error. Line 495 contains this text:

DBG (9, XisbTrace (priv->buffer, 1));

We can see that it is used for debugging with a debug macro. If you run

grep DGB *

in the driver’s source folder, you can see that DBG macro is defined in libtouch.c file:

 #define DBG(lvl, f) {if ((lvl) <= debug_level) f;}

This means that if the given number is at most the same contained in debug_level variable, we should run the given function f. We don’t need to debug the contents of the buffer, so we can safely comment it out as follows:

// #define DBG(lvl, f) {if ((lvl) <= debug_level) f;}

Now we can compile again:

make DEBUG=y LOGRAW=y

and it succeeds without errors. Next, type

sudo make install

to install the newly compiled driver.

We need to make sure that X will begin to use our own, compiled driver. Recall that we installed the binary release already, evtouch_drv.so driver located in /usr/lib/xorg/modules/input. We will rename that as follows:

cd /usr/lib/xorg/modules/input
sudo mv sudo mv evtouch_drv.so evtouch_drv.so.orig

Then press CTRL+ALT+F7 to go to X, and restart it with CTRL+ALT+BACKSPACE. In my case, the touch feature stopped working now, so I checked the errors:

cat /var/log/Xorg.0.log | grep EE

Which revealed this:

(EE) Failed to load module "evtouch" (module does not exist, 0)
(EE) Failed to load module "void" (module does not exist, 0)

(EE) No Input driver matching `evtouch'

(EE) No Input driver matching `void'

Apparently, the installation script did not install the driver to correct location. With

sudo updatedb

locate evtouch_drv.so

you can see that it went to here: /usr/local/lib/xorg/modules/input/evtouch_drv.so. So, lets copy that to correct place:

 sudo mv /usr/local/lib/xorg/modules/input/evtouch_drv.so /usr/lib/xorg/modules/input/evtouch_drv.so

Now, try to restart X again. For some reason, Ubuntu switched to safe mode in graphics, and began to use usbtouchscreen without evtouch. Apparently, there is something wrong with the driver, although the source code is supposed to be the latest version. To get rid of the safemode, I had to boot the computer. I wanted to see if DEBUG=y LOGRAW=y parameters had any problems, so I built the driver again and tested it without them as follows:

 make clean
 ./configure
 make
 sudo make install
 sudo mv /usr/local/lib/xorg/modules/input/evtouch_drv.so /usr/lib/xorg/modules/input/evtouch_drv.so

In X, CTRL+ALT+BACKSPACE restulted again to failsafe mode. Apparently, the driver that is compiled directly from source does not work properly as-is. This is getting pretty laborious now.

Get patched

Next, I found out that there are many patches available for the driver in Debian’s (Ubuntu is based on Debian) packages: http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-evtouch.git;a=tree;f=debian/patches;hb=HEAD

The file series contains this information:

 1 #02-buttonless-device.patch

 2 #03_fix_compile_warns.patch

 3 04_include_xf86_ansic_h.patch

 4 #05_build_with_1_4.patch

 5 06_xf86-input-evtouch-0.8.7-misc.patch

 6 07_random_fixes_for_06.patch

So I decided to merge the patches 04, 06 and 07 to the source code that I loaded from evtouch module’s home page, after reviewing the comments in patch files. Especially patch 06 seemed promising with this comment in it: Changed code to compile a working driver for both XInput ABI 0.x and 2.0 (Xorg 1.4.0). Recall that Hardy Heron’s X server version is 1.4.0.90. I loaded the raw patch files with a web browser, copied them to evtouch driver’s source folder and applied them like this:

patch -p1 < debian_patches_04_include_xf86_ansic_h.patch
patch -p1 < debian_patches_06_xf86-input-evtouch-0.8.7-misc.patch

Now I got an error saying: 1 out of 22 hunks FAILED — saving rejects to file evtouch.c.rej. With cat evtouch.c.rej I saw that this change was related to that one line with improper DBG macro usage, which we commented out ourself. No problem, continue:

patch -p1 < debian_patches_07_random_fixes_for_06.patch

After applying the patches, I recompiled and tried again. I also learned from Debian packages that I don’t need to manually copy the driver to correct location, if I give the path in configuration step as follows:

 make clean
 ./configure --prefix=/usr
 make
 sudo make install

In X, give CTRL+ALT+BACKSPACE. This time it did not go to failsafe mode, and the touchscreen worked just like with the pre-built driver version – jumpy.

Now that we have a working setup for building the driver, we can begin modifying it. First thing is to rebuild with debug and raw output:

make clean
 ./configure --prefix=/usr
 make DEBUG=y LOGRAW=y
 sudo make install

In X, give CTRL+ALT+BACKSPACE. The touchscreen works as earlier, and there is no debug information. Apparently, because I did not raise the debug level! Do it like this: in evtouch.c, line 109:

static int debug_level = 3;

i.e. use higher value than 0, at least 2. The higher the value, the more information you get into the log file. However, after recompilation the debug information still did not appear! It seems that the parameters DEBUG=y and LOGRAW=y do now work and INSTALL.txt really is outdated. For example, if you do grep LOGRAW *, you’ll see that the parameter is only mentioned in INSTALL.txt file – so how could it work. However, the DBGOUT macros are in place in the source files, so we can manually turn the debug printing and raw logging on as follows: in file evtouch.h, just below line #define _evtouch_H_, add these two lines:

 #define EVDBG
 #define LOG_RAW_PACKET

Recompile, install and test as usual. This time, debug information appears into the log file. You can view it easily like this:

less /var/log/Xorg.0.log

Reading the log

As you use the touchscreen, new information is added to the file, and this command prints it on the screen so that you can view it easily:

 tail -f /var/log/Xorg.0.log

Let’s see if we can find out anything from debug information. I could see that the screen resolution and desktop size were recognized correctly, and the viewport was initialized ok. To observe if jumpiness is already in the input, I used this command:

tail -f /var/log/Xorg.0.log | grep FIRST

and swiped the screen slowly with my finger from left to right – and I could clearly see how the number first stayed the same and then suddenly jumped! The other alternative would have been input is ok, but calibration goes wrong. Anyway, I moved my finger slowly up, then back down, observing and writing down the numbers. The jump was about 200, most typically 198 (these are not screen pixels, but values from the touch screen. This appeared to be the same for both X and Y axels. Warning: the size of the file /var/log/Xorg.0.log grows pretty fast to tens of megabytes with logging, don’t play around too long (it grows mostly when you touch the screen).

Next question is: what happens to the data before this step? It was alright in the event channel where data was pushed from usbtouchscreen. This debug print comes from function ConvertProc, and these are parameter values that are printed directly, without modification. Thus they are wrong before given to ConvertProc. So, who calls ConvertProc function? Its interesting that in the original, unpatched driver version it does not seem to be called at all in evtouch.c file’s functions. However, in the patched version, there are new functions in the end of the file, and it is called from there. Since there are 4 functions and I don’t know which one is called, I added

DBGOUT(2, "EVTouch: %s\n", __FUNCTION__);

in the beginning of each of these functions, and rebuild the driver. It turned out that when you tap the screen, many one of these gets called. And when you trace the data path
backwards, next you get ReadInput function. There is a debug print function that prints the input event’s basic information: type, code and value. When you do this

tail -f /var/log/Xorg.0.log | grep ReadInput

you can observe what data comes in. When you tap the screen, many lines are printed onto the screen:

EVTouch: ReadInput type:01 code: 0x014a value:1
EVTouch: ReadInput type:03 code: 0×0000 value:2086
EVTouch: ReadInput type:03 code: 0×0001 value:2153
EVTouch: ReadInput type:03 code: 0×0018 value:214
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:215
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:216
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:217
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:218
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:219
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:220
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:221
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:222
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:223
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:224
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:226
EVTouch: ReadInput type:00 code: 0×0000 value:0
EVTouch: ReadInput type:03 code: 0×0018 value:227
…

When I looked at the data, I noticed the first 3 lines: the first one probably is some kind of initiator (screen tapped), the next two are the coordinates from the touch sensor. What is the rest of the data? Why there is so much of it? Then I got it: the values close to 200 are the pressure data. There are many of them because you can keep pressing the same spot on the screen, but alter the pressure. Sampling is fast, so even from a short tap you get many, many samples. Next, try this:

tail -f /var/log/Xorg.0.log | grep "ReadInput type:03 code: 0x0000"

When you move your finger across the screen, the values are changing just fine – no jumpiness. Then why doesn’t the cursor move as it should?

Move limit!

When looking at the code, I noticed that the EVTouchProcessAbs function does not store the X and Y values, if they don’t differ enough from previously set values, and there is a variable for this limit, it is called move_limit in the code. This did not exist in the original driver, it was added in one of the patches (that otherwise made the driver to work with this Xorg version). In function EVTouchPreInit, this value is initialized in code to 180, and it stays in that value UNLESS you configure it differently in your xorg.conf file. Of course, you need to KNOW that such a value exist. And you need to KNOW that the version of the driver that you get with Ubuntu is NOT the original one, but a patched version where many new features have been added. This is just one of them.

Now you can set the debug_level back to 0, and remove debug definitions from evtouch.h file to disable debugging. Recompile and apply.

So, finally to fix the issue: you do not need to compile the driver at all, just use the one provided with Ubuntu, and edit your xorg.conf file as follows:

sudo nano /etc/X11/xorg.conf

Then go to the touch screen section and add this parameter:

Option         "MoveLimit"     "180"

But change the value to smaller! In fact, I found the original patch from the web and there in comments the author explains his xorg.conf file and has used value 18 (!) there, but in code it is set to 180! And, I even found a bug created for Debian about too high default value: http://lists.debian.org/debian-x/2008/06/msg01287.html

So, in the end, the solution was really simple, it was just a configuration bug. But it took quite a lot of work and some crazy stubbornness to find this out.

In part 3, we will finally continue to fine-tuning the calibration of the touch feature.