TheLlama

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

Steels

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?

TheLlama

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.

ruzzmon

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.

TheLlama

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?

ruzzmon

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

TheLlama

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.

intuitionsys

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.

__________________
Silverwolf 2.0 Progress: 100% (alpha)
Alpha Release Date: June 28, 2007

jbors

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.

__________________
Car2PC adapter. Car pc integration with ease
Car mediacenter

Steels

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...

ruzzmon

i was originally alluding to the 'wrapper' idea as the best idea for a dfb app. the only difference is that i suggest doing the transformation every time an input is received from the touchscreen, in the app itself. to better illustrate, the raw data (x,y) is received by dfb via the linux input event driver. then, the linear transformation is applied (determined by the calibration app), giving (x',y'), which is actually used to determine location of the touchscreen event. i'm not sure if this can easily by done programmatically, but if it can, i think it would be the best solution.

but steels has the ideas figured out, so thats all that matters...

i think using libusb is a more convoluted method than the wrapper method, as it entails a low-level understanding of the protocol touchscreens, and each particular model, use. applying a transformation matrix to the event driver should be much simpler.

jbors - how do you do calibration in your app?

as for a standard method, i think it really depends on what interface you're using: x has its own 'standard' method that is probably useable across desktops, dfb has the potential of having another 'standard' method, and the console may not have a real good use (maybe ncurses-style programs?). but you do bring up a good point - maybe a dfb app can be written to use the modified/calibrated touchscreen data like x programs do. this is what i thought to do initially, but why do that when the only app you're running is a front-end? this is why i think for this particular application, an internal calibration routine is simplest. hope that makes sense.

steels, can you start a new thread about your app? i for one am very interested, and it seems as though there are many others as well. and we're clobbering this boot time thread...

Steels

ok ill do, for sure. i just didnt go to school since monday and i havent done anything new to the app. But im gonna finish a 'beta' version soon, to be used in my own car at least, and ill post it here.

Link420

I've thought about replacing the startup scripts with a compiled program as well. But as I started thinking about it more, what I was trying to get around was the init.d-style scripts that load bash and possibly other files over and over again - one for each script in init.d. It's good for script-management, but horrible for efficiency. A BSD-style init script would almost eliminate that, though. However, if you still try the compiled rc script, I'd be interested in hearing if it makes a noticable difference.

-Link

P.S. First post, hello all

Edit: P.P.S. Holy crap I just realized this was a year old. Sorry

shotgunefx

Don't think it will help. Intepreted vs compiled is not that big a deal. Most shell scripts are small so it's not a lot of code either way (though don't know how bash/sh fair vs something like Perl which is a bit of both, compiled to opcodes).

Compared to the time to actually create the process, it's probably negligable.

__________________
GE Cache Builder | me@cardomain |Coolstuff :autospeed.com | bit-tech.net | Nitemax Ultra Pinouts

wirelessdreamer

i'm at 30 sec from coldboot in gentoo booted into x autologed in through gdm before vlc starting to play music. i then have all the other apps preload onto other desktops ready to go when i want them. prob can shave another 3 sec off if a compile a few more drivers into the kernel.