Totally bizarre: Mouse freezes over a section of mousepad; Arch only

Batou · 2017-12-18 00:51:06

Hi all,

After updating my system today, I've experienced numerous freezes of my mouse. After cleaning it and looking at it, I've narrowed the cause: it freezes/stops tracking when I position it over a specific section of my mousepad. I've had this mouse and the mousepad for well over a year and it has worked flawlessly under Arch. After I did a large update today, I've started experiencing these completely bizarre issues with my mouse. When I position it over this area of the mousepad, mouse freezes and cursor sometimes disappears. And buttons on the mouse don't work either. Only when I move it away does it start working again.

To check my sanity, I've booted Ubuntu and the mouse works flawlessly. No issues when moving over that particular section of the mousepad. I've also booted Windows 10 and it works flawlessly. Only when I boot Arch do I experience this bizarre behavior.

Since I have one of those gaming mice that you can tune the mousepad specifically for, I booted Windows and rescanned the surface. As a result of doing that, Win10 and Ubuntu work flawlessly as before, Arch still stutters.

What the heck could be happening? The mouse itself stores preferences etc in the eeprom so the OS should not even care about the mousepad surface. But somehow, something with Arch setup, does mess it up. How, I have no idea.

Anyone have any ideas, suggestions?

Linux batou 4.9.70-1-lts #1 SMP Sat Dec 16 17:59:37 CET 2017 x86_64 GNU/Linux

Last edited by Batou (2017-12-18 01:43:03)

seth · 2017-12-18 13:30:13

Try to swap libinput/evdev

Batou · 2017-12-18 15:09:30

Seth, thank you again!

OK, I've gone down to 1.8 of libinput. I didn't touch libevdev since it's from May so it's not an issue. Old libinput didn't help. Same stuff was still happening.

After looking through dmesg, I noticed this line:

[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/vgroup-root rw cryptdevice=/dev/sda4:vgroup:allow-discards nvidia-drm.modset=1 intel_iommu=off quiet  usbcore.autosuspend=-1

The culprit is usbcore.autosuspend=-1 which I added to solve my previous issue of not being able to mount USB3 drives. After I removed this and rebooted, my mouse worked perfectly again.

So weird. Something's seriously wrong with kernel's USB support. I'm not even sure where I should report this issue.

As to why the mouse stopped working over a certain area of the mousepad, I'm guessing it's sending more data when it passes over that area and somehow that messes up the USB module?! No idea.

Thanks so much again.

seth · 2017-12-18 15:32:57

evdev and libinput are "competing" (evdev being phased out) input drivers for X11, thus the idea to test (because libinput has known bugs to mess up the event order)

The mousepad could induce a massive event flood (the device cannot decide for a position and cause the mouse to judder) resulting in a lockup or bug in the drivers event compression) Since we probably cannot be sure the update caused this (but rather the autosuspend deactivation) I'd encourage to try using evdev as X11 input driver.

As for why the autosuspend could matter I can only imagine that the device frees internal memory or performs other resets when being suspended.
You can control the autosuspend interval for different devices individually, but for a quick test you could just set the value to something "big" (10000?) and see whether that leads to similar effects...

Batou · 2017-12-18 19:14:09

seth, what's the best way to switch libinput for evdev that won't cause any upgrade issues? I've been thinking about renaming 10-evdev.conf to 50-evdev.conf so it's loaded after 40-libinput. Not sure what the proper way of doing things is. Thanks for any guidance.

I'll try boosting the autosuspend to 10000 when I reboot (I have a long-running task right now and can't easily reboot)..

Last edited by Batou (2017-12-18 19:14:33)

seth · 2017-12-18 21:56:31

10-evdev should already trump 40-libinput (unless the latter has a more precise mtching), check your Xorg log on which driver is actually used atm.

Batou · 2017-12-18 23:49:49

seth,

grep -e "Using input driver " /var/log/Xorg.0.log
...
[    15.342] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[    15.361] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[    15.463] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
...

grep -e "evdev" /var/log/Xorg.0.log
...
[    15.342] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
...

and...

ls -l /usr/share/X11/xorg.conf.d
total 24K
-rw-r--r-- 1 root root   64 Jan  4  2017 00-avoid-glamor.conf
-rw-r--r-- 1 root root 1.1K Jan 18  2017 10-evdev.conf
-rw-r--r-- 1 root root  945 Sep 15 14:31 40-libinput.conf
-rw-r--r-- 1 root root 1.4K Oct 12 16:01 10-quirks.conf
-rw-r--r-- 1 root root  323 Nov 24 21:33 10-nvidia-drm-outputclass.conf

So is evdev or libinput controlling my mouse? Heh. Thanks again!

progandy · 2017-12-19 00:28:20

That should be libinput. If you read the output in order it should be obvious.

grep -e "Applying InputClass" -e "Using input driver" /var/log/Xorg.0.log

I guess you could also try the output of xinput. libinput devices should have "libinput" in most of the property names:

xinput # find <ID>
xinput list-props <ID>

Batou · 2017-12-19 03:40:52

Thanks progandy!

grep -e "Applying InputClass" -e "Using input driver" /var/log/Xorg.0.log

[    15.342] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
[    15.342] (**) Logitech USB Receiver: Applying InputClass "libinput keyboard catchall"
[    15.342] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[    15.361] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "Natural Scrolling"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "libinput pointer catchall"
[    15.361] (**) Logitech USB Receiver: Applying InputClass "libinput keyboard catchall"
[    15.361] (II) Using input driver 'libinput' for 'Logitech USB Receiver'
[    15.463] (**) Logitech USB Receiver: Applying InputClass "evdev pointer catchall"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "evdev keyboard catchall"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "Natural Scrolling"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "libinput pointer catchall"
[    15.463] (**) Logitech USB Receiver: Applying InputClass "libinput keyboard catchall"
[    15.463] (II) Using input driver 'libinput' for 'Logitech USB Receiver'

It's definitely using libinput:

xinput list-props 8
Device 'Logitech USB Receiver':
	Device Enabled (152):	1
	Coordinate Transformation Matrix (154):	1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
	libinput Send Events Modes Available (271):	1, 0
	libinput Send Events Mode Enabled (272):	0, 0
	libinput Send Events Mode Enabled Default (273):	0, 0
	Device Node (274):	"/dev/input/event1"
	Device Product ID (275):	1133, 50489

So, anyone know what the right way to switch it to evdev is?

seth · 2017-12-19 08:40:21

Either move 10-evdev.conf to a higher value (99-evdev.conf) in usr/share or copy it to /etc/X11/xorg.conf (thought it was there anyway)

Arch Linux

#1 2017-12-18 00:51:06

Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#2 2017-12-18 13:30:13

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#3 2017-12-18 15:09:30

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#4 2017-12-18 15:32:57

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#5 2017-12-18 19:14:09

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#6 2017-12-18 21:56:31

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#7 2017-12-18 23:49:49

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#8 2017-12-19 00:28:20

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#9 2017-12-19 03:40:52

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

#10 2017-12-19 08:40:21

Re: Totally bizarre: Mouse freezes over a section of mousepad; Arch only

Board footer