xyproto / wallutils

:city_sunset: Utilities for handling monitors, resolutions, wallpapers and timed wallpapers
BSD 3-Clause "New" or "Revised" License
463 stars 17 forks source link

Change wallpaper after resume from suspend #6

Closed ernierasta closed 5 years ago

ernierasta commented 5 years ago

Hi, first - thank you for very nice collection of tools. Big plus for wayland/Sway support!

This is not classic issue, but just wanted to mention, that settimed do not recheck if change is necessary. So after you resume suspended laptop your wallpaper may be not up to current time. And this may be not necessary to do by settimed, you can solve it on system level. If you want to do so, you need to restart running settimed after wake up.

I use not very common Void Linux so I have my script in /etc/zzz.d/resume:

#!/bin/sh

APP=settimed
USER=ernie
HOMEDIR=/home/$USER

# (cl)2019ER
# restart given APP with previous params
# take full APP cmd from /proc and save in $CMD, kill process 
# and restart it with previous params.
# 
# Limitations:
# - it will not work if binary is not in the $PATH,
#   unless non-relative path is given when launching command.
# - be carreful with app params, we are cd'ing to home dir
#   to make user home relative paths work, but if not sure
#   use non-relative paths in params of originally launched command.
# - hope this is obvious ... but command (f.e.: settimed) has to be running
#   to be restarted. This script will not start it if not running before suspend.

# NOTE: 9>&- is Void Linux specific, it releases flock
#       set by zzz command.

pgrep -x $APP && \
CMD=$(xargs -0 < /proc/$(pgrep -x $APP)/cmdline) && \
pkill $APP && \
cd $HOMEDIR && su $USER -c "nohup $CMD > /dev/null 2>&1 &" 9>&- && \
logger -id $APP "Restarted on wake up."

But for mainstream distros you can find info here, look at systemd answer.

I would put it into wiki, but not enabled here. Maybe it can be in readme, or some other doc?

EDIT: fixed script.

ernierasta commented 5 years ago

It looks like idea is good, but script is not. For sure we need to run it under normal user (not root), but there may be more issues. I will be back after better testing.

xyproto commented 5 years ago

Thanks for reporting!

settimed uses its own event system, so somehow detecting that the system had just woke up would be one possible approach too, perhaps via sending a signal to the settimed process.

ernierasta commented 5 years ago

It would be great if we add HUP signal support, what do think about that? Unfortunately from what I see, HUP signal support was not implemented in cli.

EDIT: It would not solve woke up event detection, but allow easy process restart.

xyproto commented 5 years ago

Support for the HUP signal can be implemented with something like https://golang.org/pkg/os/signal/#example_Notify.

I am planning to implement it unless you don't beat me to it. Pull requests are welcome. :)

ernierasta commented 5 years ago

I am planning to implement it unless you don't beat me to it.

You mean "... not planning ..."?

I am going to PR, just wanted to check if You are willing to accept it. :-)

xyproto commented 5 years ago

I believe it's a good idea and I have not yet done any development on this. If you have something, that's great. :+1:

ernierasta commented 5 years ago

I decided to not implement HUP support, it would need at least PR's for 3 repos and some changes in logic (additional for loop). And the truth is, that it will work the same as well functioning autorestart.

So at the end, there were 2 problems with my script:

I will update first post with correct script.

EDIT: Done. BTW: script is app agnostic and should work with anything.

xyproto commented 5 years ago

Could something along the lines of this command be used for detecting when the system last resumed from sleep?

grep Awake /var/log/pm-suspend.log || grep 'systemd-sleep' /var/log/syslog | grep "Suspending\|resumed"
ernierasta commented 5 years ago

Maybe ... would not work on my system (but do not need to). Should probably work on systemd systems. I wish there would be better way to do that.

I do not know for how long settimed is usually sleeping, but maybe it would be better to check if currently used background is one, which should be displayed according to timing info?

ernierasta commented 5 years ago

And if you would like to use that, you need to pick last log entry, there would be many of them so something like: grep 'test' | tail -n1

xyproto commented 5 years ago

I would do it with Go code if I found a good way to detect this.

And tail -1 is shorter than tail -n1 ;)

ernierasta commented 5 years ago

True. :-)

Just brainstorming, maybe as a part of Makefile, You could install appropriate hook to system. It would need some investigation (or to find app which is already doing it), to find how to do it reliably. Hook can do one of following:

a) send mentioned HUP if you want to have it (technically better IMO), b) kill & re-spawn as I am doing it, c) send some custom signal.

Btw: Makefile: For me defaulting to /usr prefix is wrong, if your app would be packaged can be overwritten. /usr/local is standard IMO.

ernierasta commented 5 years ago

Btw: googling around, looking into kernel docs ... I do not see any good option to detect wake up without writing kernel driver. There is plenty of complicated options available but all required active checking (some loop running) - and if You need to check something - it is always much cleaner to just check if current picture is up to schedule.

xyproto commented 5 years ago

Made changes so that either the HUP or USR1 to settimed will force a refresh of the wallpaper.

For instance, with pkill:

pkill settimed -USR1

Could this help solve the issue?

xyproto commented 5 years ago

I also updated the documentation to mention make PREFIX=/usr/local install for users that wish to install it this way (I hope most users will install it as a package instead, if possible).

ernierasta commented 5 years ago

HUP support is great, it will simplify script a lot, going to test it now.

ernierasta commented 5 years ago

It looks great! Good work. Now you basically can use just one-liner sending HUP or USR1 and you are done. Tested, works like a charm. So I think we can close this issue ... ;-)

xyproto commented 5 years ago

Great! Thanks for testing and for filing the issue in the first place.