I recently posted about my Elecom thumb trackball and how to set it up in Ubuntu to auto-configure whenever it is plugged in. Since then I’ve learned a few new things.

The mouse would occasionally stutter, by which I mean briefly stop moving (while I was moving the ball), or jump a few pixels, or across the screen. Not often enough to be completely unusable, but enough to be frustrating.

Since the Logitech mouse never did this, I thought it was a problem with the Elecom mouse itself. But it might also be a software issue. So I explored that and learned a couple of new things.

First: both libinput and synaptics were installed and conflicting with each other. This computer was a desktop not having a touchpad, so I removed synaptics and installed libinput:

sudo apt install xserver-xorg-input-libinput
sudo apt purge xserver-xorg-input-synaptics

NOTE: on my laptop, synaptics was called xserver-xorg-input-synaptics-hwe-16.04.

NOTE: I was not able to install xserver-xorg-input-libinput on my Ubuntu 16 laptop. Apparently it has a version conflict:

The following packages have unmet dependencies:
xserver-xorg-input-libinput : Depends: xorg-input-abi-22
Depends: xserver-xorg-core (>= 2:1.17.99.902)

If I check the versions, this message seems to be true:

ii xserver-xorg-core-hwe-16.04 2:1.19.6-1ubuntu4.1~16.04.2 amd64 Xorg X server - core server

This helped: the mouse still occasionally stuttered, but less frequently. So I looked for other possible software conflicts.

I noticed that using xset with different values, like this which should really slow down the mouse:

xset m 1/64 100

sometimes had an effect, sometimes did not. This suggested that evdev and libinput were both trying to control the mouse.

Since I was setting my mouse with xinput, I disabled xset. I considered the opposite, but the Elecom trackball has very high DPI (750 or 1500) and I couldn’t get xset to turn down the mouse sensitivity. Yet xinput does this nicely. Disabling xset is a simple command:

xset m 0 0

You can check what xset is doing with the mouse using the command:

xset q

Look for the section called “Pointer Control”. If acceleration and threshold are both 0, it’s disabled.

Now things got a bit more complex because I discovered every time the mouse is unplugged and replugged, xset starts up again. So I added this xset command to the script that udev fires when the mouse is plugged in.

Next, I found that I needed to ensure libinput controlled the mouse instead of evdev. In directory /usr/share/X11/xorg.conf.d I saw config files for both evdev and libinput. One thing that helped was to rename 90-libinput.conf to 05-libinput.conf so it is read first, before anything else.

Finally, to slow the mouse down I used different libinput settings. I had been using the Coordinate Transform Matrix property with values less than 1.0. This works OK, but causes a problem in some Steam games where the mouse is completely unusable. Setting this property to the identity matrix (its default value) eliminates that problem. This suggested to me that this feature might have a bug. So I use the Accel Speed property instead, setting it to negative values to slow down the mouse. This seems to be smoother and more reliable.

Another point: on my laptop, I disabled horizontal 2-finger scrolling. To my surprise, this was causing the mouse to occasionally jump across the screen when I clicked a button. I have no idea why these settings were related, but they were.

Problem solved: no more mouse stutter!