I have a newly-purchased ASUS 1015E-DS2 which came pre-loaded with Ubuntu, and the touchpad response is so bad to make the machine unusable without an external mouse. During small motions it randomly accelerates and decelerates, especially while moving across interface elements that trigger a momentary spike in cpu load. Actually at first I thought it was some broken attempt at a "snap-to-control" feature.

I plan to replace the OS with another dist, but before doing anything with it, I want to determine if the problem is fixable, because otherwise I plan to return the machine for a refund.

Turning off mouse acceleration entirely makes the problem much less severe, but doesn't entirely eliminate it, and is a usability problem in itself.

4 Answers 4


I tried playing with acceleration settings quite a bit, thinking they were the problem - the observed effect was as if mickeys were being inconsistently timed or combined into single events whereby the acceleration layer wrongly interpreted them as rapid motion subject to acceleration. I had mixed results getting semi-usable behavior, but this turned out to be the wrong direction to approach the problem from.

Two properties ended up being key to making the touchpad usable: Synaptics Noise Cancellation and and Synaptics Finger.

With the deault noise cancellation level of 13, holding a finger still on the touchpad resulted in minor "pointer brownian motion"; turning the level down to 0 (as an experiment) made this effect extreme. Increasing it to 20, on the other hand, basically eliminated the effect. It also eliminated the random acceleration and deceleration during movement, which seems to have resulted from the noise component getting combined with actual motion such that the resulting velocity was sufficiently greater or less than that of the actual motion that it affected acceleration.

The other option, "finger", was set by default to 1 for both the low and high threshold values. This worked fine on other touchpads I've used (perhaps it's ignored by them), but it seems to have caused even the slightest touch to be interpreted as a touch/motion, and caused things like releasing after precise positioning, tapping, and pressing the integrated buttons all to result in pointer movement (sometimes extreme jumps). Using thresholds of 40 and 50, which I'd found searching the web for solutions, resulted in a completely non-responsive touchpad. Values of 10 and 20 seem to be working well, and further improved the original jumpiness problem too.

The current (relevant) options I'm using:

Section "InputClass"
    Identifier "touchpad tweaked catchall"
    MatchIsTouched "on"
    Option "HorizHysteresis" "20"
    Option "VertHysteresis" "20"
    Option "FingerLow" "10"
    Option "FingerHigh" "20"

I'm posting this in the hopes that it helps others who are having touchpad jumpiness problems with this model or other laptops; other information I found in the process of searching for a solution seemed unhelpful and didn't explain what worked or how it affected symptoms.

Note that the options above are in xorg.conf form, whereas the "properties" earlier in this answer have somewhat different names. This seems to be some sort of xorg insanity that I don't really want to know about. Basically the property names are used if you use the xinput utility to tweak the options at runtime, and the xorg.conf option names are used if you're putting the settings in your xorg.conf or xorg.conf.d directory.


Some people have reported a grounding issue with the power supply. (If unplugging the power cable doesn't help, then it's not this.)

Source: Laptop touchpad response badly when on power supply?
Source: https://www.reddit.com/r/pcmasterrace/comments/19cwtjq/track_pad_tracks_horrendously_only_when_plugged_in/

Others have reported this solution:

echo N > /sys/module/drm_kms_helper/parameters/poll

Source: https://superuser.com/a/554343/52910

And others identified a problem with too many interrupts, solved by:

# Find the problematic interrupt (with the highest number)
grep enabled /sys/firmware/acpi/interrupts/*

# Disable that one (replace XX below)
echo "disable" > /sys/firmware/acpi/interrupts/gpeXX

Source: https://web.archive.org/web/20150418015419/http://carlocapocasa.com/crushing-the-kworker-uprising-or-how-to-fix-your-linux-lenovo-ideapad-y560p/


Eventually after having to take apart the machine for other reasons, I found that the touchpad seemed to work considerably better after disconnecting and reconnecting its ribbon connector, though still not as well as higher-quality models. The laptop is now dead, so I can't do any further investigation, but it seems likely that electrical/signal problems related to poor connection might contribute to this type of issue, and I'm posting this as an answer in case it's useful to anyone else.


For me, the problem comes out because I want to replace driver from synaptics with libinput. So I reinstall synaptics the pointer becomes stable again.

 sudo apt install xserver-xorg-input-synaptics

If you insist to use libinput like me, I created a folder and file in


Maybe you can copy from somewhere like /usr/share/X11/xorg.conf.d/90-libinput.conf

and edit the .conf file, change driver to libinput, e.g.

Section "InputClass"
        Identifier "touchpad catchall"
        Driver "libinput"
        MatchIsTouchpad "on"
        Option "Tapping" "on"
        Option "ClickMethod" "clickfinger"
        Option "NaturalScrolling" "true"
        #Option "TappingButtonMap" "1mr"    
        # his option is recommend on all Linux systems using evdev, but cannot be
        # enabled by default. See the following link for details:
        # http://who-t.blogspot.com/2010/11/how-to-ignore-configuration-errors.html
      MatchDevicePath "/dev/input/event*"

You must log in to answer this question.

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