eGalax Touchscreen With Linux

By: Tim Starr
e-mail address

Revision History

Revision v1.0.2 - March 18, 2005

Revision v1.0.1 - February 24, 2005

Revision v1.0 - February 5, 2005

Table of Contents

  1. About this Document
  2. Getting the eGalax Drivers
  3. Getting to the Source Files
  4. Needed Packages
  5. Preparing the Kernel Source
  6. Editing the tkusb.ko Makefile
  7. Editing the xfcfg.tcl File
  8. Running the "setup" Script
  9. Calibration and Extras
  10. Aspect Ratio and Modelines
  11. Problems and Troubleshooting
  12. Conclusions and Summary

1. About this Document

This was put together by myself, Tim Starr, after getting sick of forgetting how to do this procedure each time I wanted to use my touchscreen. It was also motivated because no one else seems to have done this and posted their results, so it's always nice to constructively (I hope!) give back. Also this document is written with the Debian GNU/Linux distribution in mind but most of the ideas transfer over to other distributions. This write up was also used with the Lilliput 619GL-70NP model touchscreen. I believe some Xenarc monitors use the eGalax screen as well, but I'm not sure. Also there is a touchkitusb kernel module that comes with recent 2.6 series kernels but I had no success with this module. I had read that you have to change just a couple #defines in the modeule's source to "flip" the x/y axis or some sort and then it'll work- I didn't pursue this route. This is also one of my first "formal" write ups so any comments are very welcome. I hope you find this helpful!

2. Getting the eGalax Drivers

Download the eGalax drivers package from, I used the Fedora Core II package. I don't know if any of the other packages are different from this one but from here on, this document will assume the use of the Fedora Core II drivers.

3. Getting to the Source Files

Run the "installer" named "" by executing the command "sh". The installer will break because of Debian not using the RPM packaging system. However it'll have dropped a nice tar/gzipped file in your temporary directory (usually /tmp) named "touchkit.tgz". There will also be a directory that the mentioned tar/gzipped file was extracted to. Copy one of them (the tgz file or the extracted director) to where you want to work on it, your home directory would be a good choice. Extract the file with "gzip -d -c touchkit.tgz | tar -xvf -" (not necessary if you just copied the extracted directory), this should produce a directory name "touchkit". This is the touchkit source root directory and I will assume from now on that the directory is called "touchkit". Move in to the root of the touchkit source directory, there will be an executable file called, "setup". To get the setup script in a usable form for later on delete lines 11 ("package=(make tcl tk)") through 39 ("done"). Note: I have tried using Debian's alien, but that doesn't solve this I don't believe. I've also re-written the setup shell script with dpkg-query but didn't use generalized version numbers for the required packages so that wasn't a good solution.

4. Needed Packages

Make sure you have the Tcl development files (sudo apt-get install tcl8.4-dev, or any other recent version should work). Also be sure to have the X windows development files (sudo apt-get install xlibs-dev x-dev) and the source to the kernel you want to run the touchscreen under (use "uname -r" to do this and then run dselect and search for "kernel-source" [do this by just hitting '/']). There is also a "tk" RPM mentioned in the setup file but I am not sure which Debian package this corresponds to. I am assuming that this is included in Tcl? I am not familiar with Tcl/Tk so someone correct me here.

5. Preparing the Kernel Source

Go to /usr/src/ , this is where the Debian bzip2 compressed kernel source is placed, if this doesn't apply to you just go to the directory which contains your kernel source.As root unpack the kernel source (change to root user with "su" enter password and type bzip2 -d -c kernel-source-*.bz2 | tar -xvf - ) . Change directories in to the newly decompressed and untarred kernel directory and as root type "make oldconfig" this will put a copy of the last used kernel configuration used. (This assumes you're using the Debian kernel, but I am not even 100% sure this is really the right thing to do. Either way if you have your own kernel you're using you can just use the path to that kernel in the Makefile. But I'm assuming you knew that already... also you could copy it from the /boot directory or use the /proc filesystem to get the kernel config as is supported on the newer kernels- assuming this option has been enabled. Man I need to stop with the parenthesis... I'm just writing this on the fly though) . Also you need to type "make" while in the kernel source directory. You don't have to let it run to completion but make sure the "scripts/.." items have been compiled (Also these are the very first things so it doesn't take long). Again I don't really know why this works, but I figured it out by examing the errors given when just trying to make the tkusb kernel module. The first error it complains about is

make -C /usr/src/kernel-source-2.6.8 SUBDIRS=/home/tstarr/touchkit/usb modules
make[2]: Entering directory `/usr/src/kernel-source-2.6.8'
CC [M] /home/tstarr/touchkit/usb/tkusb.o
In file included from include/linux/module.h:10,
from /home/tstarr/touchkit/usb/tkusb.h:13,
from /home/tstarr/touchkit/usb/tkusb.c:15:
include/linux/sched.h:4:37: asm/param.h: No such file or directory

So I think that when you build a piece of the kernel it'll make your current platform's asm directory the effective asm directory. This would seem to make sense to me and it works, but again I don't fully understand it. Also this is only on a 2.6 series kernel. Not sure how this works on 2.4 kernels.

6. Editing the tkusb.ko Makefile

In the file "Makefile" under the touchscreen/usb directory change the line variable "KDIR:= /lib/modules/$(shell uname -r)/build" to "KDIR:= /usr/src/kernel-source-2.x.x". Note also that this is simply the path to your kernel source that you used in Preparing the Kernel Source.

7. Editing the xfcfg.tcl File

Now enter the "utility" directory of the touchkit source. Begin editing the file "xf86cfg.tcl". Find the line that says "set XF86Config xorg.conf" (line 169), change it to "set XF86Config XF86Config-4". This is the standard Debian X configuration file name. If your X configuration file has a different name, use that name in place of "XF86Config-4" in the operations above.

8. Running the "setup" Script

Now you're ready to actually run the installer. Run the exectuable file "setup" that's in the root directory of the touchkit source, be sure to be root ("sudo ./setup" or "su" and then "./setup"). The installer will immediately hop to (Step 2) because of our modifcations we made in Getting to the Source Files. Now choose "(2) Full Mode ...". You'll see things being compiled and [a lot of] warnings going by. If all went well you should see no errors and the line before your prompt should say "(I) Please RESTART your X Window Server.". Go ahead and do so.

9. Calibration and Extras

You should now have a working touchscreen! I would highly recommend running the included "25pcal" program under the "diag" directory of the touchkit source. You'll most likely need to be root because you'll be accessing the touchpanel via the raw device file. So invoke the program with something like "sudo ./25pcal /dev/usb/tkpanel0". Now you'll enjoy pressing each "bullseye" until it stops pulsating red... all 25 of them. However it's worth it as opposed to just using the simpler 4 point calibration. You can also play around with the "drawtest" application if you want... Also there's a Tcl script called "rbutton.tcl". I assume that this is analogous to the left click/right click floating window that is provided with the windows drivers. I couldn't get it to launch and didn't feel like trying to hack at it seeing as I know even less about Tcl than I do Makefiles and the sort. If anyone can get it to work, I'd love to hear about it.

10. Aspect Ratio and Modelines

I think a word about resolutions and aspect ratios fits as well. This monitor is capable of a number of resolutions. In spite of the fact that the monitor has an aspect ratio of 16:9, many people use "conventional" [4:3] resolutions, resulting in a horrible, squished picture. This happens when you run a resolution such as 800x600, which has an aspect ratio of 4:3 (4/3 = 1.3333, 800/600 = 4/3) on a monitor which really has a 16:9 aspect ratio. I for one can't stand this. For instance when you go in to major consumer electronics stores (read Best Buy, Sears etc.) they always have big beautiful TVs that are 16:9 but are being fed 4:3 sources, again squished! I can't believe people let this happen, but I'm a geek and a lot of people don't care anyway. The point of this is that the Lilliput DOES support 848x480 which works out to be 1.7667... which is pretty close to 16/9 which comes in at 1.7778, my eyes can't notice. However I DO recommend running 840x480 instead because the screen phsyically has 840 horizontal pixels and 480 vertical pixels. Even though their manual lists 848x480 as the native resolution, using this might result in the LCD controller having to do some interpolation (although when running either mode and you bring up the VGA information it still states 848... who knows but I think I a noticeable difference) . Any other opinions?). I might just be seeing things but with things like text I believe their is a noticable difference. Furthermore, losing 8 pixels should hurt anything.

Now, how to actually DO THIS? Well you have to add a Modeline to your XFree86 configuration file. I would recommend using The XFree86 Modeline Generator which can be found at . Alternatively here are some modelines I generated:

Modeline "848x480@72" 38.48 848 880 1024 1056 480 489 495 505
Modeline "840x480@72" 38.14 840 872 1016 1048 480 489 495 505

Nick Kartsioukas adds that for the Xenarc 700 Series the following modeline is suggested:

"800x480" 31.746 800 860 940 1000 480 508 511 525 -hsync -vsync

Add these to the monitors section of your XFree86 configuration file. To actually have the Xserver USE these modelines put them in your Screen section and in the Display SubSections for each color depth you want. Here is my XF86Config-4 file.

Let me add that I am no whiz about modelines or even really understand them, so if anyone more knowledge sees me doing something horrid, let me know. Also you will need to have the LCD autoadjust (so it centers itself) for these modelines. However I still have an ongoing problem when the X server stops sending a VGA signal to the LCD and then when it awakes the picture will be horribly shifted. You could always tweak the DPMS option (which I have as of 2/23/05), and in a lot of applications for a monitor of this type I imagine this would be preferred, just a note though. The real problem lies within when you first start X the picture is misaligned, I'll have to mess with xvidtune some more or learn more about the modelines, any help anyone?

Another note about the your X config file. You may want to add:

Option: "CorePointer"

to your touchscreen "InputDevice" section. This will allow you to only run the touchscreen without another mouse connected to the system. I also was having some weird calibration problems with two mice, but that might've just been a fluke. Nonetheless this is helpful.

Below are the DPMS settings I am using:

Section "ServerFlags"
Option "BlankTime" "5"
Option "StandbyTime" "0"
Option "SuspendTime" "0"
Option "OffTime" "0"

Just copy and paste that in to your XFree86 configuration file if you don't already have a ServerFlags section. If you already have one you can just add those to it. Unfortunately the Lilliput (at least when hooked up to an old integrated AGP Rage 128 video card) will lose it's adjustments if it enteries any DPMS state besides blank. Of course and LCD screen doesn't take up much energy especially a 7" one.

Problems and Troubleshooting

If you are having problems with your touchscreen, like the pointer not tracking correctly at all or not working at all this could be due to having the module "touchkitusb" inserted in to the kernel along with the eGalax touchscreen driver "tkusb". To remedy this simply shut down X (if you're running it), unload both modules (sudo rmmod touchkitusb; sudo rmmod tkusb) and then try reloading tkusb ("sudo insmod /lib/modules/tkusb.ko" also note that this is the directory that the setup script drops the module in by default. If you need to load this by hand or reference it, this is where it lives, I also don't know if this will be persistent across reboots). If you have problems with touchkitusb loading at boot time and are running hotplug you can add an entry to the hotplug blacklist. In Debian edit the file "/etc/hotplug/blacklist" and on it's own line just add "touchkitusb". You may also want to add a comment if you want, or just to go more with the flow of the file :-)

If your monitor won't auto adjust correctly, or if you use a modeline like the ones in Calibartion and Extras but you find that the monitor turns on and is offset but then when it autoadjusts it changes resolutions (you can confirm this by using the menu and then the second from the far left item and then info). It'll still display the the same aspect ratio but I think the controller gets confused about what it's seeing if you have a dark background. I've played with this and if you mostly fill the screen with a lighter color and then adjust it should do it correctly.

And as a truly final word, there are some disadvantages to running such a small resolution. Some applications, notably gpsdrive just won't get small enough to actually fit on the screen. I had heard they were working on this but in general you may run in to this. Perhaps a way to work around this is to enable 1024x768 as well and map a media key or some other hot key to switch between resolutions. This isn't optimal though, but with a 7" LCD trying to run generalized applications, what do you expect?

Conclusions and Summary

This document attempts to make the retailer provided Linux drivers work on any distribution and not just the ones they support. Hopefully you now have a working touchscreen and the retailer supplied tools working. Overall the process should be pretty straight forward although it's not very flexible. In the furture more work could be done to to make the process less of a headache when you upgrade your kernel.

Any questions, comments, suggestions, corrections- basically any feedback is welcomed and appreciated at this point. Enjoy and good luck!

All contents of this site, otherwise noted, © 1999-2005 Tim Starr. All rights reserved.