Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is related to the issue discussed in this question. Summary: the mouse freezes when operating on battery since it is autosuspended after a certain time and needs more time to wake up. Disabling usb-autosuspend for the mouse's receiver in powertop is a temporary solution but does not survive a reboot.

How can I permanently disable the usb autosuspend for only one specific device?

A solution that does not involve installing additional packages is preferred (after all, I want to disable something) but not required. Removing powertop (which seems to be a solution for some) is not what I want - I like poertop... And installing laptop-mode-tools to disable usb_autosuspend alltogether is not what I want, either, thus the new question.

Also: will this affect the battery of my notebook? The logitech unifying receiver for the mouse stays connected all the time, so if that prevents the autosuspend from happening for all devices that would probably be bad.

share|improve this question
up vote 8 down vote accepted

As mentioned here at , the trick consists in two parts:

Using lsusb to ascertain the device IDs of the USB devices you wish to disable autosuspend for.
And then adding them to AUTOSUSPEND_USBID_BLACKLIST in the /etc/laptop-mode/conf.d/runtime-pm.conf (usb-autosuspend.conf until Ubuntu 14.04) config file (details are well documented in there as well).

share|improve this answer
Actually my mouse got lost/stolen shortly after, so I cannot test this. But judging from the .conf file this is exactly the kind of thing I was hoping for :) – black_puppydog Nov 3 '13 at 11:36

I had a similar problem with PCs on an Avocent KVM, where laptop-mode-tools is not installed (and didn't want to solve it that way in any case). In my case, autosuspending the KVM made the keyboard and mouse behave erratically (after a few seconds idle, they'd suspend and lose input data for a while until enough clicks and shakes woke them up.)

When I ran powertop and toggled USB autosuspend off for the Avocent, powertop told me the command to disable it from the command line was:

echo 'on' > '/sys/bus/usb/devices/3-10/power/control'

The '3-10' bit will be different on different systems. I'm not sure how to determine that other than running powertop, but there's probably some way.

Instead, I used a udev rule to match the product id of my device:

trent+14.04:/etc/udev/rules.d$ cat 10-usb-avocent-kvm-pm.rules

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624", ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM", TEST=="power/control", ATTR{power/control}:="on"

To get the proper udev information I ran:

udevadm info -a --path /sys/bus/usb/devices/N-N

share|improve this answer

You will find in /etc/laptop-mode/conf.d/usb-autosuspend.conf:

# Enable USB autosuspend feature?
# Set to 0 to disable

You should change it to CONTROL_USB_AUTOSUSPEND="0"

This will automatically make any USB device has a value "on" in /sys/bus/usb/devices/"DEVICE ID"/power/control. This will make value of the autosuspend files inactive:

$ cat /sys/bus/usb/devices/"DEVICE ID"/power/autosuspend
$ cat /sys/bus/usb/devices/"DEVICE ID"/power/autosuspend_delay_ms
share|improve this answer

The power options for a USB device are in /sys/bus/usb/devices/n-n/power. Unfortunately, what n-n is for a given device takes some sleuthing to find out, so I think this will prove a stumbling block when it comes to having a script that automatically does

echo -1 > /sys/bus/usb/devices/3-2/power/autosuspend

to turn off autosuspend on that device. The magic n-n does actually appear in the output of

udevadm info --export-db

so I think udev will be your friend here; some kind of udev script keyed on a parameter that identifies your mouse, then runs a script that echos -1 into the relevant file.

share|improve this answer
Will this survive a reboot? echoing into /sys seems to be non-permanent, isn't it? – black_puppydog Sep 16 '12 at 18:53
Put the command in your /etc/rc.local before the 'exit 0' line – Bryce Sep 18 '14 at 23:51

I created my own udev rule: ACTION=="add", ATTR{idVendor}=="0cf3", ATTR{idProduct}=="3004", RUN="/bin/sh -c 'echo 0 >/sys/\$devpath/authorized'"

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.