Heads up on touchpad change

[Andres Salomon]

On Mon, 7 Jul 2008 00:41:43 +0000
Andres Salomon <dilinger at queued.net> wrote:
[...]

Clarifications were request, so..


> 
> Cc'ing devel for a wider audience.  Basically, we've got a new
> touchpad driver that uses mouse mode rather than advanced/stream
> mode.  This means the PT won't work, but the benefits are numerous:
> 
>  - lots of silly complexity ripped out of the driver
>  - smaller packet size means that deltas between packets are much much
> smaller
>  - smaller deltas means that it's much easier to detect jumpiness; i
> found it impossible to get >90px deltas using my fingers, but i saw
> 150px deltas when the touchpad was freaking out

This is one of the hardware bugs that we see; when cursor gets jumpy.
When one puts their finger down on the pad, the cursor will make a huge
jump across the screen.  This is now fairly easy to detect; we can't
stop it, but once we've detected it, we can trigger a recalibration.

>  - packets are only sent when a finger moves on the pad, rather than
> any time a finger is placed down.  this makes it easier to detect
> when the hardware starts spewing packets.  i've come up w/ a
> completely different heuristic for detecting this, based upon what
> i've noticed. i was unable to trigger any false-positives with this,
> so i'm much happier.

Packet spews are sometimes confused for jumpiness.  When the touchpad
starts spewing, remove your fingers from the pad and take a look at the
cursor; it will float around in a 1/2"x1/2" area.  If one attempts to
use the pad during this, you'll see jumpiness and the cursor will also
appear to be drunk.  Spews can go on for hours, even days before the
hardware fixes itself (or is reset).  Again, this is not something that
we can fix, but we can at least quickly detect it and trigger a
recalibration.

>  - no finger-up/finger-down packets, which is yet another hardware bug
> that we don't have to deal w/.
> 
> The recalibration stuff requires a 2s window of silence after
> occurrence, or it will keep trying to recalibrate until that is
> satisfied.  There's the potential for shortening this, but I haven't
> tested it yet.  Likewise, I also haven't tested the power toggling
> stuff yet; I was hoping to get feedback on the other stuff, first.
> Please test and report back!
> 

When a hardware bug is detected, a recalibration will be scheduled for
1s afterwards.  The recalibration will disable the touchpad and send
the recalibrate command to the hardware.  At this point, the cursor
will stop responding for 1/4 or 1/2 a second.  The hardware
recalibration will only work if one removes their fingers from the
touchpad (this is a limitation of the hardware).  Since there's no way
to know whether the calibration was successful or not, the best we can
do is to check for additional packets.  If we get packets within 2s of
recalibrating, we make the assumption that the calibration failed (due
to fingers being on the pad), and schedule a recalibration for 1s
later.  We keep doing this until the driver thinks that a calibration
has been successful.

What an end user will see:

They will be
using the touchpad (although that's not a requirement, and detection
should occur correctly regardless of whether the pad is actually in
use), and suddenly the cursor will start misbehaving.  After anywhere
from 5s to 60s or of it misbehaving (the worse it behaves, the quicker
the driver will catch it), the driver should trigger a recalibrate.  At
that point, the cursor will simply vary between unresponsive, and jumpy.
That will be the case until the user removes their hands from the pad
for 3s (either they've managed to finally click on what they wanted to
click on, and are typing something, or they've turned away from the
machine for a second, or they're just used to this occurring and they
know to wait). After the touchpad has been clear for 3s, the cursor
should go back to normal. Note that 3s is a cautious number; we can
potentially make this window smaller (possibly even 1s), provided the
recalib is safe.