Hi,
as Nate pointed out, suspend inhibition is only about blocking automatic
suspend, e.g. during a lengthy operation. Explicit user interaction,
such as pressing the suspend button or closing the lid are never blocked
by us.
As for Logind, the “challenge” response means that the user can only
suspend if PolicyKit allows it. What could happen is that a Polkit
prompt pops up (e.g. “permission is needed to suspend with another user
logged in” or something) but I don’t see why we would need to handle
this specially on the Plasma side.
Cheers
Kai Uwe
Am 13.09.25 um 05:34 schrieb SignKirigami:
Hello everyone, I find it confusing that some inhibitions will prevent system
from auto suspend, but not manually clicking suspend button, so I try to read
source code of powerdevil and plasma-workspace.
As far as I can see, in plasma-workspace there is canSuspend function which
will check systemd-inhibit from dbus, and return yes when login1 returns yes
or challenge(some applications requests inhibition will lead to this). Suspend
button uses this, but because canSuspend treats yes and challenge as the same,
there is no difference whether systemd inhibition exists, that's why suspend
button will ignore systemd inhibition.
In powerdevil, what canSuspend returns is used in function
loadAllInactiveActions, which will create a new profile with canSuspend and
give it to suspendsession action, let it determine auto suspend or not. There
is another mechanism which really works called policyagent. It syncs with
systemd inhibitions and has its own inhibitions related to settings and old
program(like ktorrent). When suspendsesstion handles timeout, it checks
policyagent to determine whether to suspend or not.
Now I wonder if these really work as expected? Do we need to check systemd
inhibition and give a warnning before do actual suspend work when inhibition
exists?
