Touchpad accel, spirals and xset

[James Zaki]

Sorry for the delayed response, I think I need to play around and compile a
kernel module and then use it on the xo-1. But to answer a few of the
questions...

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.
>
>
In the GS spec, 7.3.1 it mentions "sensor correction" being done
automatically at startup, and the sending of AA and 00 once complete.
Then in 7.5 Section "6) Sensor calibration execution command" it says to
"When Power-up is done, do the self adjustment..."

Once I'm able I will test a module without the
"INIT_DELAYED_WORK(&priv->recalib_wq, hgpk_recalib_work);" on driver init,
and rely on the spew recalibration to be its first calibration. A bit of an
experiment...



>  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?
>
>
I believe it is noise, which is easily filtered out either at the driver
level, or with "xset m" threshold.
At a guess I'd say it is auto-tuning of the cells to get rid of low
frequency noise, like a blob of dirt/water that maybe sitting in a corner of
the pad uninterrupted.

A little bit of testing (with recalibrations turned off) I find it
compensates well against the presence of a tiny key on the pad (big
interference, and fixed), ie can still correctly and accurately move around.
But the pad does not immediately compensate back once the interference (key)
is removed, instead it just wabbles around by 1 or 2 pixels (sound familiar
;)  Perhaps this is a cause of spew? In this state I found that tracking
could work ok, but tapping the pad produced a fixed jump in the curser
depending on where I tapped.
Sometimes it stopped sooner, other times not after a while. Note, this is
still with spew recalibration turned off. I suspect if I turned it on, a
moment away from the pad and I'd be back to accurate tracking and no deltas
if I tapped the pad.
Just tested now, and yes, with spew recalib on (a spew_delay of 1), and
interference removed, I quickly gain accurate and correct control.


> 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.
>
>
Looking at the spec sheet again, I noticed its operating conditions go to
95% non-condensing humidity, and operating temperatures upto 50degreesC.

But in essence the problems in the field, are just some form of interference
or another, and its what we decide the driver should do or what we should we
let the pad firmware do that is the question.


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.
>
>
I refer to my earlier testing with the key. Note, at this point in time my
housemate has offered me some yoghurt...

Interference as yoghurt (blob in the corner) seems to be harder for the pad
to compensate against than the key. Perhaps because it does not max out the
sensors as much not being metal. This is with spew_delay off again.
Turning the spew_delay back to 1 rapidly gives me correct control, and fixed
tapping with no delta. Even when removing the blob (smearing it across the
pad in the process)

I think this is enough experimenting for now, and a field test would be
great... :)
jumpy_delay of 0, spew_delay of 1.


> 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?)
>
>
Yes its important to critique in the hope of getting to the bottom of this
and deciding what is the best solution.



James.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20100126/27627106/attachment.html>