Did your mouse turn all weird in Debian and now you suck at Quake?

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 or the menu entry I wanted.

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 on it as well, and the Arch Linux wiki has a section on it. This cannot stay if Valve wants to sell Steam OS gaming machines to anyone. No one can do gaming on this kind of setup.

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 as well. 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.

6 thoughts on “Did your mouse turn all weird in Debian and now you suck at Quake?”

  1. 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?

    Like

    1. 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

      Like

  2. 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 🙂

    Like

    1. 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.

      Like

      1. 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.

        Like

  3. Thanks.

    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…

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s