Scheduled refresh wakes the monitor on Xfce — the power-management inhibitor disables DPMS

Mint 22.3 Xfce, mintupdate 7.1.4, xfce4-power-manager 4.18.4, systemd. Same code on current master.

On an idle machine with nobody at it, every scheduled refresh powers the monitor back on. With the
default 2-hour schedule (two staggered series on this box) the panel was lit roughly 15 minutes of
every hour, around the clock.

The trigger is the inhibitor, not the apt or flatpak work. inhibit_pm() in 7.1.4
(util.Inhibitor.inhibit() on master) calls org.freedesktop.PowerManagement.Inhibit when the
session is Xfce, and xfce4-power-manager implements that by disabling DPMS — which powers a
currently-blanked panel back on.

That call on its own, panel off, no input for 654 s:

09:12:01 panel Off, idle=654s -- calling Inhibit('mintupdate', 'Checking for updates')
09:12:02 *** PANEL ON at +0.2s after Inhibit, X-idle=654s (no input) ***
09:12:02 HasInhibit=True
09:12:02 xset q says: Disabled

Connector state is read from /sys/class/drm/card1-DP-1/dpms, idle from XScreenSaverQueryInfo
(unchanged across the wake, so nothing touched the keyboard or mouse).

The matching pair from a real refresh on the same machine — mintupdate's own log:

/tmp/mintUpdate/00ev80nh
2026.09.15@08:57 ++ Changes to the package cache detected; triggering refresh
2026.09.15@08:57 ++ Inhibited power management
2026.09.15@08:57 ++ Checking for updates
2026.09.15@08:57 ++ Refresh finished
2026.09.15@08:57 ++ Resumed power management

and the connector at the same second:

2026-09-15T08:52:16 On/enabled -> Off/disabled  idle=600s
2026-09-15T08:57:06 Off/disabled -> On/enabled  idle=890s   <-- no input for 890 s

Everything else in the refresh was ruled out by running each step on its own with the panel off and
watching the connector for 40 s:

control-sleep          NO WAKE (held Off 40s)
worker-refresh         NO WAKE (held Off 40s)     flatpak-update-worker.py --refresh
control-sleep-2        NO WAKE (held Off 40s)
gtk-init               NO WAKE (held Off 40s)
mintcommon-import      NO WAKE (held Off 40s)
fp-list-installed      NO WAKE (held Off 40s)
fp-cleanup-prune       NO WAKE (held Off 40s)
installer-init-sync    NO WAKE (held Off 40s)
fp-update-appstream    NO WAKE (held Off 40s)

sudo /usr/bin/mint-refresh-cache by hand does not reproduce it either.

The inhibitor is released correctly at the end of the refresh and DPMS is re-enabled, but the idle
countdown restarts from zero, so each refresh costs a full DPMS timeout (900 s here) of lit panel.

The non-Xfce path already asks for LOGOUT | SUSPEND and deliberately leaves out the idle flag;
org.freedesktop.PowerManagement.Inhibit has no flags and always includes idle.

A logind block inhibitor gives the same protection with no display side effects. Measured in the
graphical session (session-c1.scope), panel off:

09:15:59 panel Off, idle=892s -- taking logind sleep:shutdown block inhibitor
09:15:59 got inhibitor fd=9 in 4ms
09:16:24 NO WAKE: connector held Off for 25s with the inhibitor active, idle=917s
09:16:24 xset q DPMS: Enabled
mintupdate  1000 lucy 33974 python3  shutdown:sleep  block
09:16:25 released; connector=Off

Both actions are allowed for the GUI process without any prompt:

$ pkcheck --process 1897 --action-id org.freedesktop.login1.inhibit-block-sleep    ; echo $?
0
$ pkcheck --process 1897 --action-id org.freedesktop.login1.inhibit-block-shutdown ; echo $?
0

As a bonus the fd is dropped automatically if mintupdate exits unexpectedly, so it cannot leave the
session inhibited the way a leaked cookie can (cf. #941).

Patch in the next comment / PR. Current workaround is turning the refresh schedule off entirely.

Start at util.Inhibitor.inhibit() on current master, or inhibit_pm() in the 7.1.4 code, and compare the Xfce path with the existing non-Xfce inhibitor behavior. Check the logind block-inhibitor measurements in the issue, then verify that scheduled refreshes no longer wake DPMS and that protection is released when refresh finishes or the process exits.