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! 🙂
I’m curious: did you try your touch screens with the latest ‘evdev’ driver? I did some work some months ago to make touch screens work with this driver, and it worked just fine for me. This should make the ‘evtouch’ driver redundant, and simplify some of the configuration stuff (plus give you hotplugging, run-time calibration (no need to restart X), etc.).
As to your question, I cannot think of any way to match configuration with screens unless you have some way of telling the screens apart. I think you’ll have to make some dirty hacks that will be tied to your specific setup.
Søren
It doesn’t look intuitive at all, but i wonder if that can be useful with USB touchscreens.
Hi!
Of course on product line can have different properties, but the same product id. You should check the report descriptor of the device. I think a touch screen is a HID device, so join the libhid maling list and/or try to figure out how to read the report descriptor of the touchscreen. Good luck!
I have 3 touchscreens on a single computer (all Elo)… I ended up using the evtouch driver as well. The only way I could figure out how to tell the screens apart was from their serial number and writing a udev rule to make the naming of them consistent.
They also have the same vendor and product IDs… I would love to remove the hardcoding of the serial numbers.. I had one idea of doing it (specific to my setup) based on the type of USB hub its plugged into but udev rules didn’t seem flexible enough to get that working… Also on one of the touchscreens the mouse gets misaligned with whats on the screen… using SWCursor fixes this but causes the cursor to flicker on OpenGL apps…
I tried the evdev trouble but it didn’t seem to have any support for multiple screens. (you’ll need to use the screen option to evtouch in the xorg.conf to relate the right USB to the right screen)
@Søren Hauberg: No, I didn’t. This was the driver the doc told to use and the one hal-info set up for me automatically. And, with some problems at the beginning, it was working well, so I had no reason to try other.
Now I don’t have any of those touch screens to test them, but when I can I will.
Thanks for the tip 🙂
@J. Félix Ontañón: It’s not. Not at all. Those were USB touchscreen and this was what I had to do to make them work, but it’s not the way. They are working on better autocalibrate tool, but by now this is what I found.
Actually, this was not a magic solution I wanted to post, but a try to write down somewhere all the info, issues, “solutions” and thoughts I was finding on my way.
I found how hal-info fdi files work and also the relationship between Hal and Xorg in the current versions, I learn a lot about touchscreens, I was browsing into udev, hal, init scripts and so to discover all this, so for me it’s more important what I learn by the way than the still unsatisfactory solution 🙂
@comicinker: Thanks for the tip. My problem is all the info I found from those devices are product and vendor id which are the same. I didn’t check more hid info (and I won’t be able to do that until I come back to work), but I was looking for info on the net and seems the only different data they could give me is the serial number, which is not really helpful as Adam says.
Anyway, I’ll will ask libhid guys in case they have any idea. Thanks 🙂
@Adam: I was thinking about to do the same. Kind of hack with udev rules. Until the other day I didn’t know about the serial number, but now I can use it. Have you the rules you use over there? They could save me some work 🙂
But I think I’ll keep looking for a better solution. Must be a way to know which touchscreen is plugged….
Thanks guys for your comments, you give me some ideas to follow 🙂
shame the autocalibrate is no good. thanks for sharing your findings it does help.