> First, the synthetic button goes off at random without any tapping
> (not enough debouncing?).
I've found the up/down reporting on the pad pretty reliable. There
doesn't seem to be bounce as such, but during movement the pad does
report occasional bogus up events which the driver filters out with
the bounce timer.
It is possible that the driver is still getting out-of-sync with the
hardware, but unlikely since I've put in a resync mechanism, and anyway
you say movement is OK. Is it possible you have some other process
trying to read the pad device at the same time?
> Second, no matter what kind of tap I use, I can't seem
> to induce a click reliably.
Try running ``paddump /dev/pc110pad 1'' and tap the pad. You should see
the end two columns changing in sync with your touches. If that looks
OK, try ``paddump /dev/pc110pad 2'' which dumps all the internal timing
to do with tap gestures and may prove useful in learning how long a tap
is needed. Use the ioctl() or modify the default_params struct if the
timing values I picked don't suit you or your pad.
> Third, the real buttons don't seem to have
> any effect, even if I remove the -g1 flag.
> ...
> What I'd like for now is just to get the real buttons to work, the
> synthetic buttons can wait.
As I said above, the pad driver doesn't know about the real buttons, so
I think you need to figure out what's independently wrong with gpm.
> I'm using gpm 1.1 (from Slackware 3.1 but RedHat 4.1 has the identical
> gpm binary). Kernel is 2.0.27.
My gpm -V reports
gpm-Linux 1.10, July 1996
Robin.