On my Lenovo T460p, I have a "delay way" before touch pad movement or scrolling is registered. Note: This delay way is not to be confused with inactive areas of the touchpad as configurable through synclient and used e.g. for clickpad features. This can more be compared to "dead zones" of joysticks, which only react after a certain amount of movement.

When I touch the pad and start moving my finger, at first, nothing happens. I have to move the finger for a few millimeters before the mouse pointer would respond. It then registers the movement completely, which means that whenever I start using the touch pad, I have a skip by tens of pixels in the pointer movement. This makes the touch pad unusable for any "precision" work, such as hitting the close button on a tab.

This also happens after I let the finger rest within a movement for a second or so. The same happens for two-finger scrolling. These are the xinput settings:

Device 'SynPS/2 Synaptics TouchPad':
    Device Enabled (139):   1
    Coordinate Transformation Matrix (141): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    Device Accel Profile (275): 1
    Device Accel Constant Deceleration (276):   2.500000
    Device Accel Adaptive Deceleration (277):   1.000000
    Device Accel Velocity Scaling (278):    12.500000
    Synaptics Edges (297):  1574, 5369, 1354, 4571
    Synaptics Finger (298): 25, 30, 0
    Synaptics Tap Time (299):   180
    Synaptics Tap Move (300):   254
    Synaptics Tap Durations (301):  180, 100, 100
    Synaptics ClickPad (302):   0
    Synaptics Middle Button Timeout (303):  75
    Synaptics Two-Finger Pressure (304):    282
    Synaptics Two-Finger Width (305):   7
    Synaptics Scrolling Distance (306): 115, 115
    Synaptics Edge Scrolling (307): 0, 0, 0
    Synaptics Two-Finger Scrolling (308):   1, 1
    Synaptics Move Speed (309): 1.000000, 1.750000, 0.034590, 0.000000
    Synaptics Off (310):    0
    Synaptics Locked Drags (311):   0
    Synaptics Locked Drags Timeout (312):   5000
    Synaptics Tap Action (313): 0, 0, 0, 0, 1, 3, 2
    Synaptics Click Action (314):   1, 3, 2
    Synaptics Circular Scrolling (315): 0
    Synaptics Circular Scrolling Distance (316):    0.100000
    Synaptics Circular Scrolling Trigger (317): 0
    Synaptics Circular Pad (318):   0
    Synaptics Palm Detection (319): 0
    Synaptics Palm Dimensions (320):    10, 200
    Synaptics Coasting Speed (321): 20.000000, 50.000000
    Synaptics Pressure Motion (322):    30, 160
    Synaptics Pressure Motion Factor (323): 1.000000, 1.000000
    Synaptics Grab Event Device (324):  0
    Synaptics Gestures (325):   1
    Synaptics Capabilities (326):   1, 0, 0, 1, 1, 1, 1
    Synaptics Pad Resolution (327): 65, 44
    Synaptics Area (328):   0, 0, 0, 0
    Synaptics Noise Cancellation (329): 28, 28
    Device Product ID (267):    2, 7
    Device Node (266):  "/dev/input/event1"

Has anyone a solution for this?

I have tried to set Noise Cancellation to 0, 0, but that did not help.

This is on Debian testing (stretch). Fedora 24 Workstation Live Image also shows the same issue.

2019-11-20: The problem still persists. Here is a screen capture of how the cursor behaves when I roll my finger up and down without pause on the touchpad (no "movement", just rolling the fingertip).

I am still on Debian testing (which is nowadays bullseye).

  • Wouldn't a dead zone be an area where no touch is registered? AFAIK you are talking about "palm detection" or such.
    – phk
    Jun 21, 2016 at 12:08
  • @phk Maybe dead zone isn’t the correct term, but Palm Detection I think isn’t either, as it is clearly turned off in xinput, nevertheless I’m seeing the effect. If anyone has a suggestion for a more correct term, feel free to edit. Jun 21, 2016 at 12:17
  • 1
    Please tell us if this happens only on Debian Stretch, or other linux distros as well, i.e. would this happen if a Linux Mint bootCD, and so forth...
    – agc
    Jun 30, 2016 at 0:39
  • @JonasWielicki Could you please check if my answer is helping? It would be a shame if the 250 reputation would be going to waste
    – Thawn
    Jul 5, 2016 at 7:22
  • I think the Synaptics driver could be better configured out of the box for these distros. We're experiencing the same issue with several Linux installs. See if this helps: superuser.com/questions/861829/touchpad-after-scroll-delay-fix
    – Meetai.com
    Mar 27, 2018 at 3:31

4 Answers 4


It is possible that in your particular case Synaptics Finger (298): 25, 30, 0 is set a bit too high.

I.e. for instant movement on any pressure (use something more sensible later):

xinput set-prop "SynPS/2 Synaptics TouchPad" "Synaptics Finger" 1 1 0

for your device SynPS/2 Synaptics TouchPad (get device name by: xinput list)


"FingerLow" "integer": When finger pressure drops below this value, the driver counts it as a release. Property: "Synaptics Finger"

"FingerHigh" "integer": When finger pressure goes above this value, the driver counts it as a touch. Property: "Synaptics Finger"

So the issue here could be "pressure" not pixel distance.

  • 1
    Interesting, but unfortunately I don’t think this changes the behaviour. I tried what you suggested, but the behaviour did not really change :(. Thanks for giving this a shot though! At first I thought it might’ve changed something, but reverting to the old values didn’t feel different; there is still considerable lag before the touchpad registers a 180° change of direction for example. Nov 20, 2019 at 9:32
  • Oh I really thought that was it. Are you sure Noise Cancelling is still 0 0 too? These are the 2 properties that give me lag here. FWIW here is my configuration: pastebin.com/wT55gWUf (don't expect it to be the same for your device though) Nov 20, 2019 at 14:06
  • I made a screen capture of how it looks (also edited that into the question): imgur.com/a/vdYXKAG This is just rolling my finger on the touchpad, no movement. I do not pause the rolling of my finger at all. Nov 20, 2019 at 16:57
  • Thanks for the screencap. This looks exactly like what a lowpass filter would do, but strangely in your case Noise Cancelling is disabled, as you wrote. You could try out my xinput config if you want (it should be reset after a restart) if that doesn't help at least a bit I think we can rule out a configuration issue. Nov 21, 2019 at 21:32
  • 1
    Woo, thanks for the config. I loaded it, but it didn’t fix the issue. The gaps became wider though, probably due to your increased pointer speed. Nov 22, 2019 at 13:59

I had the same issue in Ubuntu 18.04 LTS.

Installing this package seems to improve how the touchpad reacts a lot:

sudo apt-get install xserver-xorg-input-synaptics
  • Unfortunately, already installed. Jul 19, 2018 at 8:16
  • This one fixed it for me
    – Merc
    May 26, 2019 at 21:36

This could be caused by USB power management.

Try temporarily disabling USB power management and see if the problem disappears:

first use lsusb (part of the usbutils package) to identify the port that your touchpad uses:

Bus 002 Device 003: ID 18a5:0245 Verbatim, Ltd 
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In my case this would be the logitech unifying receiver on bus 001 Device 003. Now find the corresponding device in /sys/ using the vendor ID of your device (in my case the id is 046d):

grep 046d /sys/bus/usb/devices/*/idVendor

> /sys/bus/usb/devices/1-1.5/idVendor:046d

now tell the kernel to keep the device always on:

echo on >/sys/bus/usb/devices/1-1.5/power/control

if this helps, you can disable autosuspend in the laptop-mode tools. edit /etc/laptop-mode/conf.d/runtime-pm.conf and add AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="046d:c52b" where you replace 046d:c52b with the device id of your device given by lsusb. In my case I used the more general parameter that disables autosuspend for all human interface devices and storage devices: AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="usbhid usb-storage"

  • Nice idea, but unfortunately, this does not work. I could not find the matching USB device (I only have Acer (webcam), Intel corp. (wifi) and Validity Sensors, which I presume is the fingerprint reader, otherwise there are only root hubs). I nevertheless set power/control to on for all of them and also used powertop to disable PM for any other devices I could find. To no avail :(. Jul 5, 2016 at 7:22
  • Sorry to hear that.
    – Thawn
    Jul 5, 2016 at 7:24
  • Did you try to disable powermanagement through laptop-mode alltogether?
    – Thawn
    Jul 5, 2016 at 7:25
  • Also could you try lsmod and see if any of the modules fit your touchpad?
    – Thawn
    Jul 5, 2016 at 7:26
  • I just found out that there are two drivers available for your touchpad: xf86-input-synaptics and libinput. Could you try to find out which you are using and try to install the other one?
    – Thawn
    Jul 5, 2016 at 7:35

This is what improved responsiveness for two finger scrolling for me (ThinkPad T14 Gen1, Ubuntu 22.04):

Get xinput props for your touchpad:

$ xinput list-props "SynPS/2 Synaptics TouchPad"

Set scrolling pixel distance:

$ xinput set-prop "SynPS/2 Synaptics TouchPad" "libinput Scrolling Pixel Distance" 10

The new setting becomes effective immediately.

In my case it was set on 15 and lowering it to 10 significantly improved responsiveness of two finger scrolling. It turned out that values below 10 are not allowed. Could be a different value for your touchpad (I don't know), so you have to try.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .