You are not logged in.
Did you test SDDM w/ or w/ supergfxd running?
I actually cannot remember. I believe supergfxd was running, but I'll disable supergfxd for a second and respond back after I let it sleep with SDDM.
Offline
Disabled supergfxd and it went to sleep on SDDM. I just have to wait a few seconds after opening in order to close it so it can sleep.
Edit: currently on the power saver mode on KDE.
Last edited by ORIOLESFan02 (2024-04-09 15:36:07)
Offline
So
1. supergfxd inhibits the lid-triggered sleep (but only on battery)
=> https://gitlab.com/asus-linux/supergfxctl
Does it also inhibit "systemctl suspend"?
2. KDE inhibits the lid-triggered sleep (battery & external supply)
Double and triple re-check the KDE powerdevil config in systemsettings and try the behavior w/ a fresh user account.
Does it also inhibit "systemctl suspend"?
Offline
So
1. supergfxd inhibits the lid-triggered sleep (but only on battery)
=> https://gitlab.com/asus-linux/supergfxctl
Does it also inhibit "systemctl suspend"?2. KDE inhibits the lid-triggered sleep (battery & external supply)
Double and triple re-check the KDE powerdevil config in systemsettings and try the behavior w/ a fresh user account.
Does it also inhibit "systemctl suspend"?
1. I don't understand the question.
2. I have checked many... many times to make sure my settings are correct.
2a. I tried with a fresh user account, and it went to sleep on lid closed every time.
2b. I don't entirely understand the question, but i tried systemctl suspend on the fresh user account and it slept. Also, we figured out from before that doing systemctl suspend on my main account has worked and always has (yes, I just tried it again, it still works)
Offline
2. I have checked many... many times to make sure my settings are correct.
2a. I tried with a fresh user account, and it went to sleep on lid closed every time.
Still seems something specific to your main login config, though…
Move away ~/.config/powermanagementprofilesrc of your main user while NOT logged into a KDE session as such.
Offline
what do you mean by move away? like just move it out of ~/.config?
Offline
Anyways, I moved it out of ~./config if that's what you wanted me to do.
Offline
away = not there, you can also "rename" it to ~/.config/not.powermanagementprofilesrc, the main thing is that it's not in that location.
Did it have any impact on the LID behavior on KDE?
Offline
away = not there, you can also "rename" it to ~/.config/not.powermanagementprofilesrc, the main thing is that it's not in that location.
Did it have any impact on the LID behavior on KDE?
No impact on the lid behavior. It's still not sleeping when the lid is closed. On battery power
Offline
If it's not powerdevil check
systemd-inhibit --list
in- and outside a KDE session
Offline
$ systemd-inhibit --list
WHO UID USER PID COMM WHAT WHY >
NetworkManager 0 root 504 NetworkManager sleep NetworkManager needs t>
UPower 0 root 730 upowerd sleep Pause device polling >
PowerDevil 1000 dog 1094 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power even>
Screen Locker 1000 dog 863 kwin_wayland sleep Ensuring that the scre>
Offline
So powerdevil and screenlocker are KDE specific inhibitors, check the screensaver config and in doubt disable it.
Oh, and try KDE on X11, this could just be a bug in the wayland implementation.
Offline
I don't see a screen saver config. Edit: Unless you meant screenlocker config, but I don't know.
Last edited by ORIOLESFan02 (2024-04-12 17:41:09)
Offline
Also, it doesn't go to sleep under X11.
Offline
Hey, any other ideas? Thanks.
Offline
Did you disable the screenlocker and powerdevil and/or re-check their configuration?
We *know* that plasma inhibits the sleep actions to control them itself, so the answer will be in its config.
I don't use plasma, so I can't really tell you whether there're specific configss to address.
Offline
Did you disable the screenlocker and powerdevil and/or re-check their configuration?
We *know* that plasma inhibits the sleep actions to control them itself, so the answer will be in its config.I don't use plasma, so I can't really tell you whether there're specific configss to address.
Fair enough. I did not disable the screenlocker because I was given conflicting information. You at first said screensaver, but I wanted to make sure you meant screenlocker, which is why I didn't do it. I also didn't disable powerdevil since you're only telling me to do that now. Whenever I get the chance, I'll attempt to disable screenlocker and report back here.
From the time I'm posting this, it could be anywhere from 30 minutes from now, or 3 hours from now before I'm able to work on it.
Offline
So I disabled screenlocker, and it still doesn't sleep on lid closed.
Offline
What I am currently assuming is that it has to do with something in my home directory, because even re-installing arch (keeping the home directory), I still get the same problem. It could've been when I attempted to get my laptop to hibernate (which I disabled because I ran out of storage in the root directory) and using a script called "hibernator", but I'm not entirely sure.
Offline
Didn't we try the behavior w/ a fresh user account?
If not, you should do so, but it could end up being a systemic issue w/ KDE (on your device)
Offline
Didn't we try the behavior w/ a fresh user account?
If not, you should do so, but it could end up being a systemic issue w/ KDE (on your device)
We did.
Something else I tried was to delete the powerdevil config in ~/.config and that seemed to fix it. I believe the problem is finally solved. I will put solved on the thread.
Offline
For anyone else having this issue where the laptop does not sleep upon closing the lid:
In /etc/systemd/logind.conf, uncomment (and/or change) the line "HandleLidSwitch=suspend" to "HandleLidSwitch=ignore".
I also changed the line "HandleLidSwitchExternalPower=suspend" to HandleLidSwitchExternalPower=ignore".
It seems that these settings need to be explictly ignored rather than simply commented out (at least for powerdevil and KDE/Plasma).
*** This no longer appears to work, but neither does the solution posted above.
Last edited by SmilingTexan (2024-11-26 14:27:52)
Offline