This is indeed very annoying. I've tried to adjust things via xinput but with no luck, not all of the same options seem to be available as through the old Shared Memory config method.
There are a couple of posts about this issue on the forum but with no solution. I don't know whether the driver or something else would need to be changed but something like the following behaviour would be ideal: First scenario: Double/Triple Tap User taps (down and up within TapTimeout). ButtonDown happens immediately, but it waits TapDuration before sending ButtonUp. This gives the user time to tap again. If the user releases within TapTimeout, it sends another TapDuration tap, which again gives the user time to tap a third time. Second scenario: Tap and Drag User taps (down and up within TapTimeout). ButtonDown happens immediately, but it waits TapDuration before sending ButtonUp. This gives the user time to put his finger back on the touchpad, and if he doesn't lift it within TapTimeout, any movement from then on is treated as a drag. Depending on whether the DragLockTimeout, the drag ends immediately when the user lifts his finger, or after a delay. I guess the current situation is that the driver decides what the user is doing before executing any action (is he tapping, doubletapping, dragging), whereas what we're asking for is that the driver decides *while* the action is taking place. -- touchpad tap-to-click response delayed .5 seconds https://bugs.launchpad.net/bugs/449208 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
