A quick thing to check… … can you edit the script and replace “$USER” with your actual username and check that ? (so that it reflects the actual path, ex - /home/cscs/.Xauthority)
Yes!!! It works! Thank you, thank you, thank you! 
Hm. Yeah thats more sure… but I thought I had gotten it with the env var … owell
but hey … glad it worked in the end 
cheers!
I was getting a Failed message on reboot and edited the systemd file to exclude the basic.target. My file now includes:
[Unit]
Description=Restart Touchpad
After=suspend.target hibernate.target
[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/local/bin/EnableTouchpad.sh
[Install]
WantedBy=suspend.target hibernate.target
Once again, thanks @cscs!
1 Like
Ah … yes it was designed to start at first login too.
That can mean it starts too fast in that case … so in another case a ~ sleep 5 was put on the beginning because at boot the script started before the module was loaded.
But your solution makes more sense for your scenario - dont need it at boot, dont need a wait.
cheers
Glad it works for h_ramus!
On my side I get an error when trying to enable the service:
systemctl enable restart-touchpad.service --user --now
The output is:
The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified.
Whereas the file ~/.config/systemd/user/restart-touchpad.service does exist and is executable (owned by me).
I had to create the directories systemd/user in my .config, so I am wondering if systemd is really looking into it. Is there some sort of user declaration to be done with systemd?
Hi. I think the systemd restart-touchpad.service file was missing [Install]. Check that your file includes
[Install]
WantedBy=suspend.target hibernate.target
Thanks! I was able to enable the service with:
systemctl enable restart-touchpad.service --user --now
But it still does not work after suspend and when I look at the status with:
systemctl status restart-touchpad.service --user
I get:
● restart-touchpad.service - Restart Touchpad
Loaded: loaded (/home/bapman/.config/systemd/user/restart-touchpad.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Although I went on suspend, there is no log of that in the status.
The content of /home/bapman/.config/systemd/user/restart-touchpad.service is:
[Unit]
Description=Restart Touchpad
After=suspend.target hibernate.target[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/local/bin/restart-touchpad.sh[Install]
WantedBy=suspend.target hibernate.target
And when I source /usr/local/bin/restart-touchpad.sh directly from the terminal, it works!
Quick question. Did you enable the service after editing the systemd file? Enabling the systemd service binds the targets to the service making it run when either suspend or hibernate is activated.
If it was already enabled, try disabling and then enabling to rebind targets.
systemctl disable restart-touchpad && systemctl enable restart-touchpad
I tried it but it made no change.
Note that I need to add “--user” to every command or I get the error “Failed to disable unit: Unit file restart-touchpad.service does not exist.”
systemctl disable restart-touchpad --user && systemctl enable restart-touchpad --user
hum…my systemd service is owned by root. Is your restart-touchpad.service owned by root or the user? If the user try chown to root:root and see if that works. If I add --user to the systemctl command it fails for me.
Now it works, thanks!
I followed the instructions given by cscs and the service was belonging to my user (and stored in ~/.config). With the service owned by root and stored in /etc/systemd/system/, it finally works!
Again, thanks to you and cscs.
That’s great to hear! Hopefully this settles the touchpad issues that one might face.
Someone found a way to edit acpi dsdt table to advertise the lid button and enable the laptop to wakeup when the lid opens.
The dsdt patch file is included in - https://gist.github.com/polikutinevgeny/7d673fe2453d88461ab06edfd7556d14. This is a comment to the original reddit post on enabling S3 sleep.
1 Like
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.