From: Holger Schurig <[email protected]>
Generic calibration support for usbtouchscreen.
Signed-off-by: Holger Schurig <[email protected]>
---
With build-in calibration support, the "swap_xy" kernel parameter
vanishes and usbtouchscreen instead gains a new kernel-parameter
which holds 7 integers.
This is used to calibrate the resulting output of the driver. Let
x_o and y_o be the original x,y coordinate, as reported from the
device. Then x_r,y_r (the x,y coordinate reported to the input event
subsystem) are:
x_r = ( a*x_o + b*y_o + c ) / s
y_r = ( c*x_o + d*y_o + e ) / s
The default values for (a,b,c,d,e,s) are (1,0,0,0,1,0,1). To
simulate swap_xy, one would set them to (0,1,0,1,0,0,1). Once can
also use swap_x or swap_y alone, or define other, linear
transpositions. The algorithm used is the same as in Qt/Embedded
3.x for the QWSCalibratedMouseHandler.
This interface allows re-calibration at runtime, without
restarting the X-Server or any other event consumer.
Please review this patch and schedule it for inclusion once
2.6.19 comes out.
--- linux.orig/drivers/usb/input/Kconfig
+++ linux/drivers/usb/input/Kconfig
@@ -219,6 +219,32 @@
To compile this driver as a module, choose M here: the
module will be called usbtouchscreen.
+config USB_TOUCHSCREEN_CALIBRATE
+ default n
+ bool "Calibration support"
+ depends on USB_TOUCHSCREEN
+ ---help---
+ With build-in calibration support, the "swap_xy" kernel parameter
+ vanishes and usbtouchscreen instead gains a new kernel-parameter
+ which hold 7 integers. You can also access this with cat/echo
+ via /sys/module/usbtouchscreen/parameters/calibration
+
+ This is used to calibrate the resulting output of the driver. Let
+ x_o and y_o be the original x,y coordinate, as reported from the
+ device. Then x_r,y_r (the x,y coordinate reported to the input event
+ subsystem) are:
+
+ x_r = ( a*x_o + b*y_o + c ) / s
+ y_r = ( c*x_o + d*y_o + e ) / s
+
+ The default values for (a,b,c,d,e,s) are (1,0,0,0,1,0,1). To
+ simulate swap_xy, one would set them to (0,1,0,1,0,0,1).
+
+ This interface allows re-calibration at runtime, without
+ restarting the X-Server or any other event consumer.
+
+ If unsure, say N.
+
config USB_TOUCHSCREEN_DMC_TSC10
default y
bool "DMC TSC-10 device support" if EMBEDDED
--- linux.orig/drivers/usb/input/usbtouchscreen.c
+++ linux/drivers/usb/input/usbtouchscreen.c
@@ -49,9 +49,16 @@
#define DRIVER_AUTHOR "Daniel Ritz <[email protected]>"
#define DRIVER_DESC "USB Touchscreen Driver"
+#ifdef CONFIG_USB_TOUCHSCREEN_CALIBRATE
+static int cal[7] = {1, 0, 0, 0, 1, 0, 1 };
+module_param_array_named(calibration, cal, int, NULL, 0644);
+MODULE_PARM_DESC(calibrate, "calibration data");
+
+#else
static int swap_xy;
module_param(swap_xy, bool, 0644);
MODULE_PARM_DESC(swap_xy, "If set X and Y axes are swapped.");
+#endif
/* device specifc data/functions */
struct usbtouch_usb;
@@ -499,6 +506,12 @@
input_report_key(usbtouch->input, BTN_TOUCH, touch);
+#ifdef CONFIG_USB_TOUCHSCREEN_CALIBRATE
+ if (cal[6]==0)
+ cal[6] = 1;
+ input_report_abs(usbtouch->input, ABS_X, (cal[0]*x + cal[1]*y + cal[2])/cal[6] );
+ input_report_abs(usbtouch->input, ABS_Y, (cal[3]*x + cal[4]*y + cal[5])/cal[6] );
+#else
if (swap_xy) {
input_report_abs(usbtouch->input, ABS_X, y);
input_report_abs(usbtouch->input, ABS_Y, x);
@@ -506,6 +519,7 @@
input_report_abs(usbtouch->input, ABS_X, x);
input_report_abs(usbtouch->input, ABS_Y, y);
}
+#endif
if (type->max_press)
input_report_abs(usbtouch->input, ABS_PRESSURE, press);
input_sync(usbtouch->input);
--
M&N Solutions GmbH
Holger Schurig
Dieselstr. 18
61191 Rosbach
06003/9141-15
hi
On Thursday 16 November 2006 11.25, Holger Schurig wrote:
> From: Holger Schurig <[email protected]>
>
> Generic calibration support for usbtouchscreen.
>
> Signed-off-by: Holger Schurig <[email protected]>
>
> ---
>
> With build-in calibration support, the "swap_xy" kernel parameter
> vanishes and usbtouchscreen instead gains a new kernel-parameter
> which holds 7 integers.
>
> This is used to calibrate the resulting output of the driver. Let
> x_o and y_o be the original x,y coordinate, as reported from the
> device. Then x_r,y_r (the x,y coordinate reported to the input event
> subsystem) are:
>
> x_r = ( a*x_o + b*y_o + c ) / s
> y_r = ( c*x_o + d*y_o + e ) / s
>
> The default values for (a,b,c,d,e,s) are (1,0,0,0,1,0,1). To
> simulate swap_xy, one would set them to (0,1,0,1,0,0,1). Once can
> also use swap_x or swap_y alone, or define other, linear
> transpositions. The algorithm used is the same as in Qt/Embedded
> 3.x for the QWSCalibratedMouseHandler.
>
> This interface allows re-calibration at runtime, without
> restarting the X-Server or any other event consumer.
>
>
> Please review this patch and schedule it for inclusion once
> 2.6.19 comes out.
sorry, but i have to give you a big NACK on that one:
- no more modparam: it should be per-device sysfs attributes
(swap_xy is basically only for touchkitusb compatibility and shoud be
converted to per-device sysfs attribute as well. i just never got to
do it)
- calibration can be handled in userspace just fine
- even for in-kernel it's in the wrong place. there are other devices
that report raw absolute data...so it would belong to the input layer
Cc'ing Dmitry Torokhov as he might have some comments about calibration
support in the input layer.
thanks, rgds
-daniel
> sorry, but i have to give you a big NACK on that one:
Hehe, I actually anticipated this NACK :-)
> - no more modparam: it should be per-device sysfs attributes
> ? (swap_xy is basically only for touchkitusb compatibility and
> shoud be converted to per-device sysfs attribute as well. i
> ? just never got to do it)
That would be okay for me.
> - calibration can be handled in userspace just fine
Yes it can, and that is the most convinging argument against my
patch.
However, user-space calibration often sucks. For example, in X11
the calibration values are stored in /etc/X11/xorg.conf, so a
calibration program has to parse & write that file. And I've
seen binary-only-calibration programs from vendors
use /etc/X11/XF86Config, which doesn't exist here. Anyway, once
you've calibrated you have to restart X-Windows, so you need to
terminate all running X applications just because of a silly
re-calibration. Not nice.
A calibration at kernel level (may it be input level or driver
level) doesn't have this problem. I can make the level
persistent via udev, modules.conf or other means. Even when I
have a frame-buffer based calibration utility, the calibration
would be OK for X11 or GTK/DirectFB as well.
For me, this speaks against "Calibration is purely a user-space
problem".
> - even for in-kernel it's in the wrong place. there are other
> devices that report raw absolute data...so it would belong to
> the input layer
Suppose I have a graphics tabled and a touchscreen connected at
the same time. Can I distinguish this easily at the input layer
level?
I can very easily distinguish this at the device driver level.
After all, the individual calibration parameters are a property
of this individual device.
Hi,
On 11/17/06, Holger Schurig <[email protected]> wrote:
> > sorry, but i have to give you a big NACK on that one:
>
> Hehe, I actually anticipated this NACK :-)
>
> > - no more modparam: it should be per-device sysfs attributes
> > (swap_xy is basically only for touchkitusb compatibility and
> > shoud be converted to per-device sysfs attribute as well. i
> > just never got to do it)
>
> That would be okay for me.
>
Actually I think having module parameter is OK as long as we have
comlementing device attribute. Then user has an option to either
specify default value for the parameter at load/boot time or fiddle
with an individual device.
> > - calibration can be handled in userspace just fine
>
> Yes it can, and that is the most convinging argument against my
> patch.
>
> However, user-space calibration often sucks. For example, in X11
> the calibration values are stored in /etc/X11/xorg.conf, so a
> calibration program has to parse & write that file. And I've
> seen binary-only-calibration programs from vendors
> use /etc/X11/XF86Config, which doesn't exist here. Anyway, once
> you've calibrated you have to restart X-Windows, so you need to
> terminate all running X applications just because of a silly
> re-calibration. Not nice.
>
I believe tslib handles this.
> A calibration at kernel level (may it be input level or driver
> level) doesn't have this problem. I can make the level
> persistent via udev, modules.conf or other means. Even when I
> have a frame-buffer based calibration utility, the calibration
> would be OK for X11 or GTK/DirectFB as well.
>
> For me, this speaks against "Calibration is purely a user-space
> problem".
>
> > - even for in-kernel it's in the wrong place. there are other
> > devices that report raw absolute data...so it would belong to
> > the input layer
>
> Suppose I have a graphics tabled and a touchscreen connected at
> the same time. Can I distinguish this easily at the input layer
> level?
>
> I can very easily distinguish this at the device driver level.
> After all, the individual calibration parameters are a property
> of this individual device.
>
Yes, but evdev is the interface between input layer and userspace. If
we ever implement in-kernel calibration I think we'll add
recalibrate() method to input device structure and have EVIOCSABS
ioctl handler call it. But I'd look at tslib first. I believe Qt,
Xserver, etc support it.
--
Dmitry
> I believe tslib handles this.
The special X server "KDrive" supports tslib, this is used in
many embedded projects, e.g. by images created via
http://www.openembedded.org. But mainline X.org server, e.g.
what is in Debian unstable (7.1.0), doesn't support tslib.
Also I don't know if X/tslib allows re-calibration on-the-fly,
but I guess it does. However, tslib usually does not work via
the input subsystem (/dev/input/eventX is just one of them),
most devices use proprietary kernel interfaces.
Qt/Embedded for Qt 2 and Qt 3 doesn't handle tslib
out-of-the-box, (heck, the don't even know
about /dev/input/eventX), but patches exist.
But I think we can stop this thread now :-)
On Fri, 2006-11-17 at 15:53 +0100, Holger Schurig wrote:
> > I believe tslib handles this.
>
> The special X server "KDrive" supports tslib, this is used in
> many embedded projects, e.g. by images created via
> http://www.openembedded.org. But mainline X.org server, e.g.
> what is in Debian unstable (7.1.0), doesn't support tslib.
Someone should add tslib support to the main xorg server then ;-). All
tslib supported devices will then just work...
> Also I don't know if X/tslib allows re-calibration on-the-fly,
> but I guess it does.
It does.
> However, tslib usually does not work via
> the input subsystem (/dev/input/eventX is just one of them),
> most devices use proprietary kernel interfaces.
tslib does work via the input subsystem for almost every 2.6 kernel
based device I can think of in OpenEmbedded and we made an active effort
to get into that position. The only proprietary interfaces are old 2.4
kernels.
> Qt/Embedded for Qt 2 and Qt 3 doesn't handle tslib
> out-of-the-box, (heck, the don't even know
> about /dev/input/eventX), but patches exist.
Qt/E 2/3 have a ton of other input issues beside this (e.e keymap
problems) so the lack of merged tslib support is only a minor one and as
you say, patches exist.
IMO, calibration in the kernel would be a backwards step (especially
when tslib can do more besides like filtering and hopefully in the
future rescaling).
Regards,
Richard