[PATCH] touchscreen-meddling.patch

andrzej zaborowski balrogg at gmail.com
Thu Jun 19 01:59:55 CEST 2008

2008/6/18 Andy Green <andy at openmoko.com>:
> Touchscreen on GTA01-02 experiences noise on the channel that serves the
> "tall axis" of the LCM.  The sample quality of the other axis is good.
> The bad samples have a characteristic of one shot excursions that can
> reach +/- 20% or more of the sample average.
> Previously, we had a simple averaging scheme going in the touchscreen
> driver that summed up 32 x and ys and then divided it by 32.  This patch
> first tidies up the existing code for style, then adds a new "running
> average" concept with a FIFO.  The running average is separate from the
> summing average mentioned above, and is accurate for the last n samples
> sample-by-sample, where n is set by 1 << excursion_filter_len_bits in the
> machine / platform stuff.
> The heuristic the patch implements for the filtering is to accept all
> samples, but tag the *previous* sample with a flag if it differed from
> the running average by more than reject_threshold_vs_avg in either
> axis.  The next sample time, a beauty contest is held if the flag was
> set to decide if we think the previous sample was a one-shot excursion
> (detected by the new sample being closer to the average than to the
> flagged previous sample), or if we believe we are moving (detected by
> the new sample being closer to the flagged previous sample than the
> average.  In the case that we believe the previous sample was an
> excursion, we simply overwrite it with the new data and adjust the
> summing average to use the new data instead of the excursion data.

Like this http://svn.berlios.de/viewcvs/tslib/trunk/tslib/plugins/variance.c?rev=34&view=markup

This is really not a coding issue, it's a configuration issue in our
tslib config.  You can try to hack it into the kernel obviously (like
e.g. Nokia), duplicating existing solutions, and you'll get frowned
upon when trying to upstream (like e.g. Nokia).  If it must be in the
kernel then it should be at evdev level, not at s3c24xx_adc level, but
it seems like *precisely* what tslib is for and you even get a
lightweight plugins support.

More information about the openmoko-kernel mailing list