From 314b4b0a68d9ab35de981923a088fc8c8820caa5 Mon Sep 17 00:00:00 2001 From: Lennart Poettering Date: Fri, 25 Jan 2013 06:30:23 +0100 Subject: logind: rework delay inhibition logic - Don't allow any locks to be taken while we are in the process of executing the specific operation, so that apps are not surprised if a suspend/shutdown happens while they rely on their inhibitor. - Get rid of the Resumed signal, it was a bad idea, and redundant due to PrepareForSleep(false), see below. - Always send out PrepareFor{Shutdown,Sleep} signals, instead of only if a delay lock is taken. - Move PrepareForSleep(false) after we come back from the suspend, so that apps can use this as "Resumed" notification. This also has the benefit that apps know when to take a new lock. --- src/login/logind.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'src/login/logind.c') diff --git a/src/login/logind.c b/src/login/logind.c index ed0b7489b9..be793e2a93 100644 --- a/src/login/logind.c +++ b/src/login/logind.c @@ -1628,11 +1628,11 @@ int manager_run(Manager *m) { manager_gc(m, true); - if (m->delayed_unit) { + if (m->action_what != 0) { usec_t x, y; x = now(CLOCK_MONOTONIC); - y = m->delayed_timestamp + m->inhibit_delay_max; + y = m->action_timestamp + m->inhibit_delay_max; msec = x >= y ? 0 : (int) ((y - x) / USEC_PER_MSEC); } -- cgit v1.2.3-54-g00ecf