Logitech Anywhere Mouse MX becomes unresponsive every few seconds on Jetson TK1.

I have a logitech Anywhere Mouse MX.
The mouse works fine in Windows or X86 linux, but on the Jetson it will cut out and won’t respond to movement for a few seconds until after I press a button on the mouse. This mouse uses the new unifying receiver.
http://www.logitech.com/en-us/support/anywhere-mouse-mx?osid=14&bit=64
It seems like this mouse maybe has a more aggressive low power mode that the Jetson isn’t handling correctly. Maybe on x86 it takes about 100ms to come out of lower power, but on the Jetson it takes multiple seconds.

I have this problem both on the old 19.2 release and the new 19.3 Tegra release.
The behavior is the same both on the USB 2 port and USB 3 port with USB 3.0 mode turned on.
Using a powered USB hub does not change the behavior.
I have tried disabling the USB autosuspend and it did not make any difference.
http://elinux.org/Jetson/Cameras#Disabling_USB_auto-suspend

I also have a Logitech MX1000 (older flash drive size wireless transceiver) and a Logitech G700.
Both of these mice work without any issues.

What is odd is that after leaving the system on to test the other 2 mice, after plugging the MX anywhere back in, it seems to work just fine. It is like one of the other 2 mice changes something in the USB state somehow.
After rebooting the machine the mouse goes back to not working correctly.

How should I go about troubleshooting this?
Is there a command I can use to check the USB state and all relevant status info with the different mice plugged in?

Looks like you’ve started looking in all the correct places. I tend to always be suspicious of wireless mice when something flakes out, and tend to wonder about the wireless unit itself…possibilities of low batteries, weak signal, or signal interference from other devices. Your particular mouse has a help page on erratic scrolling, but the situation is more specific and probably not related:
http://logitech-en-amr.custhelp.com/app/answers/detail/a_id/41666/section/troubleshoot/crid/398/lt_product_id/5846/tabs/1,3,2,4,5/cl/us,en

Speculation only: I wonder if the SetPoint and smooth scrolling software (which doesn’t run under linux) is truly an “extra” or if it was designed to combat some weakness, but since you don’t have the issue in linux, that tends to be discredited. It is still possible that placement of anything wireless could change and be a problem when you move the mouse/receiver.

There is one very simple tool which can tell you a lot: evtest. You’ll have to enable the “universe” repositories in /etc/apt/sources.list, and apt-get install evtest.

What evtest does is simply report input device events which are exposed to /dev/input/event* files. It does not interfere nor does it require configuration. Simply run evtest naming one of the /dev/input/event* files and it will put out text each time an event is found. Example is a key down or key up on a keyboard, a mouse click or wheel move on a mouse, or even the tiniest of movement on the mouse. The latter is what you are interested in. Do events stop being generated when the pause occurs, which would mean the source of events stopped, or do the events continue despite lock, meaning it would be the consumer of the events failing.

You can safely run evtest on each /dev/input/event* until you get one responding to your mouse. You might get one responding to keyboard or anything else before you find the mouse…simply move the mouse slightly after starting evtest to see if you found the right input device.

Autosuspend of USB devices can be controlled by changing the ‘autosuspend’ entry for corresponding USB device.
This is supposedly done to save power on embedded devices where in power is a limiting factory.

Changes can be made using below steps. For e.g:

Check the current status first,

And then change usb-device value for your connected usb device accordingly

cat /sys/devices/platform/tegra-xhci/usb1/1-3/power/autosuspend

echo > /sys/devices/platform/tegra-xhci/usb1/1-3/power/autosuspend

You can get the usb-device value from the device syslog logs on connecting the device to the USB port. Eg.
###################
[61624.234895] usb 1-3: new low-speed USB device number 6 using tegra-xhci
[61624.263772] usb 1-3: New USB device found, idVendor=046a, idProduct=000c
[61624.272294] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[61624.280631] usb 1-3: Product: USB Optical Mouse
[61624.286467] usb 1-3: Manufacturer: PixArt
[61624.306708] usb 1-3: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[61624.365406] input: PixArt USB Optical Mouse as /devices/platform/tegra-xhci/usb1/1-3/1-3:1.0/input/input4
###################

I have exactly the same problem. I use the Logitech “Unifying” receivers, I have 2 of them with 2 different set of mouse and keyboard, and they all do exactly the same behavior as described by Bill above.

For me also these receivers and mouse/keyboard combo work perfectly on Windows as well as Ubuntu (13.10 & 14.04 x64) and Mint 17, but it also works flawlessly on my Odroid U3 arm board that I have.

As you can see, I also use a keyboard with the unifying receiver and it also has the issue.

It would be great if there is a way to fix this since I really like to use a single USB receiver for both mouse and keyboard.

Note: After I updated to Grinch Kernel 19.3.2 (just by flashing the kernel itself, without the whole OS) I no longer experience the issue with the mouse and keyboard.

That’s because you were bitten by the usb auto suspend bug. The grinch kernel fixes it at start up.

I also finally flashed Grinch 19.3.6 instead of the standard 19.3 and the issue has immediately disappeared for me as well with no additional configuration changes necessary.
How come the auto suspend bug only affects some mice but not others? Do these mice use a different protocol mode or something?