#7341 HIGH 8.2.0 (: 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:  high       |   Milestone:  8.2.0 (was Update.2)
  Component:  kernel     |     Version:  olpc-3              
 Resolution:             |    Keywords:  olpc3-23:-          
Next_action:  never set  |    Verified:  0                   
  Blockedby:             |    Blocking:  7383                
-------------------------+--------------------------------------------------

Comment(by dilinger):

 Replying to [comment:3 dsaxena]:
 >
 > 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:
 >

 Keep in mind that these are hacks to work around flaky hardware; there's
 no way we're going to get this perfect.   The best we can hope for is
 'usable'.


 > 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.
 >

 The reason I made the threshold configurable  is because I wasn't sure
 that 60px was a good value.  Now, we're trying to balance buggy hardware
 behavior w/ what the user may actually do.  Yes, you can trigger the
 threshold thing with very drastic movements, but is that really how the
 user is going to be using the touchpad?  I expected more controlled, fluid
 movements.  Of course, the occassional huge jump is expected, which is why
 it requires two huge jumps in a row to trigger a recalibration.  However,
 that may not be sensitive enough, which is why I committed a change to the
 testing branch (iirc) to trigger a recalibration after just one huge jump.
 I was working w/ Richard at the time, and he was seeing jumpiness that
 just wasn't triggering with two jumps in a row.

 And yes, the 24ms thing would certainly affect this workaround.  A fixed
 EC is important; however, we've also got many machines out in the field w/
 older firmware versions that will probably never get upgraded, so the
 workarounds will need to deal properly w/ the 24ms thing (unless we can
 force users to upgrade their firmware).


 > 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.
 >

 Known issue, but again, I had to weigh expected use cases
 against buggy hardware.  Why would a user keep their finger resting on the
 touchpad for a long time?  If we could distinguish between that and the
 spewing bug, that'd be great; but I've been unable to.


 > 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.

 Unfortunately, the recalibration procedure itself is not ideal..


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


 Well, yes.  First we need to trigger hardware bugs that are, by
 definition, incredibly hard to trigger.  Then, we need to inspect the
 packet data and figure out ways to identify when the touchpad hw has
 screwed up.  You can approximate the touchpad spew bug by doing a 4
 -finger-salute while keeping a piece of tinfoil or rubber on the touchpad,
 and then removing it; 1 out of every 5 or 10 times, it will begin spewing
 packets.

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