Yesterday Carlos told me about Ubuntu’s plans for Karmic and the Hal deprecation. I don’t really know how could I miss this, but I didn’t know before…

Lately I was working a bit with Hal and I kinda like it. As far as I saw, there is a GNOME plan for that deprecation and hal will be split into different pieces which will be integrated into other software. Such a udev-extras, libudev, DeviceKit-*, the kernel itself and so.

I’ve been reading quite a lot about all those changes and I don’t really get the reasons for this move. And I don’t really know how the things will work when the migration be completed.

No more hal at all? No hal-info either? just udev rules (which, btw,  I find really confusing and ugly…)?

I hope someone could help me to see how the things will be at the near future around the hardware layer on GNU/Linux.

Thanks

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!

The real goal is to run on those little boxes just a X with a java application other group have made. I can’t tell so much about the project because the contract say so… Anyway, that’s interesting stuff to do

My first thought was to use Moblin, a project I’ve already posted about. This project is designed for those kind of products, have a few sets of funcionalities over small distro base and it has a GUI application for building the distro in different formats and even try out via kvm.

All this sounds really cool to me. I knew the project from time ago, but I didn’t pay enough attention to the project (I wanted, but I didn’t find the moment before), so this was good excuse to have a closer look to the project.

The project is nice, with a lot of cool features and a lot of potential, but, actually, it didn’t fit well with my needs. I got to much troubles to get working a very basic Ubuntu based distro where to run the Xorg and the Java application. But now I’m working on fixing some bug and improve the system a bit…

But I needed to finish my tasks, so I took a different approach. Ubuntu Mobile, which was before with Moblin, now they go by their own (or kind of). They got some images already built so I download one and I started to clean things and installing what I needed.

Now we got the distro and the application running, but we’ve still some issues. The worst thing was to set up the Xorg with the Chrome C9 graphic card. We installed first a Ubuntu 8.04 (lpia) based distro and the graphic card didn’t work out the box. But on the Intrepid (Ubunu 8.10) version we got the last openchrome driver, so it did work

If some one is interesting on make it works on Hardy or another distro which has not the last version, we followed a easy good recipe from Ubuntu docs.

But on Intrepid we found some probles with this driver. The first one wasn’t actually this driver’s issue, it was Xorg’s. I mean, I realized on Intrepid Xorg use Hal and hal-info to for setting up itself.

I tried as a fool to configure the Xorg config file on the old fashion way (dpkg-reconfigure xserver-xorg), but the file was still empty…

After googling for a while and read some hal specs, docs and examples I learn a lot a bout hal-info. This is actually a really good stuff.Richard Hughes with his post about it open my eyes about Hal, which I’ve already known but I didn’t know its potential. Which is huge, I think.

If you are interesting on, here you have the git repository:

[via web]

http://cgit.freedesktop.org/hal-info

[cloning the branch]

git clone git://anongit.freedesktop.org/git/hal-info

I have to use this hal-info thing to let hal setting up the touchscreens properly, because, by default the cursor goes crazy. Don’t worry, I’ll post the quirks and the things I’ll learn when I finish the work

BTW, more interesting stuff here, on quirks docs:

http://people.freedesktop.org/~hughsient/quirk/index.html

Enjoy Hal and hal-info