It is simple and safer to generate these ad-hoc small command sequences. You can always hack the default pm-suspend script, but I won't recommend it. No time to hack involved.Īnd then, after resuming the laptop, you should re-enable the module by typing: Of course this is not fancy at all, but works and it is a straigh forward solution. To do that I use a simple command line to suspend the laptop instead of just closing the lid "manually". How to execute a command after resume from suspend?Īn alternative approach is to kill the module before suspend, avoiding to lock of the module after the resume (which apparently is what generates the issue, as WinEunuuchs2Unix underlined). Here is a nice discussion on how to do this "automatically": The first, which not always works (as you mentioned) just restarts the mouse module after the suspend action. I deal with two simple approaches with this issue. Still haven't figured out the dual suspend and dual resume yet. The 2 second delay was necessary for kernel and systemd to finish waking up. I needed to redirect pulseaudio sound back to the TV due to a bug introduced in Ubuntu 16.04/pulseaudio 8.0. The sleep 2 command is from my own problems where systemd and kernel (via gnome or APM) were both sleeping and waking up. After resume insert it and hopefully the kernel won't reject it. So this technique removes it before suspend. We also know it can be removed and inserted before a suspend. It is known after a suspend the psmouse module can't be removed. # Place your post suspend (resume) commands here, or `exit 0` if no post suspend action required # Place your pre suspend commands here, or `exit 0` if no pre suspend action required If this works manually then you can automate by creating a new file in the /lib/systemd/system-sleep/ directory containing: #!/bin/sh But what if psmouse was removed before suspend and inserted after suspend? After suspend the OP tries # modprobe -r psmouse and # modprobe psmouse and it doesn't work. This bug is reported in launchpad: Elantech touchpad stops working after suspend. I also modified other default power settings to go to hibernate using the dconf Editor under org>gnome>settings-daemon>plugins>power Here are the steps I followed to enable hibernate. Since hibernate seems to not cause a problem and I have an appropriate amount of swap memory, I just hibernate as the default action for things like closing the lid. I don't observe this problem if I hibernate instead of suspend. However when I suspend, I can't "revive" the touch pad, even if I enter these commands.
I can run sudo modprobe -r psmouse to "turn off" the touchpad, and then sudo modprobe psmouse to turn it back on.
Xserver-xorg-input-synaptics-lts-vivid (not sure which one is in use)
0 kommentar(er)
