JoshStrobl First of all thanks for your time on this.
I was not aware the screen saver is forked, but in the meantime I've pursued another avenue. I installed a fresh VM with Solus, updated to Gnome 3.38, configured the screensaver there to 1 minute and waited: the VM locks the screen properly.
So now I'm wondering if the problem is that some configuration is broken in my system due to eopkg's failed rollback.
When I tried to rollback from 3.38 with eopkg history -t n
, that failed due to a missing package (vino is removed from the repo). So eopkg aborted the rollback mid-way and I was forced to re-install all updates to go back to latest. (NOTE: I tried to roll back due to the resolution bug which I had just run into, and my first reaction was to revert).
I'm thinking that maybe some configuration was broken by eopkg when it interrupted its rollback?
One last thing I investigated was this:
I ran dbus-monitor in the VM and my desktop. I see in the VM these dbus messages when I go idle, the screen saver activates and when I move the mouse after:
# idle detected
signal time=1607120427.055833 sender=:1.34 -> destination=:1.7 serial=149 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
method call time=1607120427.056460 sender=:1.7 -> destination=:1.34 serial=293 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch
# screen saver activated
signal time=1607120437.280720 sender=:1.11 -> destination=(null destination) serial=17 path=/org/gnome/ScreenSaver; interface=org.gnome.ScreenSaver; member=ActiveChanged
method call time=1607120437.281013 sender=:1.24 -> destination=:1.34 serial=57 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddIdleWatch
# moved mouse, idle stop
method call time=1607120437.281120 sender=:1.24 -> destination=:1.34 serial=58 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch
signal time=1607120437.281972 sender=:1.34 -> destination=:1.24 serial=159 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
On the host which has the issue I see no mention of org.gnome.ScreenSaver. It simply doesn't activate:
# idle detected
signal time=1607120702.020979 sender=:1.35 -> destination=:1.7 serial=367 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
method call time=1607120702.021405 sender=:1.7 -> destination=:1.35 serial=364 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=AddUserActiveWatch
# moved mouse, idle stop
signal time=1607120722.263449 sender=:1.35 -> destination=:1.7 serial=370 path=/org/gnome/Mutter/IdleMonitor/Core; interface=org.gnome.Mutter.IdleMonitor; member=WatchFired
However, in the window running gnome-screensaver --debug
I do see it noticing the inactivity:
[watcher_idle_notice_cb] gs-monitor.c:126 (22:25:02): Idle notice signal detected: 1
[_gs_watcher_set_session_idle_notice] gs-watcher-x11.c:207 (22:25:02): Idle notice signal not handled: 1
I wonder who is supposed to handle this signal being emitted by gs-watcher. It is very likely that this failure to handle this signal is the culprit. Does something receive it and fail to process it? Does the thing supposed to receive it not run on my box anymore causing this? I don't know much about GNOME/dbus architecture unfortunately so I don't know what's supposed to happen there.