One of the most annoying “features” of Ubuntu is that it will wake from suspend on mouse move, even if waking up your system was the last thing you wanted; in fact, it will wake from suspend, a second after you put it to sleep, if your touch is less than feather-like in releasing the mouse after clicking on the “Suspend” button.
(By the way, Canonical: why did you feel the need to “hide” the Suspend button, and only enable it on Alt-press?)
Unfortunately, the most popular solutions on the matter will also cause the keyboard to be disabled (if you happen to have a USB keyboard) and that is actually something we want.
The “popular” solution (don’t do this) is to modify the /proc/acpi/wakeup system file, by disabling the offending device:
└─( cat /proc/acpi/wakeup | grep enabled
will give you a list of enabled devices, and then it’s a bit of guesswork as to which one is the USB hub that your mouse connects to — on my system there are two: EUSB and USBE, turns out that the hub to which both the keyboard and the mouse are connect is the EUSB, so this would disable both:
└─( sudo sh -c "echo EUSB >/proc/acpi/wakeup"
The above works, but it is crude and, as mentioned, disables the keyboard wake, which is actually useful.
A more granular alternative can be derived from this post which is actually about enabling the wake-on-mouse; but the principle is the same.
First, we start by enumerating the USB devices connected to the system:
└─( lsusb | sort
from here, it’s pretty obvious which one is the mouse:
...
Bus 002 Device 006: ID 046d:c52b Logitech, Inc. Unifying Receiver
...
then we proceed with finding where the devices are mapped to:
└─( grep . /sys/bus/usb/devices/*/power/wakeup | grep enabled
/sys/bus/usb/devices/2-1.2.6/power/wakeup:enabled /sys/bus/usb/devices/2-1.2.7/power/wakeup:enabled
Finally, to figure out which is which, we use:
└─( dmesg | grep Logitech | grep -o -P "usb.+?\s" usb 2-1.2.7:
at which point it’s pretty obvious which one needs to be disabled:
└─( sudo sh -c "echo 'disabled' > /sys/bus/usb/devices/2-1.2.7/power/wakeup"
(note: every time you need to echo as superuser, sh -c is necessary, or the system will not allow redirecting to a priviliged file).
Then it’s just a matter of suspending the system and verifying that, while the mouse does not wake it, the keyboard will.
Update: this does not survive a system reboot, so either you need to re-run the last command, or add it to your .bashrc or .zshrc.
This is something that has been annoying me on Ubuntu since when I installed 16.04, and probably there forever, I cannot understand why Canonical wouldn’t add this in the System Settings.
I found the command that will keep my mouse from waking my laptop from suspend: sudo sh -c “echo ‘disabled’ > /sys/bus/usb/devices/1-3/power/wakeup”
And you’re right that it doesn’t survive a reboot. However, are you sure I’m supposed to put that in my .bashrc file? When I do, it still doesn’t keep my mouse from waking the computer, until I open a terminal. Then, every time I open a terminal, it asks for my sudo password (if I keep the sudo command in) and THEN activates the command, or it tells my i don’t have permission to run that command (if I don’t keep the sudo command in). Neither of those situations is acceptable. Is there a system-wide place I should be putting that command, so that I don’t have to open a terminal and type my password before my mouse is prevented from waking the system?
Hey Mike, thanks for reading my blog!
That is “expected behavior” as `.bashrc` is only executed upon running an interactive TTY session (and not a graphic UI) – there is a way to add scripts to be run at login (if memory serves, you need to use Alt+F2 or something like that) but I found it rather unreliable.
To get you going, I recommend googling “ubuntu login run scripts”
And, anyway, Terminal (actually, Terminator 🙂 ) is the first thing I run upon logging in Ubuntu: without a shell, it’s not much use to me.
As for asking your password when using `sudo` this is, again, “expected behavior” and protects the integrity of the system; you can bypass it by adding your user to the `sudoers` group (remember to use `visudo` to edit the /etc/sudoers file); this may help guiding you in the right direction: https://codetrips.com/2012/01/18/adding-a-new-sudoer-in-ubuntu/
Hope this helps!