Talking about touchscreens

I was talking yesterday with my good friend Carlos Garnacho about touchscreens and multi-touch and I discover a couple of interesting projects. The first was Garnacho who pointed me out. I didn’t know that project. It was MPX (Multi-pointer X Server).

I tought this was a project for creating drivers for those multi-pointer (or multi-touch) touchscreens which start to be on the streets, but actually is something more. It seems the Xorg X server itself doesn’t support more than one pointer at time, so those people had to make some changes on him.

I didn’t have time yet to read docs and code, or just testing, but I think I’ll try. It looks interesting project to me.

The other project I found was tbeta which is a project for providing a multi-pointer (or multi-touch) support via video input. Which means it emulating a multi-touch screen using video camera to see the pointers (e.g. the fingers).

That’s pretty interesting project as well… And it is not necessary expensive to use it. If you don’t believe me, watch this:


Multitouch Mini (MTmini) – My Cheap Multitouch Pad

More details about the video here

I hope you like those projects 🙂

UPDATED: Another friend (Luis) is working on this stuff and give me some nice links:

Touchscreens on Linux

As I posted before, I’ve been working with a EPIA Mini-ITX with a Touchscreen. But, actually, it wasn’t just one touchscreen. We did configure a few for the same machine and the same system. I’ll tell you how we did just for one (which is kind of tricky) and later what surprise me about those touchscreens…
I though this was a matter of repeat the same steps as I did for the first touchscreen and hook each configuration with each touchscreen depending of their hardware info (vendor and product id, or so), but I got one big surprise with that… I’ll tell you later 😛

Well, the main problem of touchscreens is the calibration. You need to tell to the Xorg the limit of the touchscreen so it can be mapped with the screen. This could be automatic task done by hal, but there isn’t still a automatic tool for that. At least for evtouch driver based touchscreens.

I was playing with the fdi file which came with the evtouch driver to fix the screen, but obviously isn’t a easy task, so I kept googling and I found there was a utility to get the X and Y points and limits. And I felt as a fool when realized that utility was already installed (by the evtouch driver) in my own system… 🙁
Anyways, I ran the tool (/usr/bin/calibrate_touchscreen) and I got the max and min X and Y points. Which means the four corners of the touchscreen.
I couldn’t have the utility working properly… It didn’t show me any message or dialog and it didn’t give me a out.txt file with the result, as the doc told me. But I got the X and Y points, so I put them in my fdi own file for “eGalax” touchscreens.
The evtouch driver have one fdi for eGalax, but the properties doesn’t fit at all with my touchscreens, so I copied the file into /etc/hal/fdi/policy/ and I did the changes there.
The fdi files Hal find in that directory overwrites the ones who were installed by the package on /usr/share/hal/fdi/ (or similar if your distribution is nos Debian alike).

You need to restart the Hal service to get the changes and to let the Xorg realize that.

$ sudo /etc/init.d/hal restart

(or similar)

You can test if the changes were made by running the following commands:

$ UDI=$(hal-find-by-capability --capability input.mouse)
$ lshal -u $UDI

Then you’ll probably get something like:

udi = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0_logicaldev_input'
info.capabilities = {'input', 'input.mouse'} (string list)
info.category = 'input'  (string)
info.parent =
'/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0'  (string)
info.product = 'eGalax Inc. Touch'  (string)
info.subsystem = 'input'  (string)
info.udi = '/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0_logicaldev_input'
(string)
input.device = '/dev/input/event1'  (string)
input.originating_device =
'/org/freedesktop/Hal/devices/usb_device_eef_1_noserial_if0'  (string)
input.product = 'eGalax Inc. Touch'  (string)
input.x11_driver = 'evtouch'  (string)
input.x11_options.longtouched_action = 'click'  (string)
input.x11_options.longtouched_button = '3'  (string)
input.x11_options.longtouchtimer = '750'  (string)
input.x11_options.maxx = '1912'  (string)
input.x11_options.maxy = '1989'  (string)
input.x11_options.maybetapped_action = 'click'  (string)
input.x11_options.maybetapped_button = '1'  (string)
input.x11_options.minx = '112'  (string)
input.x11_options.miny = '76'  (string)
input.x11_options.movelimit = '10'  (string)
input.x11_options.oneandhalftap_button = '2'  (string)
input.x11_options.rotate = 'ccw'  (string)
input.x11_options.swapy = true  (bool)
input.x11_options.taptimer = '30'  (string)
input.x11_options.touched_drag = '1'  (string)
linux.device_file = '/dev/input/event1'  (string)
linux.hotplug_type = 2  (0x2)  (int)
linux.subsystem = 'input'  (string)
linux.sysfs_path = '/sys/class/input/input1/event1'  (string)

Now Hal know your touchscreen preferences and limits, so Xorg will set up the right values for the cursor and so. If you try to start the X server you’ll see.
It’s possible you have to do the process a few times. The perfect calibration could need it.

But, at this point, I found a new problem: when I rebooted the machine, the cursor gone crazy again… 🙁
Well, the thing is the package ‘xserver-xorg-input-evtouch‘ install you a init script for setting the hal parameters from his own conffile (/etc/evtouch/config). This file was generated for the calibration tool (I didn’t know and I haven’t seen still in the doc of the tool…).
The file has something like:

MINX="140"
MINY="55"
MAXX="1888"
MAXY="1975"
X0="-9"
Y0="-588"
X1="391"
Y1="-588"
X2="795"
Y2="3"
X3="-398"
Y3="-298"
X4="-3"
Y4="4"
X5="390"
Y5="300"
X6="-788"
Y6="-2"
X7="-393"
Y7="299"
X8="-4"
Y8="593"

The init script got this values and set up the hal ‘input.x11_options‘ and the script is launched after the hal’s, so it will overwrite any fdi I put in there. But the problem for me is the only values were working for me were the MIN and MAX X and Y. The rest just makes the X server getting lost.

What I did to fix the situation was deleting from the /etc/evtouch/config file everything but the MAX and MIN values and also deleting the input.x11_options for those MAX and MIN values from the fdi file I wrote. The file (the fdi one) was still useful to set up the rotate and more X11 options.

So now I got all the values I need set up and I’m sure no other scripts or services will mess with my configuration.

Ok, now I have the configuration for ONE of the touchscreens, but there are more… What now? well, doing the same process (knowing the issues and taking the sorter way) and figure the way to put the right configuration depending of what touchscreen is plugged.

Ummmmm… I show directives on fdi files to match strings and search for hal properties. I just need to looking for the usb.vendor_id and usb.product_id hal properties to choose which configuration set up. But here was my surprise….
All the touchscreens I have (and more some friends checked out) have the same vendor and product id. All are different and have different calibration values, but all have the same vendor and product id, which let me with no way to know which touchscreen is plugged. At least, by now, I don’t know how to be sure about which one is plugged.
Please, if anyone know how, tell me.

You can make the test if you have one or more touchscreen which work with evtouch driver. Run a ‘lsusb‘ and I almost sure you’ll get this line:

Bus 002 Device 002: ID 0eef:0001 D-WAV Scientific Co., Ltd eGalax TouchScreen

Well, that’s all for today folks. Soon more 😉

Happy hols for those of you who have Xtmas hols and happy hacking! 🙂

Creative Commons Attribution-ShareAlike 3.0 España
This work by Juanje Ojeda is licensed under a Creative Commons Attribution-ShareAlike 3.0 España.