Using Lenovo Ideapad S340 with Ubuntu 18.04
Suspend works, but after resume, the touchpad is barely active.
The following two commands restore the touchpad operation.
sudo modprobe -r i2c_hid
sudo modprobe i2c_hid
Is there a way to correct this behaviour permanently without having to issue these commands everytime?
The hardware/software description is below.
Lenovo Ideapad S340
Ubuntu 18.04 (dual boot with Win10)
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Logitech M185/M225 id=9 [slave pointer (2)]
⎜ ↳ MSFT0002:01 04F3:304B Touchpad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Power Button id=8 [slave keyboard (3)]
↳ Integrated Camera: Integrated C id=10 [slave keyboard (3)]
↳ Ideapad extra buttons id=12 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=13 [slave keyboard (3)]
↳ Logitech M185/M225 id=14 [slave keyboard (3)]
it has been a while since this question was asked, but not so long that i thought starting a new thread was really necessary. i had a similar issue with slight loss of touchpad functionality on my thinkpad W540 (some of which i detailed here) running bodhi linux 5.1.0 which is based on ubuntu 18.04. i was reviving mine with similar commands:
sudo modprobe -r psmouse && sudo modprobe psmouse.
that worked just fine and restored full functionality, but i was also searching for a way to get my system to effectively reset it self after waking from suspend. i tried similar methods to add commands to post-suspend wakeup without any luck. after some helpful discussion with @Tech_JA (as well as pointers in the linked thread from @Akito) and reading through some logs (most notably /var/log/pm-suspend.log), i realized there were some hooks (or commands) that the system was running as it woke up from suspend. for my system those hooks were located in /usr/lib/pm-utils/sleep.d.
the highest number hook (95) ran first and the lowest (000) ran last. i read through the other hooks to get an idea about what format worked (most all used #!/bin/sh instead of /bash for example) and decided try adding my hook after 00logging to make sure i could see it in case there were any errors or other issues.
i named my file 0000touchpad-mod and these were the contents:
# modprobe psmouse off and back on
/sbin/modprobe -r psmouse && /sbin/modprobe psmouse
case "$1" in
i ran chmod +x on the file to make sure it was executable.
i thought it would be better to restart the system entirely to ensure the possible solution had the best chance of success, but since i was already up and running i decided to suspend and see what happened. luckily, it worked as intended. the system ran my hook after all of the others and my touchpad had full functionality with no manual intervention.
i did reboot just to make sure the change survived that. then i waited a week to make sure i hadn’t done anything that would inadvertently have ill effects on my system. so far (knock on wooden head) it has worked perfectly every time and i now don’t even realize it runs in the background.
If you are interested in more touchpad gestures on your S340, have a look here, https://github.com/iberianpig/fusuma. I like the 3, 4 finger swipes and pinching. Works differently in Kubuntu, Gnome shell and Unity.
Have attempted the following and that seems to have restored the touchpad functionality after every resume.
Have placed a script containing the modprobe commands in /etc/pm/sleep.d
See : https://wiki.debian.org/Hibernation
Will watch for few days and report if something goes wrong.
Would also try placing it in /usr/lib/pm-utils/sleep.d (Would that work only for my user login?)
that’s an interesting question. i don’t have a multiuser system to check it on, but it seems like it would be quick and easy enough to test by logging into a different user if your system has one.