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
