On Fri, Jan 18, 2019 at 03:19:11PM -0500, Zygo Blaxell wrote:
> I get:
 
[snipped]

>       HandleLidSwitch=suspend
>       HandleLidSwitchDocked=ignore
>       Docked=yes
 
> It seems there is some significant lag (several seconds, maybe a minute
> or two) before "Docked" changes to the correct value.  The "Docked" state
> definitely does not update while the rapid suspends are happening.  I can
> wake the laptop with the docked keyboard spacebar, but it immediately
> goes back to sleep again, at least 20 times.  After that it starts
> ignoring the spacebar and stays asleep until I undock and open the lid.
> 
> I encountered a similar problem on another laptop some months ago, where
> that laptop's lid switch was always reporting closed.  That system was
> running systemd, and the fix was to set HandleLidSwitch=ignore, but in
> a different configuration file from what elogind uses.

And does that fix work for elogind too if you set it in 
/etc/elogind/logind.conf?

> Note that docked state tracking is irrelevant to the original issue
> I was reporting.

Hmmm, the docked state changes which action elogind executes for the lid switch
-- HandleLidSwitch or HandleLidSwitchDocked. The defaults for each are
different. If the Docked state is slow to update then the wrong action might be
being invoked.

I also notice you have

>       InhibitDelayMaxUSec=5s
>       UserStopDelayUSec=0
>       HoldoffTimeoutUSec=30s
>       IdleActionUSec=30min

The manpage refers to InhibitDelayMaxSec, UserStopDelaySec, HoldoffTimeoutSec
and IdleActionSec (no 'U'). I will have to look into the significance of those.

> I had configured acpi-support to take no suspend
> action on lid close, docked or otherwise.  elogind appears to be
> unaware of acpi-support's overlapping functionality, and the maintainer
> scripts for elogind don't adjust elogind's configuration to disable
> lid/power/hibernate key handling if there's another ACPI event handler
> already installed on the system.  Both can be installed at the same time,
> and by default both will try to suspend the system, so in the worst case
> you could get two suspend/resume cycles per lid close (which is a great
> way to find ACPI firmware bugs).

Yes, maybe elogind and acpi-support should just conflict.

Mark

Reply via email to