You are not logged in.
I use autorandr to set my displays within Xorg. I have sometimes troubles making it load the xrandr configurations when I wake the system up. My "/sys/power/mem_sleep" is set to
s2idle [deep]
autorandr has a hook to run the unit set to "After=sleep.target":
[Unit]
Description=autorandr execution hook
After=sleep.target
StartLimitIntervalSec=5
StartLimitBurst=1
[Service]
ExecStart=/usr/bin/autorandr --batch --change --default default
Type=oneshot
RemainAfterExit=false
KillMode=process
[Install]
WantedBy=sleep.target
However, this works randomly. I tried:
[Service]
ExecStartPre=/bin/sleep 10
ExecStart=/usr/bin/autorandr --batch --change --default default
Type=oneshot
RemainAfterExit=false
KillMode=process
But I realised the hook wasn't running at all when waking up from S2Idle state. Is this expected?
Last edited by jfk (2023-03-26 15:59:48)
Offline
But I realised the hook wasn't running at all when waking up from S2Idle state. Is this expected?
Check the journal, does the s2idle "sleep" not reach/finish the sleep.target?
Also how do you enter this? (as the default is set to "deep")
Do you just "echo freeze > /sys/power/state"?
Offline
Also how do you enter this? (as the default is set to "deep")
Do you just "echo freeze > /sys/power/state"?
Yes. Actually I've been letting "gnome-power-manager" works by itself. I didn't know I was going into S2Idle state before investigating the issue. So if I want to mimic what gnome does I do enter "echo freeze > /sys/power/state":
mar 27 18:42:05 xps13-fpierreh sudo[729057]: root : TTY=pts/1 ; PWD=/home/fabien ; USER=root ; COMMAND=/usr/bin/echo freeze
mar 27 18:42:05 xps13-fpierreh sudo[729057]: pam_unix(sudo:session): session opened for user root(uid=0) by fabien(uid=0)
mar 27 18:42:05 xps13-fpierreh kernel: PM: suspend entry (s2idle)
mar 27 18:42:06 xps13-fpierreh kernel: Filesystems sync: 0.804 seconds
mar 27 18:42:20 xps13-fpierreh kernel: Freezing user space processes
mar 27 18:42:20 xps13-fpierreh kernel: Freezing user space processes completed (elapsed 0.002 seconds)
mar 27 18:42:20 xps13-fpierreh kernel: OOM killer disabled.
mar 27 18:42:20 xps13-fpierreh kernel: Freezing remaining freezable tasks
mar 27 18:42:20 xps13-fpierreh kernel: Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
mar 27 18:42:20 xps13-fpierreh kernel: printk: Suspending console(s) (use no_console_suspend to debug)
mar 27 18:42:20 xps13-fpierreh kernel: sd 3:0:0:0: [sda] Synchronizing SCSI cache
mar 27 18:42:20 xps13-fpierreh kernel: sd 4:0:0:0: [sdb] Synchronizing SCSI cache
mar 27 18:42:20 xps13-fpierreh kernel: sd 3:0:0:0: [sda] Stopping disk
[etc.]
The execution hook doesn't run when I wake the system up from this state. However, when I "suspend" the session and go back, then the hook is triggered:
mar 27 18:35:45 xps13-fpierreh systemd[1]: Starting autorandr execution hook...
[...]
mar 27 18:35:55 xps13-fpierreh autorandr[728785]: Config already loaded
mar 27 18:35:55 xps13-fpierreh autorandr[728785]: autorandr running as user fabien (started from batch instance)
mar 27 18:35:55 xps13-fpierreh autorandr[728785]: Bureau (detected) (current)
mar 27 18:35:55 xps13-fpierreh autorandr[728784]: Running autorandr as fabien for display :0
mar 27 18:35:55 xps13-fpierreh systemd[1]: autorandr.service: Deactivated successfully.
mar 27 18:35:55 xps13-fpierreh systemd[1]: Finished autorandr execution hook.
Last edited by jfk (2023-03-27 17:15:02)
Offline
You're not reaching the sleep.target (this way) - what if you
echo s2idle | sudo tee /sys/power/mem_sleep
systemctl sleep
?
Offline
$ echo s2idle | sudo tee /sys/power/mem_sleep
s2idle
$ systemctl sleep
Unknown command verb sleep.
You're not reaching the sleep.target (this way)
Yes that is precisely the "ambiguity" I've been trying to understand. S0ix state is sometimes described as a "sleeping state" but systemd doesn't seem to include it in its targets - and there's no "wakeup target" which might solve the issue here.
Last edited by jfk (2023-03-27 23:09:22)
Offline
systemctl suspend
Sorry.
You're also not entering the sleep target when the cpu enters c6. "freeze" isn't "sleep"
Moving back to the gnome-power-manager situation: why does it enter s2idle to begin with?
Also why do you want/need to run autorandr in this situation? I guess to work around another gnome thing?
Are you looking for x-on-resize (AUR)?
Offline
Moving back to the gnome-power-manager situation: why does it enter s2idle to begin with?
As I said, this happened to be the "default" state I got from setting the suspend timer from the GUI. I haven't investigated this in depth.
Also why do you want/need to run autorandr in this situation? I guess to work around another gnome thing?
I've got 2 displays connected to my laptop (so 3 in total). It's the easiest option I've found to set what I want quickly. The thing is when the system wakes up it randomly turns all displays on (which I don't want). In that case, I need to manually run autorandr to get back my default profile. The hook should be there to avoid that gesture and I wanted to know wether I can keep my power management as such and trick systemd to run the hook somehow. Apparently this is not possible.
Are you looking for x-on-resize (AUR)?
I'll look into it.
Last edited by jfk (2023-03-28 21:44:48)
Offline
These might or not convince gnome to leave your output configuration alone:
https://wiki.archlinux.org/title/GNOME#Power
gsettings set org.gnome.settings-daemon.plugins.xrandr default-monitors-setup do-nothing
Offline
gsettings set org.gnome.settings-daemon.plugins.xrandr default-monitors-setup do-nothing
Yes this was one of my idea but the key has been deleted since Gnome 40. But I tried:
dconf write /org/gnome/settings-daemon/plugins/xrandr/active false
As it is random, I need to test it for a while.
Last edited by jfk (2023-03-29 15:34:37)
Offline
So not surprisingly no success to report. It is my understanding that we cannot disable gnome screen detection aynmore.
Offline
You could check whether s2idle triggers an ACPI event that you can intercept w/ https://wiki.archlinux.org/title/Acpid#Example_events
As for a super-ugly workaround you could have a daemon check the system time every 60 seconds or so and if there's a time jump, assume a wake from idle and fire autorandr.
Finally, iff gnome acts because the output un- and re-registers, https://aur.archlinux.org/packages/x-on-resize might come to the rescue (you'd detect the appearing output yourself and handle the event accordingly)
Offline