[PATCH] touchscreen-meddling.patch

[Carl-Daniel Hailfinger]

On 18.06.2008 16:51, Andy Green wrote:
> 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.
>   

Clever, but it will spoil your average if there are two subsequent bad
samples. From your description, it will even fail if the two subsequent
ba samples deviate in opposite directions.

> I only tested this by eyeballing the output of ts_print_raw, but it
> seemed to be quite a bit better.  Gross movement appeared to be
> tracked fine too.  If folks want to try different heuristics on top
> of this patch, be my guest; either way feedback on what it looks like
> with a graphical app would be good.
>   

Unfortunately, I won't have time in the next 3 weeks to code up my
suggestion, but I think my suggestion of a 5-value median at 5 times the
rate or a 5-value running median at the normal rate should handle two
subsequent erratic samples a lot better. The only disadvantage of my
method is a 2-sample delay for movements (to be honest, for any
"natural" movement the delay is more like 1 sample). AFAICS the
computational cost should be even less than the averaging method because
my methods do not need division which is quite costly on some processors.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/