On Fri, Feb 14 2020, Scott Cheloha <scottchel...@gmail.com> wrote: > On Thu, Feb 13, 2020 at 02:08:32PM +0100, Jeremie Courreges-Anglas wrote: >> On Wed, Feb 12 2020, Scott Cheloha <scottchel...@gmail.com> wrote: >> > On Wed, Feb 12, 2020 at 01:35:22PM +0100, Jeremie Courreges-Anglas wrote: >> >> On Wed, Feb 12 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: >> >> > On Sat, Jan 25 2020, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: >> >> >> The diff below improves the way apmd -z/-Z may trigger. >> >> >> >> >> >> I think the current behavior is bogus, incrementing and checking >> >> >> apmtimeout like this doesn't make much sense. >> >> >> >> >> >> Here's a proposal: >> >> >> - on APM_POWER_CHANGE events, check the battery level and trigger >> >> >> autoaction if needed. This should be enough to make autoaction just >> >> >> work with drivers like acpibat(4). >> >> >> - on kevent timeout (10mn by default now, maybe too long), also check >> >> >> the battery level and suspend if needed. This should be useful only >> >> >> if your battery driver doesn't send any APM_POWER_CHANGE event. >> >> >> >> >> >> While here I also tweaked the warning. >> >> > >> >> > This has been committed, thanks Ted. >> >> > >> >> >> Some more context: >> >> >> - a subsequent diff would reorder the code to handle similarly the >> >> >> "!rv" >> >> >> and "ev->ident == ctl_fd" paths >> >> > >> >> > Diff below. >> >> > >> >> >> - I think we want some throttling mechanism, like wait for 1mn after we >> >> >> resume before autosuspending again. But I want to fix obvious >> >> >> problems first. >> >> >> >> On top of the previous diff, here's a diff to block autoaction for 60 >> >> seconds after: >> >> - autoaction triggers; this prevents apmd from sending multiple suspend >> >> requests before the system goes to sleep >> >> - a resume happens; this gives you 60 seconds to fetch and plug your AC >> >> cable if you notice you're low on power >> >> >> >> A side effect is that apmd now ignores stale acpiac(4) data at resume >> >> time, so it apmd doesn't suspend the system again when you resume with >> >> a low battery and AC plugged. >> >> >> >> cc'ing Scott since he has a thing for everything time-related. :) >> > >> > For the first case, is there any way you can detect that a suspend is >> > in-progress but not done yet? >> >> Well, apmd could record that it asked the kernel for a suspend/hibernate >> and skip autoaction as long as it doesn't get a resume event. > > Hmmm. So what happens if the suspend/hibernate fails? Could apmd(8) > get stuck waiting for a resume that will never happen?
Well, if suspend fails maybe there's no point in having apmd retry a suspend. Also what would get stuck is only the autoaction behavior, the rest of apmd would keep on working as usual. acpi_sleep_state seems to properly send a RESUME event even if suspend/hibernate fails, except in one error case. But depending on a resume event is not portable, the APM code in i386 and loongson doesn't notify userland about resumes. Something that ought to be fixed. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
