touchscreen driver

Mark Pustjens pustjens at dds.nl
Wed Apr 26 03:13:44 PDT 2006


Hi everyone,

I recently written a touchscreen driver. This touchscreen driver is 
available as an event device with an absolute pointer. If the mousedev 
kernel module is loaded, it is also available through /dev/input/mice.

Since i use Kdrive, i used a evdev patch i found in bugzilla.

The touchscreen interface returns values for x and y in a certain range,
eg 120 - 960 (different per display). These coordinates should be scaled 
to fit the display resolution (eg: 352 x 416).

Using the evdev driver for Kdrive, the mouse pointer is allways offset by 
some value. This means that some calibration must take place. The problem 
is that i do not know where to put the responsibility of the calibration
of these settings.

Of course the should be an userspace app available, but where should the 
calibration be stored?

My idea was to use the same method jscal uses: ioctl's. This way, 
the kernel input driver would alreay allow to set the min/max x and y 
values. However, the input driver does not support device specific 
ioctl's (at least i didn't find it) which means i cannot set the display 
resolution in the driver this way.

I could get settings into the driver using sysfs, but this does not solve 
the problem that the input driver just does not support this kind of 
calibration.

I could also put the calibration in the userspace app (Kdrive in this 
case). This means that i have to add a touchscreen input driver. I would 
like to be able to use the standard mouse driver.

Another option for evdev in Kdrive is to add scaling support to the mouse 
driver.

So, i would like to ask you to tell me where calibration settings belong. 
Which way would you choose and why? I would really like to understand this 
problem, so any other input is greatly appreciated.

Greetings,

Mark Pustjens

-- 
"[...] a number of offences of murder by means of a blunt instrument, to
whit, a dragon, and many further offences of generalized abetting [...]"
   (Guards! Guards!)



More information about the xorg mailing list