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? I think that'd be cleaner (in some ways) than an autoaction cooldown timer. Whenever I want to add an arbitrary delay that isn't per se required by an interface I wonder whether I'm working around a deficiency in the state machine instead of addressing the root cause. Sometimes it can't be helped, but I have to ask. For the second case, I thought the design of autoaction was to (a) note that the battery was below a particular threshold and (b) take action to avert data loss. If you resume from suspend with battery below the threshold and no AC I think you would *want* autoaction to trigger. Like, it sounds like the state machine is working as designed. If the machine is immediately suspending after resume shouldn't you just plug it in before reattempting resume? Isn't that better than having the battery die on you?
