В Сб, 04/01/2014 в 19:21 +0100, Per Jessen пишет:
[...]. Jan 04 15:16:43 toshiba1 systemd-logind[669]: Lid closed. Jan 04 15:16:46 toshiba1 systemd-logind[669]: Suspending... Jan 04 15:30:17 toshiba1 systemd-logind[669]: Lid opened.
What is missing is my closing the lid again ... (and the machine wasn't suspended either).
But the lid close is detected and logind tries to suspend. That is good!
Except it only happens once.
systemd-logind gets events directly from input device corresponding to LID switch. Here it is P: /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input4 E: DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input4 E: EV=21 E: ID_FOR_SEAT=input-acpi-PNP0C0D_00 E: ID_INPUT=1 E: ID_PATH=acpi-PNP0C0D:00 E: ID_PATH_TAG=acpi-PNP0C0D_00 E: MODALIAS=input:b0019v0000p0005e0000-e0,5,kramlsfw0, E: NAME="Lid Switch" E: PHYS="PNP0C0D/button/input0" E: PRODUCT=19/0/5/0 E: PROP=0 E: SUBSYSTEM=input E: SW=1 E: TAGS=:seat: E: USEC_INITIALIZED=139610 And systemd-l 30202 root 13u CHR 13,71 0t0 5897 /dev/input/event7 systemd-l 30202 root 20u CHR 13,69 0t0 5886 /dev/input/event5 systemd-l 30202 root 21u CHR 13,68 0t0 5885 /dev/input/event4 systemd-l 30202 root 22u CHR 13,70 0t0 5887 /dev/input/event6 If systemd-logind does not log Lid close/open event anymore this would mean that either kernel stops delivering it or for whatever reasons device changed in between, so logind continues to listen on "dead" device. Both imply some kernel issue. I had once funny case of "On Battery" information being wrong after resume because kernel incorrectly restored memory used to store this bit ... Try running "upower --monitor-detail" across suspend. It takes events from the same source so it would be interesting whether it stops seeing Lid close at the same time. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org