jitterless touchscreen input in .34 [working proof of concept]
gb at bsdmn.com
Wed Oct 20 18:58:32 CEST 2010
I have tons of ideas how to improve kernel more. But I am very uncertain
_then_ i'll be able to spend any time on it. So, here is what i already
have, my patch to fix jitter without filtering. I think as everyone gone
to .34, it may be important now.
Main idea is to slow down glamo pixplock while doing adc conversions.
So, it works like this:
<get ts down interrupt>
<wait for vsync>
<slow down glamo pixclock>
<start ts adc>
<wait for full adc cycle>
<restore glamo pixclock>
it is not really simple. busy waiting for vsync if really too long (eats
cpu and so), so it were changed to waiting for hsync (i can't recall
details) and i didn't find way to understand if we 'close to vsync end'.
doing this without any waiting will procude small but noticeable visual
effects (1 white line per second). reducing averaging sample count also
required because overwise glamo will be slowed down for long time, which
increase probability of visible effects.
Expirements show that probability of getting wrong data is 10 or 100
times lower while glamo pixclock slowed down. I wrote proof of concept
patch. It works well here for few months. Result is not ideal, worse in
some aspects and better in other aspects than _filtering driver_ but
much better than with default .34 driver, i can say that event data is
fully usable for any kind of work after this change.
One who want to test it will need to manually apply patches, because i
had to extract code from my custom tree.
As you have no need to filter, it generates significantly less events
and doing less conversions, which should have positive influence on both
power consumption and performance. I works here for several months in my
I can't do proper locking, so it is more like working proof of concept,
it just sets pixclock to predefined portrait-mode value, that's why it
shows snow in landscape mode while rotated. I don't know how to do
proper allocation of 'glamo' struct.
More information about the openmoko-kernel