Re: Re: [Opie] Fwd: Unstable pointing?
"Matt Reimer" <[email protected]>
| Newsgroups | gmane.linux.ports.h2200,gmane.comp.handhelds.opie |
|---|---|
| Message-ID | <[email protected]> |
On 6/19/06, Paul Sokolovsky <[email protected]> wrote: > Hello Vladimir, > > Monday, June 19, 2006, 1:50:38 PM, you wrote: > > > Hi, > > > I've seen the same thing on my h2200. Sometimes pointer jumps to the top of > > the screen. It makes handwriting recognition unusable. Sometimes when I'm > > pressing a button in the GUI opie ignores it and I need to press twice. > > > Strange, but in GPE touchscreen works quite better. I've thought that GPE > > and OPIE uses the same tslib, don't they ? > > > And even in GPE there is some jitter with touchscreen: when I drag scrollbar > > and stop to move my stylus scrollbar positions still oscillates around > > stylus. There is no such effect in WinCE. > > Yes, those are all effects of drivers written not up to specs. On > the example of h4000_ts evolution (tracking h1910_ts): > > 1. Once it just read the first sample from ADC after interrupt - > diplsaying all those horrible "linearity" problems. > 2. Then it was brought a little to specs: there're few samples taken > each time (on initial pen IRQ or on subequent timter IRQs). First N > are thrown away (N=1 apparently works good enough). The rest are > bounded - i.e., all samples are checked to be close (within 8 units, > IIRC), and if not, thrown away as not stabel reading. Well, outcome of > this all machinery unfortunately is one random sample (like, first, > or something) taken as reading. Result - that cursor jitter which is being > described. > 3. But just adhering to recommended algorithm - averaging few readings > from the step above (I tried with 3) gave me a rock-solid cursor, not > worse than in wince. (The caveat is that sometimes sursor stopped > tracking on quick moves - so, all parameters needs to be tries and > adjusted first). > > Ok, looking in h2200's driver, samcop_ts.c - it just that naive as > to take first ADC reading. Of course, SAMCOP might be doing some > dejittering on its own, but I'd rather not trust that and use > techniques as described above. Thanks for the advice Paul. It's too bad tslib's dejittering doesn't take care of this, so we wouldn't have to duplicate this kind of code in every kernel ts driver. Matt