[SOLVED] Wireless mouse very choppy in XFCE

HuckleSmothered · 2014-09-10 01:52:55

I just bought a wireless mouse that doesn't work on my system. It is extremely choppy and unresponsive. Clicking a button pretty much freezes the mouse up entirely. Once I plug my USB wired mouse back in, that mouse works fine.

It's more interesting than that though. I originally just put the batteries in (they came with new batteries), and put the wireless receiver in a USB slot. It was choppy. So I rebooted. It worked fine ... until my XFCE desktop was fully loaded. The mouse cursor comes up a little before XFCE is fully up, and it was quite perfectly responsive in these few seconds.

So, I started up Xorg without XFCE. Mouse works fine. Go figure. Logged out, logged into XFCE, worked fine ... until I opened a browser. Then it became choppy. I have a 10mbps cable connection completely unused at the time of this test. I reboot again, go straight into XFCE, fine for two seconds, then choppy again. I've repeated this a couple times already now. Seems consistent. Something seems wrong with the system, not the mouse.

XFCE recognizes the mouse. Not sure it is "correct" though. The settings-manager shows two additional mice, MOSART Semi 2.4G Wireless Mouse, and SIGMACHIP USB Keyboard.

Any suggestions?

Onn wireless optical mouse
Model ONA14HO602

My computer:
Archlinux 64bit, fully updated
XFCE4
CPU: i7
RAM: 12 GBs
HD: 100+ GBs free disk space

Last edited by HuckleSmothered (2014-09-25 00:26:41)

brebs · 2014-09-10 08:32:35

Sounds like the usual USB autosuspend is worth disabling. Google it.

HuckleSmothered · 2014-09-10 23:26:21

I found some instructions to disable usb autosuspend by adding a conf file in /etc/modprobe.d. So I created usbautosuspend.conf and put the following in it:

options usbcore autosuspend=0

This did not do anything. Of course, I can't tell if it has disabled autosuspend or not. How do I verify?

Most of the usb autosuspend advice came related to settings with laptop-mode. I'm not on a laptop and don't have that package.

Since my last post, I have tried a few things that made the mouse work:

tried it on my friend's ubuntu desktop
tried it on a windows machine
went into my bios (which has mouse support)

Here's the attempts at things that did not help the mouse:

installed linux-lts
installed nvidia driver instead of nouveau video driver
installed lxde (I'm back on xfce now though)

Here's the only place (outside of my current modprobe.d/usbautosuspend.conf file that contains the word autosuspend

 :: ~ $ cat /proc/kallsyms |grep autosuspend
ffffffff813aab60 t autosuspend_delay_ms_show
ffffffff813aaf80 t autosuspend_delay_ms_store
ffffffff813adb40 t pm_runtime_autosuspend_expiration.part.2
ffffffff813adbd0 T pm_runtime_autosuspend_expiration
ffffffff813af5e0 t update_autosuspend
ffffffff813af640 T pm_runtime_set_autosuspend_delay
ffffffff813af6a0 T __pm_runtime_use_autosuspend
ffffffffa08bf050 t snd_usb_autosuspend	[snd_usb_audio]
ffffffffa004b040 t autosuspend_check	[usbcore]
ffffffffa004eb40 t autosuspend_show	[usbcore]
ffffffffa004f140 t supports_autosuspend_show	[usbcore]
ffffffffa004f850 t autosuspend_store	[usbcore]
ffffffffa004b4e0 t usb_autosuspend_device	[usbcore]
ffffffffa004a9b0 t usb_disable_autosuspend	[usbcore]
ffffffffa004a990 t usb_enable_autosuspend	[usbcore]

emeres · 2014-09-10 23:44:26

HuckleSmothered wrote:

I found some instructions to disable usb autosuspend by adding a conf file in /etc/modprobe.d. So I created usbautosuspend.conf and put the following in it:
options usbcore autosuspend=0
This did not do anything. Of course, I can't tell if it has disabled autosuspend or not. How do I verify?

Did you reboot after editing or manually reload the module? To see what parameter values the module is loaded with run:

systool -vm usbcore

Edit: I would blacklist the other modules that get loaded, or start with blacklisting/unloading all, then load them one by one and see which work.

lsmod > before_wl_mouse_attached
lsmod > after_wl_mouse_attached
diff before* after*
man modprobe

Last edited by emeres (2014-09-10 23:49:13)

HuckleSmothered · 2014-09-11 01:51:50

I did indeed reboot after the modprobe.d conf was added. I wasn't able to remove and insert the usbcore module manually because so much was dependent on it.

I did find another site that said autosuspend should be -1, not a positive integer. Apparently the number indicates how many seconds until it goes to suspend. And a -1 would be "never." However, I changed my module.d conf file to reflect a -1 instead of a 0. But it doesn't seem to have made a difference.

 :: ~ $ cat /sys/bus/usb/devices/usb*/power/autosuspend
0
0
0
0
 :: ~ $ cat /sys/bus/usb/devices/usb*/power/level      
auto
auto
auto
auto

Of course, I didn't check all this prior to even adding the module.d/usbautosuspend.conf file.

I suspect my module conf file is not doing anything. Here is the output of systool -vm usbcore (parameter section only):

  Parameters:
    authorized_default  = "-1"
    autosuspend         = "2"
    blinkenlights       = "N"
    initial_descriptor_timeout= "5000"
    nousb               = "N"
    old_scheme_first    = "N"
    usbfs_memory_mb     = "16"
    usbfs_snoop         = "N"
    use_both_schemes    = "Y"

autosuspend=2, this was the same after I reboot with my conf file stating autosuspend=0 and it says the same when autosuspend=-1 in my conf file.

In regards to blacklisting ... here's my results from diff before.txt after.txt:

65c65
< evdev                  21544  9 
---
> evdev                  21544  11

I assume I can't blacklist evdev since it's being used by 9 processes even before the wireless mouse is attached.

emeres · 2014-09-11 03:00:10

https://bbs.archlinux.org/viewtopic.php?pid=1454513
Skip the irrelevant part to when brebs suggests using udev. Write a rule for your hardware with appropriate autosuspend settings.

Edit: Relevant documentation and wiki page.

Last edited by emeres (2014-09-11 09:39:08)

ewaller · 2014-09-11 05:20:31

As an experiment, try writing a -1 to /sys/module/usbcore/parameters/autosuspend

# echo '-1' >  /sys/module/usbcore/parameters/autosuspend

If that does not work, then figure out which usbx file belongs to your mouse in /sys/bus/usb/devices. Then descend that tree to the power directory and play with the settings therein:

ewaller$@$odin ~ 1008 %ls -l /sys/bus/usb/devices 
total 0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.7/usb1/1-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 2-5 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5
lrwxrwxrwx 1 root root 0 Sep  9 10:51 2-5:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 2-5:1.1 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.1
lrwxrwxrwx 1 root root 0 Sep  9 10:51 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.0/usb3/3-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 4-0:1.0 -> ../../../devices/pci0000:00/0000:00:1a.1/usb4/4-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 5-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb5/5-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 6-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb6/6-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 7-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb7/7-0:1.0
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb1 -> ../../../devices/pci0000:00/0000:00:1a.7/usb1
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb2 -> ../../../devices/pci0000:00/0000:00:1d.7/usb2
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb3 -> ../../../devices/pci0000:00/0000:00:1a.0/usb3
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb4 -> ../../../devices/pci0000:00/0000:00:1a.1/usb4
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb5 -> ../../../devices/pci0000:00/0000:00:1d.0/usb5
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb6 -> ../../../devices/pci0000:00/0000:00:1d.1/usb6
lrwxrwxrwx 1 root root 0 Sep  9 10:51 usb7 -> ../../../devices/pci0000:00/0000:00:1d.2/usb7
ewaller$@$odin ~ 1009 %ls -l /sys/bus/usb/devices/usb2/power/
total 0
-r--r--r-- 1 root root 4096 Sep 10 22:09 active_duration
-rw-r--r-- 1 root root 4096 Sep 10 22:09 async
-rw-r--r-- 1 root root 4096 Sep 10 22:09 autosuspend
-rw-r--r-- 1 root root 4096 Sep  9 10:51 autosuspend_delay_ms
-r--r--r-- 1 root root 4096 Sep 10 22:09 connected_duration
-rw-r--r-- 1 root root 4096 Sep  9 10:51 control
-rw-r--r-- 1 root root 4096 Sep 10 22:09 level
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_active_kids
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_active_time
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_enabled
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_status
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_suspended_time
-r--r--r-- 1 root root 4096 Sep 10 22:09 runtime_usage
-rw-r--r-- 1 root root 4096 Sep 10 22:09 wakeup
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_abort_count
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_active
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_active_count
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_count
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_expire_count
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_last_time_ms
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_max_time_ms
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_prevent_sleep_time_ms
-r--r--r-- 1 root root 4096 Sep 10 22:09 wakeup_total_time_ms
ewaller$@$odin ~ 1010 %cat /sys/bus/usb/devices/usb2/power/autosuspend 
2
ewaller$@$odin ~ 1011 %cat /sys/bus/usb/devices/usb2/power/autosuspend_delay_ms 
2000
ewaller$@$odin ~ 1012 %

Edit: Maybe try -1 for the autosuspend, or negative or large values for the autosuspend_delay_ms

Last edited by ewaller (2014-09-11 05:22:19)

HuckleSmothered · 2014-09-12 00:30:30

Before writing udev rules for autosuspend settings, I thought I'd play with them a little more. Specifically the -1 and the larger, positive numbers. I've tried -1, 0, 30, 40, 400, 4000 for /sys/bus/usb/devices/usb2/power/autosuspend but nothing seems to have any effect at all.

I also tried switching /sys/bus/usb/devices/usb2/power/autosuspend from auto to on. No love.

According to journalctl -xr, and unplugging the mouse and putting it back in, usb2 is the correct usb for the mouse.

I'm starting to think it's not actually autosuspend. It's interesting. While I'm moving, moving, moving the mouse and it's hardly responding, occassionally for a few brief seconds it will respond beautifully. It gives me glimpses of how wonderful a responsive mouse can be. But it is also like my high school girlfriend, just a tease.

emeres · 2014-09-12 02:18:58

Why do you attempt to suspend the whole bus? Go at least one level lower. Try udev rules, make sure they run. Or follow ewallers suggestion to modify the autosupend parameter of usbcore, then reattach the mouse. It should be loaded with that parameter and value, which you can check in the appropriate /sys/bus/structure.

HuckleSmothered · 2014-09-12 03:27:30

Not sure what is meant by suspending the whole bus. I'm fairly new to udev and the bus hierarchy. I figured the udev rule was to make permanent the testing that ewallers suggested. Is this not an accurate assumption?

I created a udev rule, 50-usb_power_save.rules

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="3938", ATTR{idProduct}=="1047", GOTO="power_usb_rules_end"
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"

The idVendor and idProduct were taken from usb-devices command.
Unplugged the mouse and put it in another usb slot, not working. Still as choppy as ever.

The /sys/bus/usb/devices/usb*/power/autosuspend shows as 0 for all. The limit files are all auto.
The /sys/module/usbcore/parameters/autosuspend shows as 2

emeres · 2014-09-12 03:35:26

What I meant is that this will probably not work, at least it failed to suspend in my case, which does not mean one cannot suspend* the whole bus, but I would go for specific ports, like /sys/bus/usb/devices/usb8/8-1/power/{control,autosuspend}. The whole structure is so recursively symlinked, that it is difficult to navigate.
Have you reloaded the udev rules?

# udevadm control --reload

Edit: I would go the other way around for that specific mouse:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="3938", ATTR{idProduct}=="1047", TEST=="power/control", ATTR{power/control}:="on"

You should be also able to change the control and autosuspend on the fly, once you locate where the mouse is in /sys/[...] .

*suspend/control

Edit: To make sure the rule gets executed you can add this to the rule:

, RUN+="/usr/bin/sh -c 'echo date >> /tmp/udev.log'"

Last edited by emeres (2014-09-12 03:48:23)

HuckleSmothered · 2014-09-12 23:53:50

Latest attempts have failed to fix the issue, the wireless mouse is still very choppy and mostly unresponsive.

Here's what I did:

Changed my udev rule to match that in the latest post by emeres (started it right off with appending the log method). Ran udevadm control --reload. Unplugged and replugged in my mouse. Verified that the udev rule ran (it did). Mouse is still crap.
Tried several different values in /sys/bus/usb/devices/usb2/2-1/power/{control,autosuspend}. Switching to "on" for control, and -1, 0, 40, and 400 for autosuspend. Tried different combos. Ran udevadm control --reload each change.

emeres · 2014-09-13 00:24:54

So it seems the issue is not related to usb power control. I found this searching for Mosart mouse:

modprobe -r usbhid

Try reloading the module with different mousepoll parameter values. Post vid and pid, maybe there some quirks for your hardware:

lsusb

HuckleSmothered · 2014-09-17 16:52:02

I thought we had it. After that simple module removal and plugging the mouse back in, it seemed to work. For a few minutes. Which is a heck of a lot longer than it would otherwise. But, unfortunately, the problem came back. But this got me excited that we were close to a solution. So I started playing with the polling values. Nothing here seemed to help. I increased it (reduced intervals) dramatically, but nothing changed.

Since I never really looked specifically for Mosart mouse (which I really should have before even my original post), I'm going to do some searching on that and see about the quirks. I'll report back with, hopefully, a solution.

HuckleSmothered · 2014-09-17 17:01:45

By the way, lsusb shows the mouse as 3938:1047
Interestingly enough, the description in lsusb is blank. Doesn't mention anything at all for manufacturer or product. Other mice show up, such as my Dell optical wheel mouse.

HuckleSmothered · 2014-09-17 23:36:15

Crap. So apparently I need to correct some of the bad info I gave originally. If it worked for a second or two, I considered it good. However, after using it for more than a few seconds I find that my mouse does /not/ work in XFCE, LXDE, startx w/ twm, NOR my bios. That bios part was where I was really counting on there being a fix in arch for this. But it does /not/ work in the bios. Apparently my bios recognizes this mouse as a keyboard. Not sure if that is the cause, or just coincidence.

The test that made me double check all of this was after trying this mouse on multiple other linux machines and it all working. And testing it for several minutes, not just a few seconds. So I made an Ubuntu live cd and booted the home pc with it (this is the only machine the mouse doesn't work on). Lo and behold, the mouse doesn't work. So I check the bios again, it doesn't work there either. No settings there to manually tell it what it is either.

Oh well. I guess I should stop trying to figure it out. It simply doesn't seem to be compatible with my bios. No setting in linux is going to fix that. I'm really sorry for wasting people's time.

emeres · 2014-09-18 00:52:31

Maybe there are options for legacy usb support on the machines in question bios. Try disabling them. I also made experience with a noname gamepad that blocks the whole system from booting after grub. It seems it is being recognized as a flash drive or some usb device that can be booted from, since turning that option off in bios "fixed it" if I recall correctly. Maybe I will double check next time I boot, should I remember it that is.

If you really consider this unsolvable, please mark the thread as such, otherwise people will read through all of this, only to read your last remarks.

HuckleSmothered · 2014-09-18 02:35:29

I played around in the BIOS. I do have legacy support on. So I turned it off and rebooted. No difference. Then I reset my BIOS (I had altered some fastboot options and boot options previously) and tried it with and without legacy support. No go.

Also, I checked the command lsusb -v|egrep "^Bus|MaxPower", this apparently gives me the max power draw for usb devices. This mouse is right 100mA, the same as the other devices which are 100 and 98mA.

Thank you very much for your help through this emeres. I came across another post or two when looking for answers for this and it seems you help out a lot with USB problems. Kudos. I'll be returning it later this week. Now I'm all paranoid about trying another wireless mouse though. Maybe I should go with something better quality than a $13 Walmart one.

HuckleSmothered · 2014-09-25 00:26:30

I'm switching this from UNSOLVED to SOLVED. I think I confirmed the problem. Tell me if I'm being too audacious in calling it a solution.

Mouse that has been the source of my woes: [Onn Wireless Blue LED Optical Mouse
New mouse bought today: Verbatim Wireless Multi-Trac Blue LED Optical Mouse

The new mouse is working perfectly. Been using it for about three hours now. No problems.

What's the difference? About $3. And a few buttons. The Onn mouse had a button right in between the two mouse buttons with a Microsoft logo. Something it was supposed to do in Windows 8. Whatever. It also had two buttons on the side of the mouse. I think those were intended to be to page up and down. Or forward and back while browsing. Not sure. That's it.

So, it wasn't an archlinux issue, not even a linux problem. Turned out to be a hardware problem. My motherboard just apparently didn't support that thing. New mouse works great.

Arch Linux

#1 2014-09-10 01:52:55

[SOLVED] Wireless mouse very choppy in XFCE

#2 2014-09-10 08:32:35

Re: [SOLVED] Wireless mouse very choppy in XFCE

#3 2014-09-10 23:26:21

Re: [SOLVED] Wireless mouse very choppy in XFCE

#4 2014-09-10 23:44:26

Re: [SOLVED] Wireless mouse very choppy in XFCE

#5 2014-09-11 01:51:50

Re: [SOLVED] Wireless mouse very choppy in XFCE

#6 2014-09-11 03:00:10

Re: [SOLVED] Wireless mouse very choppy in XFCE

#7 2014-09-11 05:20:31

Re: [SOLVED] Wireless mouse very choppy in XFCE

#8 2014-09-12 00:30:30

Re: [SOLVED] Wireless mouse very choppy in XFCE

#9 2014-09-12 02:18:58

Re: [SOLVED] Wireless mouse very choppy in XFCE

#10 2014-09-12 03:27:30

Re: [SOLVED] Wireless mouse very choppy in XFCE

#11 2014-09-12 03:35:26

Re: [SOLVED] Wireless mouse very choppy in XFCE

#12 2014-09-12 23:53:50

Re: [SOLVED] Wireless mouse very choppy in XFCE

#13 2014-09-13 00:24:54

Re: [SOLVED] Wireless mouse very choppy in XFCE

#14 2014-09-17 16:52:02

Re: [SOLVED] Wireless mouse very choppy in XFCE

#15 2014-09-17 17:01:45

Re: [SOLVED] Wireless mouse very choppy in XFCE

#16 2014-09-17 23:36:15

Re: [SOLVED] Wireless mouse very choppy in XFCE

#17 2014-09-18 00:52:31

Re: [SOLVED] Wireless mouse very choppy in XFCE

#18 2014-09-18 02:35:29

Re: [SOLVED] Wireless mouse very choppy in XFCE

#19 2014-09-25 00:26:30

Re: [SOLVED] Wireless mouse very choppy in XFCE

Board footer