Update: This issue is largely resolved nowadays because modern desktop environments include configuration tools for libinput and its acceleration profiles.
If you have a recent Debian testing release, you might have noticed that your mouse now behaves very differently. For me, I noticed it when my aiming turned wobbly in Quake. Quake has extremely tight controls and shouldn’t feel as if you’re playing a 2016 console FPS with jelly dildos in place of fingers. So I was a bit surprised when it suddenly did. Also, I couldn’t reliably hit e.g. a close button on a window.
GUI tools to set up my mouse were no use, all settings, at least from the XFCE interface, are now ignored.
The reason appears to be a switch to libinput, specifically the libinput driver in X.org. The developers claimed that users probably won’t notice any difference between the new acceleration algorithm and the old one, but hell, do I notice a difference. Other gamers have commented as well, and the Arch Linux wiki has a section on it.
I used to be very happy with how mice work in X, I liked it even better than on Windows or OS X. At least this person seems to agree acceleration in OS X is broken. But with this new force-enabled acceleration from libinput I get motion sickness from FPS games, never mind not being able to hit anything.
Let’s see how we might fix this. At least two ways:
Method 1: Keep libinput, configure acceleration profile
You can keep libinput but set the acceleration profile to flat, like so in your xorg.conf:
Section "InputClass" Identifier "Logitech USB-PS/2 Optical Mouse" Driver "libinput" MatchIsPointer "yes" Option "AccelProfile" "flat" Option "AccelSpeed" "1" EndSection
Or this variation, depeds a bit on the version of libinput and X:
Section "InputClass" Identifier "Logitech USB-PS/2 Optical Mouse" MatchIsPointer "yes" Driver "libinput" Option "AccelProfile" "-1" Option "AccelScheme" "none" Option "AccelSpeed" "-0.5" EndSection
For me this was perfect for gaming, but not usable for office work. I kept overshooting and undershooting. Even tweaking the speed (from -1.0 to 1.0) didn’t really help much, I could never find a comfortable one. If you want to try anyway, it’s done like so, on the fly and without restarting X:
xinput --set-prop 'Logitech USB-PS/2 Optical Mouse' 'libinput Accel Speed' 0.35
Of course you substitute the right device identifier, you can find it with
xinput --list. They say that speed and acceleration are intertwined in libinput, so you may not be able to find any setting that works for both work and gaming as long as any form of acceleration scheme or profile is set.
Background on libinput and X.org
Some Accel options are for general input devices and handled by the device-independent layer in X.org, some other options are driver-specific and handled e.g. by the libinput driver, the synaptics driver, etc.
It seems that AccelProfile and AccelSpeed are libinput options. But AccelerationProfile and AccelerationScheme are libinput options. What libinput calls a profile is not the same as what X.org calls a profile. Neither are the options simply passed on down to the next layer.
AccelProfile on the libinput layer accepts the options “adaptive” and “flat”. But the manpage warns that “Not all devices support this option or all profiles”.
AccelerationProfile seems to be on the X.org layer and accepts 9 different profiles at this time. From the manpage:
0 classic (mostly compatible) -1 none (only constant deceleration is applied) 1 device-dependent 2 polynomial (polynomial function) 3 smooth linear (soft knee, then linear) 4 simple (normal when slow, otherwise accelerated) 5 power (power function) 6 linear (more speed, more acceleration) 7 limited (like linear, but maxes out at threshold)
Confused yet? They are explained here. What I’m not sure I understand is whether if both the libinput driver and the X.org layer apply an acceleration algorithm, are we getting two competing accelerations on the same pointer? That would make it very obvious to me why I feel like I’m wearing boxing gloves using my mouse with Debian’s default settings now.
Method 2: Remove libinput, revert to evdev
If none of this works for you, you can revert to the old way of driving your mouse by uninstalling the libinput driver:
apt-get remove xserver-xorg-input-libinput
This will remove a metapackage that normally pulls in all xorg-input drivers. That means that in future, you are responsible for hand-picking which drivers you need. No more just plugging in random Wacom tablets and expecting everything to work immediately, like it used to.
Not beautiful, but it does the job. I do hope the X.org devs go back to the drawing board about these mouse acceleration profiles. Gaming has only just begun to be an important thing for GNU/Linux, don’t mess it up, please 🙁 I’m happy to test any new code if the driver can be compiled out-of-tree.
Do you know of libinput profile settings that work well for gaming and office? Any great mouse acceleration stories to share?
Updates: Added subsections, tried to make tone a bit friendlier, probably didn’t succeed. More accurate bit on disabling acceleration completely. Second xorg.conf example for older libinput/X.
8 thoughts on “Did your mouse turn all weird in Debian and now you suck at Quake?”
Thanks for this. At least now I know what’s up. I just installed Debian testing on a new ThinkPad 13. Due to a kernel or hardware bug, the trackpoint can’t be configured via the kernel driver (e.g. ‘echo 150 > /sys/bus/serio/devices/serio1/sensitivity/’ and ‘echo 255 > /sys/bus/serio/devices/serio1/speed/’) and due to this libinput bug: https://bugzilla.redhat.com/show_bug.cgi?id=1200717 the trackpoint is still really slow even on max speed.
If I want to keep running Debian on this thing, there’s probably no way around getting rid of libinput, but if I ‘apt-get remove xserver-xorg-input-libinput’ then neither the trackpoint nor external mouse work.
How would I go about installing the drivers for those manually?
For me the TrackPoint works with evdev, no additional drivers required, I can even configure acceleration and sensitivity through the XFCE pointer GUI as usual. Maybe you were hit by the kernel bug that makes the TrackPoint devices only appear several minutes after boot? I can say that on 4.5.0-2-amd64, it worked fine with no configuration through xorg.conf. The Arch Linux wiki has some details about configuring, though: https://wiki.archlinux.org/index.php/TrackPoint
I posted commands for the solution in a separate reply below… I just want to say that current version of MX Linux (stand-alone distro based on Debian) uses Synaptics drivers instead of libinput. It offers much more options for my touchpad when compared to Manjaro for example, and enables me to fine-tune it much more to my tastes. I can finally play 1st person shooters again, like was possible in my older laptop (with much better touchpad)
Thx. I’m on Debian testing with 4.5.0-2-amd64 as well. I’ve heard from other Arch users that evdev works flawlessly for them. The problem for me is that Debian now comes with libinput and I can’t figure out how to switch to evdev. If I don’t figure it out, I’ll have to switch to Arch 🙂
Sorry, now I get that your not on arch – just using the great Arch wiki. Anyways, I installed Testing from one of the newest images and it comes with with libinput as default.
If I ‘apt-get remove xserver-xorg-input-libinput’ and restart X-session the trackpoint doesn’t work at all and it’s not seen by “xinput list”.
I just realized now that I should probably install ‘xserver-xorg-input-evdev’ after removing ‘xserver-xorg-input-libinput’ (unless ‘xserver-xorg-input-libinput’ is a layer on top and it’s already installed.)
Will test when I get home.
I can at least say that I have xserver-xorg-input-evdev installed and it works for me, so I’m cautiously optimistic it will work for you 🙂
I’m not sure where to give feedback to the libinput team on all this. I’m hearing tales of sorrow from many a gamer, so this isn’t just me, it would be nice to have the GUIs and default configurations updated in such a way that gaming feels good.
libinput’s palm detection proved useless for me. I use 2-finger scrolling, and the synaptics solution is simple: restrict the touchpad area using “synclient AreaLeftEdge=X AreaRightEdge=Y”. I didn’t have any luck mucking about with xinput, so I reverted back to original config. I have a hard time understanding how less configuration is better…
I have good news! I can play 1st person shooters on the touchpad once again!
I can finally use a product that I spent good money on! What a concept! LOL
I knew that something was off, but I couldn’t pinpoint what it was…
Took me almost 2 months of fiddling around with my new laptop but I eventually found linux commands to “fix” my touchpad and now I can play 1st person shooters on it again. There’s the xinput command but there’s also a less documented one out there, the synclient command (special fine tune settings for the synaptics driver)
With the synclient command, I was able to disable right-click when I have two fingers resting in the touchpad (example: you are running and aiming in game, and you try to press the fire button at the same time… it’s likely that your fire action will not be registered by the mousepad, it will recognize it as right-click instead)
And also reduced the “size” of the right-click button (it is a button-less touchpad, buttons are virtual, defined by software)
These were the commands, for anyone interested:
xinput set-prop 11 300 1, 1, 2
Also worthy of mention, I’m using MX Linux, which is a stand-alone distribution based on Debian that still uses the Synaptics driver (better!!) rather than the libinput driver. I found it to be the best linux distro at the moment when it comes to touchpad mouse movement.
Final observation: I still suck at Quake!! LOOOOOOL