On Mon, 7 Jul 2008 00:41:43 +0000 Andres Salomon <[EMAIL PROTECTED]> 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. _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
