#7341 NORM Never A: touchpad is a little off the rails in olpc3

[Zarro Boogs per Child]

#7341: touchpad is a little off the rails in olpc3
-------------------------+--------------------------------------------------
   Reporter:  dsd        |       Owner:  dilinger      
       Type:  defect     |      Status:  new           
   Priority:  normal     |   Milestone:  Never Assigned
  Component:  kernel     |     Version:  olpc-3        
 Resolution:             |    Keywords:  olpc3-23:-    
Next_action:  never set  |    Verified:  0             
  Blockedby:             |    Blocking:  7383          
-------------------------+--------------------------------------------------
Changes (by dsaxena):

 * cc: smithbone (added)


Comment:

 Spent some time watching packet logs while  I think we might be overly-
 calibrating the TP with the heuristics in the driver (possibly due to HW
 issues?). Two specific cases:

 1. If I move my finger around quickly, I often trigger the "delta too
 large" recalibration event, which is set to a default of 60. If I increase
 this to 120 (/sys/modules/psmouse/parameter/ignore_delta), I drastically
 decrease the number of times a recalibrate is issued (almost 5 minutes of
 constant rapid movement) and only seem to trigger it after very drastic
 movements. This might be related to only receiving packets every 24ms that
 smithbone is investigating as what are perfectly acceptable movements may
 appear erroneous to us due to missing data.

 2. The other scenario is around the following function in the driver:

 {{{
 /*
  * This is my favorite touchpad hardware bug.  I'm entirely not sure what
  * triggers it (I've seen it triggered while the laptop was left on
 overnight,
  * but my cat could have very well been using it/sleeping on it).
 However,
  * the touchpad will randomly get stuck in a state where it constantly
 spews
  * packets without a finger being on it.  A recalibration will fix it, but
  * without that it will go on for days (auto-recalibration doesn't catch
 it,
  * either).  The packets tend to either have the same coordinates, or be
  * 1px away from each other; ie, (283,139,6) -> (284,139,5) -> (285,139,5)
 ->
  * (286,139,6) -> (286,139,6) -> etc.  We have a number of workarounds
 here..
  */
 static void hgpk_spewing_hack(struct psmouse *psmouse, struct hgpk_packet
 *p)
 }}}

 I believe this recalibration is being falsely triggered in certain cases
 where my finger moves very slowly or rests in one place but i release the
 pressure so the Z value goes down. For example, in the following trace:

 {{{
 l=0 r=0 p=0 g=1 x=89 y=202 z=15 m=0
 l=0 r=0 p=0 g=1 x=87 y=206 z=15 m=0
 l=0 r=0 p=0 g=1 x=89 y=202 z=15 m=0
 l=0 r=0 p=0 g=1 x=89 y=202 z=15 m=0
 l=0 r=0 p=0 g=1 x=89 y=202 z=15 m=0
 l=0 r=0 p=0 g=1 x=89 y=202 z=15 m=0
 # ... [300+ samples of above] ...
 # lightly remove pressure
 p=0 g=1 x=89 y=202 z=13 m=0
 Recalibrating touchpad..
 }}}

 I removed finger pressure and tried to move but b/c of being the middle of
 recal, the behavior again goes a bit out of whack.

 The basic issue with both cases above is that trying to move the pointer
 in the middle of recal triggers another recal (etc, etc) and all our data
 during this time frame is essentially bogus AFAICT.

 If we can't differentiate between truly bogus data and bogus-looking but
 valid data, fixing this is going to be a painful exercise. :(

-- 
Ticket URL: <http://dev.laptop.org/ticket/7341#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system