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...<br><br>The init of the psmouse module<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
 > triggers a calibration.<br>
<br>
</div>that's certainly true, but i think it happens pretty early -- the<br>
kernel is initialized by the time the dots start circling the XO<br>
guy.  and we don't really have any control over it.<br>
<div><br></div></blockquote><div><br>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.<br>Then in 7.5 Section "6) Sensor calibration execution command" it says to "When Power-up is done, do the self adjustment..."<br>
<br>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...<br>
<br><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
</div> why do you think<br>
that the when the pad emits streams of packets on its own, which don't<br>
represent any real motion, that it's not a bug?<br>
<div><br></div></blockquote><div><br>I believe it is noise, which is easily filtered out either at the driver level, or with "xset m" threshold.<br>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. <br>
<br>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.<br>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.<br>
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.<br>
Just tested now, and yes, with spew recalib on (a spew_delay of 1), and interference removed, I quickly gain accurate and correct control.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>
<br>

</div>i think you may not be aware of the long history of issues with this<br>
touchpad.  fixing the pad's errant behavior in the lab, or in a climate<br>
controlled home, is easy.  the touchpads don't misbehave in those<br>
conditions, much.  but in the uncontrolled environment of a classroom<br>
in the developing world, all bets are off.  kids have dirty hands, or<br>
lick their fingers, or work in a dusty (chalk dust?) environment, or<br>
often tend to have two hands close to the touchpad at once, or, or, or...<br>
the list goes on.<br>
<br></blockquote><div><br>Looking at the spec sheet again, I noticed its operating conditions go to 95% non-condensing humidity, and operating temperatures upto 50degreesC.<br><br>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.<br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
i'm all for having a deployment that's having touchpad troubles try<br>
simply turning off jumpyness recalibration -- i'd love to be proven<br>
wrong -- but i don't think it will work well.<br>
<div><br></div></blockquote><div><br>I refer to my earlier testing with the key. Note, at this point in time my housemate has offered me some yoghurt...<br><br>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.<br>
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)<br><br>I think this is enough experimenting for now, and a field test would be great... :)<br>
jumpy_delay of 0, spew_delay of 1.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
</div>it's certainly nice having someone else looking at the problem(s) with<br>
a fresh perspective.  thank you.  (and don't let my negative response<br>
deter you -- you might well be on to something -- who knows?)<br>
<div><div></div><div><br></div></div></blockquote><div><br>Yes its important to critique in the hope of getting to the bottom of this and deciding what is the best solution.<br><br><br><br>James.<br> </div></div><br>