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-X,
which is subscribed to xserver-xorg-input-synaptics in ubuntu.

_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-x-swat
Post to     : ubuntu-x-swat@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-x-swat
More help   : https://help.launchpad.net/ListHelp

Reply via email to