#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, 7393          
-------------------------+--------------------------------------------------
Changes (by dsaxena):

  * blocking:  7383 => 7383, 7393


Comment:

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

 testing does indeed have your change to recal after only 1 large delta.
 I'll play around with this to see if I can impact behavior. Maybe make
 this into a tunable too?

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

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

 Note that I did reproduce this at times by just resting for a second at
 the end of a stroke in one direction.

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

 So we need to figure out what to do next. With 4 weeks until August, we
 need to either fix the issues or we need to see if moving the stable
 driver into the testing kernel will be a simpler solution for now.

 On my end, I will:

 1. Post something on devel to get more input from people on what behavior
 they are seeing with the TP.
 2. Build a 2.6.25 kernel with the old driver to play around with and see
 what the behavior is like there.

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