Thread: Boot times

Originally Posted by TheLlama

Why do you need to hack any of the driver? Can't you put your calibration code inside userspace?

Sorry, what i mean is that i want to make my app portable for other touchscreen users, so should i expect to receive calbrated data in my app or should i make the calibration in my app?

I would plan for calibration in your app. I know one of my friends (who uses a touchscreen with X) complains that is is not calibrated. If you place the calibration code in your app then you will have a single place where all calibration is done.

This will let you use a configurable selection of input methods.

The only downside is, if you plan to use the touchscreen for existing applications. I don't expect this to be a problem however, since you are not even using X.

are you suggesting having a configuration applet/subprogram in the dfb app that is designed to calibrate the touchscreen, and then store the calibration data so that it doesn't have to be re run everytime?

if so, thats a great idea. i've seen a few calibration algorithms online, and if i could, i'd attempt to do that, esp. since i've been wanting to learn how to write a dfb app.

Yes. The basic idea is the user taps the 4 corners of the display and possibly the center.

You store these 4 values then you calculate the difference to your projected points. Let me see if I can explain this more visually.

The user taps the four corners. This will result in four points that will form a quadrilateral. Imagine deforming the quadrilateral to fit your desired range of coordinates (a rectangle equal to the screen resolution). Once you've found the system of equations, you can use it to translate all of the input coordinates.

The easiest way to do this is with a transformation matrix. Do you have any experience with linear algebra?

funny you ask, i'm taking linear algebra right now. i thought i was done w/math forever...anyhow...

the algorithm itself is not that difficult, just as you stated it should be relatively simple. i think the question is really where to do the calibration: a userspace program for all dfb programs, or in the particular frontend app being developed. DirectFB has a driver for egalax, it does detect the touchscreen itself. however, it is not calibrated data (and i don't know if its possible to change/redirect this easily - Steels?). in comparison with x, a calibration program runs, determines this transformation, and x uses the calibrated data and not the raw data via a driver (in /dev). at least thats how i understood it before, i could be wrong. anyone else know better?

i think its simpler to do as you suggested in this particular case - have the frontend itself run a calibration routine and apply this transformation matrix in the program rather than in a psuedo-driver and tell DirectFB itself to listen to that driver

I would not hack into dfb's input routines. There are three methods that seem practical to me. The best would be if dfb has support for a filter to be installed or something to that effect to manipulate the input data before it is sent out. Second, if dfb provides a /dev device for the "mouse" then you can create another character device. Make the device read from the dfb device, translate the point, and then relay it out. Your program can use your new character device as the "input device". I am not familiar with dfb so I don't know if any of those would work. The advantage with both of these is that the calibration is centralized. You can write multiple apps without worrying about calibration.

EDIT: i just noticed you talked about dfb supporting drivers like an egalax driver. Couldn't you write a wrapper driver? You would configure dfb to use your wrapper driver. You can configure your wrapper to load a normal input driver. You just need to relay any events from dfb to the loaded driver. When the loaded driver gets an event, you translate it and send it out to dfb. This is probably the best solution.

The final option is to include the calibration into your application. You can write multiple applications that contain the same calibration code and read from the same configuration. But, any non-aware program will not be calibrated. This will work with dfb or gpm.

Thats about everything I can think of.

Well I was going to make some suggestions but I think Llama has covered all the bases, so I guess this is a null post I would lean toward two of the suggestions made; either create a wrapper driver that your app(s) reads from, or even simpler, include the calibration code in every app. The first is more elegant but the second is probably simpler.

Using the TS drivers which goes through kernel IO does not give you the right data since it is been transformed and scaled already whereas you need a raw data.
The easiest way to do calibration is _not_ to use Egalax driver at all. Just get libusb working in kernel and read _directly_ from Egalax and calibrate it properly in the app.
Another way is to rewrite driver so it creates device, but that will be the same as above.

Before i made a very simple hack to the egalax *kernel* driver, where you would supply the maximum and minimum x and y coords of the TS, plus resolution, and the module would output correct values. (i rather use the linux input driver from DFB)
I figured out those max and min values more or less trial and error, but it would have been very easy to write a simple calibration app, which would tell you the module parameters.

Now i figured im prbably better off doing that in my app, so that anyone who would want to use it (if thats ever the case ) doesnt have to patch the kernel or compile a special module.

Shouldnt there be some standard way of calibrating and using TSs in linux? Or not? In windows i guess you get special drivers and utils with the TS itself...