Touchpad accel, spirals and xset

[Paul Fox]

james -- thanks for taking a fresh look at this.

james wrote:
 > Thanks Martin,
 > 
 > With some help from the people at #olpc-devel such as pgf, I was able to
 > look at where I needed to to test some theories.
 > 
 > Looking at the code in hgpk.c that runs on the xo-1 I'm testing on,
 > 
 > The first thing I suspect most people do while waiting for the gui to become
 > responsive is try to move the curser. The init of the psmouse module
 > triggers a calibration.

that's certainly true, but i think it happens pretty early -- the
kernel is initialized by the time the dots start circling the XO
guy.  and we don't really have any control over it.

 > 
 > Perhaps this is already clear to all but for completeness, calibrating the
 > capacitive display with a finger on the pad is a (the?) cause of
 > jumpyness/weirdness in control.

just "a" cause, i believe.  if it were the only cause, i think we'd
be having a lot fewer issues.  as you've observed, multiple digits
too close to the pad at once can cause jumpiness.  overreacting to
that by immediately recalibrating isn't the answer, though, for this
reason (i.e., the fingers may well still be there).

 > 
 > To prove, first turn off how the existing module triggers recalibrations (I
 > will explain the problem with one of them in a moment)
 > ---
 > cd /sys/module/psmouse/parameters
 > echo 0 > jumpy_delay; echo 0 >spew_delay
 > ---
 > 
 > Now give your xo a 5-finger-salut. The regular 4-finger-salut is
 > here<http://wiki.laptop.org/go/Recalibrating_Touchpad>but just before
 > hitting that final fn key, try rest a finger on the touchpad
 > (the nose squished a bit also works too). The bigger the touch, the greater
 > areas are miscalibrated.
 > (useful link1 <http://www.alps.com/e/csr/value/val_new.html>,
 > link2<http://www.cirque.com/technologies/glidepoint.aspx>
 > )
 > 
 > To regain control, just do the regular 4-finger-salut for recalibration.
 > 
 > Without a recalibration, the touchpad rests consistantly miscalibrated
 > (heightened sensitivity).

sure.

 > 
 > 
 > Spew
 > --------
 > 
 > I believe the spew_delay (originally 1ms) is our saviour.
 > 
 > >From hgpk.c...
 > /*
 >  * We have no idea why this particular hardware bug occurs.  The touchpad
 >  * will randomly start spewing packets without anything touching the
 >  * pad.  This wouldn't necessarily be bad, but it's indicative of a
 >  * severely miscalibrated pad; attempting to use the touchpad while it's
 >  * spewing means the cursor will jump all over the place, and act "drunk".
 >  *
 >  * The packets that are spewed tend to all have deltas between -2 and 2, and
 >  * the cursor will move around without really going very far.  It will
 >  * tend to end up in the same location; if we tally up the changes over
 >  * 100 packets, we end up w/ a final delta of close to 0.  This happens
 >  * pretty regularly when the touchpad is spewing, and is pretty hard to
 >  * manually trigger (at least for *my* fingers).  So, it makes a perfect
 >  * scheme for detecting spews.
 >  */
 > 
 > I've not read the spec (at a guess I'd say touchpad self tuning) but the
 > spew sounds perfect to trigger a recal! So probably not a bug, nor
 > miscalibrated pad, especially with such stable deltas.
 > --
 > echo 1 > spew_delay
 > 
 > After a moment of not touching, the recalibrate is triggered and the cursor
 > responds as expected.

i don't really understand what you're saying above.   why do you think
that the when the pad emits streams of packets on its own, which don't
represent any real motion, that it's not a bug?


 > 
 > Jumpyness recalibration
 > -----------------------------------
 > 
 > I believe that the recalibration after detecting jumpyness (x/y deltas >
 > discard_threshold) is causing more problems than its solves, since jumpyness
 > happens when fingers are on/near the touchpad.
 > 
 > One way to reproduce was with a finger in one corner tap the other corner
 > whilst lifting the first finger. Doing something like this a few times
 > (basically triggering the recalibrate by imperfect use) will cause the
 > calibration to occur whilst your fingers are there.
 > Another (more difficult) way was to have ones index finger touching
 > normally, but the adjacent middle finger parallel and close to the touch
 > surface. This also causes deltas greater than discard_threshold, and
 > triggeres touchpad-recalibration avec fingers.
 > 
 > It is probably that under ideal use with dodgy hardware, this would be a
 > good thing. But from what I have seen and read, I think the touchpad
 > firmware should not be assumed to need too many hacks.
 > 
 > So i'm not sure if spew or jumpyness came first, but with no jumpy_delay
 > (ie. bypass jumpyness recalibration) and default spew_delay of 1, I dont
 > have any "weirdness" with the touchpad.

i think you may not be aware of the long history of issues with this
touchpad.  fixing the pad's errant behavior in the lab, or in a climate
controlled home, is easy.  the touchpads don't misbehave in those
conditions, much.  but in the uncontrolled environment of a classroom
in the developing world, all bets are off.  kids have dirty hands, or
lick their fingers, or work in a dusty (chalk dust?) environment, or
often tend to have two hands close to the touchpad at once, or, or, or...
the list goes on.

i'm all for having a deployment that's having touchpad troubles try
simply turning off jumpyness recalibration -- i'd love to be proven
wrong -- but i don't think it will work well.

 > 
 > Tomorrow I'll take a look at the xset commands and such, but for now I hope
 > this helps.

it's certainly nice having someone else looking at the problem(s) with
a fresh perspective.  thank you.  (and don't let my negative response
deter you -- you might well be on to something -- who knows?)

paul
=---------------------
 paul fox, pgf at laptop.org