SUMMARY On GNOME if I closed the lid, it goes to sleep correctly. On KDE, in system settings, the option to go to sleep on lid close is missing: https://i.imgur.com/I0wHGxz.png The lid closed is detected, in fact here is the journalctl log: Jan 10 09:51:28 Archy systemd-logind[527]: Lid closed. Jan 10 09:51:28 Archy root[2260]: LID closed Jan 10 09:51:36 Archy systemd-logind[527]: Lid opened. Jan 10 09:51:36 Archy root[2264]: LID opened but nothing happens. I also edited the logind.conf file but does not help: HandleLidSwitch=suspend HandleLidSwitchExternalPower=suspend HandleLidSwitchDocked=suspend If I do systemctl suspend or if I click on Sleep kde button, it goes to sleep, the question is why it does not go to sleep automatically? Also, if I suspend with systemctl suspend or via Sleep button, and then close the lid... if I reopen the lid, it automatically wakes up! So it appears that the bug is ONLY when I try to suspend... By now, the workaround is installing acpid, and force the suspend from there, here is the relevant part from /etc/acpi/handler.sh : button/lid) case "$3" in close) systemctl suspend logger 'LID closed' ;; open) logger 'LID opened' ;; *) logger "ACPI action undefined: $3" ;; esac ;; OBSERVED RESULT Suspend on lid close should be available on system settings EXPECTED RESULT No option for enabling suspend on lid close SOFTWARE/OS VERSIONS ArchLinux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2
Can you check the output of $ qdbus --system org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.LidIsPresent That's what we use for determining whether the computer has a lid or not.
.
(In reply to Kai Uwe Broulik from comment #1) > Can you check the output of $ qdbus --system org.freedesktop.UPower > /org/freedesktop/UPower org.freedesktop.UPower.LidIsPresent > > That's what we use for determining whether the computer has a lid or not. it says "false"
Well there you have it. Your hardware isn't properly supported by upower. Can you file a bug report with them? Thanks! https://gitlab.freedesktop.org/upower/upower/-/issues
I installed Plasma on this laptop several months ago and suspend on lid close was working... then I moved to GNOME for months and this week I went back again to Plasma, and have this bug.(In reply to Nate Graham from comment #4) > Well there you have it. Your hardware isn't properly supported by upower. > Can you file a bug report with them? Thanks! > > https://gitlab.freedesktop.org/upower/upower/-/issues I installed Plasma on this laptop several months ago and suspend on lid close was working... then I moved to GNOME for months and this week I went back again to Plasma, and have this bug. Should I report to them anyway?
Yes. Something could have regressed upstream in that time, and maybe GNOME has a hack to work around it that we don't have.
Also possible Gnome just uses logind for that. Didn't find any "had lid" property there but perhaps they rely on its implicit behavior.
(In reply to Kai Uwe Broulik from comment #7) > Also possible Gnome just uses logind for that. Didn't find any "had lid" > property there but perhaps they rely on its implicit behavior. weird fact: if I try to force to suspend it on lid close using logind, it does not work at all. I have to use acpid editing the its config to acutally suspend my laptop on lid close.
I FOUND THE REASON: I had a config in /etc/UPower/UPower.conf that didn't allow KDE to suspend. IgnoreLid=true . I have set it to "false" and now it WORKS. The reason why it was set on true (I completely forgot it) it was to workaround a suspend issue on external monitor that I had under GNOME. So, again, this is not KDE fault.
Alright, thanks for the update, glad you found it!
reverting back to upower 0.99.15 solves this issue on Arch Linux. 0.99.16has this issue