#9008 NORM 8.2.1: touchpad suddenly stops working (recalibration failed)

[Zarro Boogs per Child]

#9008: touchpad suddenly stops working (recalibration failed)
-------------------------------------+--------------------------------------
           Reporter:  HoboPrimate    |       Owner:  dsaxena      
               Type:  defect         |      Status:  new          
           Priority:  normal         |   Milestone:  8.2.1        
          Component:  kernel         |     Version:  not specified
         Resolution:                 |    Keywords:  cjbfor9.1.0  
        Next_action:  test in build  |    Verified:  0            
Deployment_affected:                 |   Blockedby:               
           Blocking:                 |  
-------------------------------------+--------------------------------------

Comment(by pgf):

 just realized i'm not sure anyone else knows how to test this.

 it's fairly easy to generate the "recalibration failed" error:  i do it by
 taking my finger and continuously doing quick sweeps, alternating from the
 two sides of the touchpad.  mix it up -- some short, some long, but the
 goal is to cause touchpad jumps (which means closely spaced large
 relocations of your finger with no contact on the pad) and lots of
 touchpad traffic (which involves contact with the pad).  the former (large
 displacements) force the recal, and the latter (traffic) interferes.  at
 least that's my theory.  you'll know when you get it, because the mouse
 will lock up, and you'll see the "recalibration failed!" message in the
 log.  you can recover by suspending/resuming the laptop.

 with the fix in, you'll still see the message, but the recalibration will
 be retried in 500msec, and should succeed the next time.  the driver
 currently retries forever, at half second intervals, if the recalibration
 keeps failing.  upstream has rejected the patch because of this, and would
 rather we re-init the ps2 subsystem after some number of failures.  i have
 it on my todo list to look at this, but my OLPC work isn't currently at
 the top of that list.  i don't know whether simply putting a limit on the
 number of retry attempts (5? 10?), which would be a much easier change,
 would be acceptable upstream.

 final note:  we have not looked at _why_ we're getting a failure from
 ps2_command() when it is called by hgpk_force_recalibrate(), nor exactly
 which of the 5 possible calls is failing.  there are already special cases
 in ps2_command() for some commands that can take a long time -- it's
 possible that one of the commands we're sending (which aren't #defined --
 grr) needs such an exception.  (i actually think that ps2_command() should
 get an additional "how long to wait for reply" parameter of some sort,
 which would usually specify a default value -- knowledge of per-command
 delay req'ts should be with the caller.)

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