You are not logged in.
I rather suspect that the situation is reversed and that an (unconfigured) acpid is running when things don't work.
Let's make sure acpid is actually entirely unconfigured.
cat /etc/acpi/events/anything /etc/acpi/handler.sh | curl -F 'file=@-' 0x0.st
Offline
I rather suspect that the situation is reversed and that an (unconfigured) acpid is running when things don't work.
Let's make sure acpid is actually entirely unconfigured.
cat /etc/acpi/events/anything /etc/acpi/handler.sh | curl -F 'file=@-' 0x0.st
Offline
That's the default config and won't do anything but logging the events.
The only way this makes sense if acpid is actually running when things "don't work" (because it's configured to just do nothing)
Have you tried to uninstall it (and reboot)?
Offline
That's the default config and won't do anything but logging the events.
The only way this makes sense if acpid is actually running when things "don't work" (because it's configured to just do nothing)
Have you tried to uninstall it (and reboot)?
I didn't uninstall, I just disabled the acpid service with systemctl and then restarted.
Offline
Yes, the point is to uninstall it to see what the results of that are.
"It works when it shouldn't and doesn't when it should" doesn't add up, there must be another factor.
Offline
Yes, the point is to uninstall it to see what the results of that are.
"It works when it shouldn't and doesn't when it should" doesn't add up, there must be another factor.
So, it went to sleep, but again, it's connected to power (meaning it's charging).
Yes I uninstalled it and rebooted, still in multiuser mode.
Offline
And does it still work if you unplug it from the charger?
Offline
And does it still work if you unplug it from the charger?
No.
Offline
Do asusd or supergfxd have any impact on this?
Does the lid get properly handled under KDE while you've on external power supply?
Offline
Do asusd or supergfxd have any impact on this?
Does the lid get properly handled under KDE while you've on external power supply?
Honestly I'm not sure.
Offline
It doesn't seem like it's going to sleep on KDE when connected to power.
Offline
Honestly I'm not sure.
Test. Disable the services and see whether that has impact on the behavior.
It doesn't seem like it's going to sleep on KDE when connected to power.
Did you check the KDE settings? It might just enter DPMS on power and S3 on battery (w/ the latter possibly still failing for unknown reasons)
The strategy here is to eliminate variables (test from the multi-user.target, no KDE) until you've established a functional behavior.
Then re-introduce more complexity (KDE)
Offline
Did you check the KDE settings? It might just enter DPMS on power and S3 on battery (w/ the latter possibly still failing for unknown reasons)
The strategy here is to eliminate variables (test from the multi-user.target, no KDE) until you've established a functional behavior.
Then re-introduce more complexity (KDE)
My KDE settings have it set to sleep when the lid is closed for all power modes. AC, Battery, and Low Battery/Power Save. I don't know what else to change. Not sure what variables I would eliminate.
Offline
Wait, I think I may have just figured out the variables. I'm assuming the variables are asusctl and supergfxctl.
Offline
The variable is KDE, the test object is asusctl/supergfxctl.
The test is to stop/disable those services and see whether the multi-user.target goes to sleep when you close the lid while running on battery.
Offline
I can't figure out how to disable asusd, as when I do sudo systemctl disable asusd.service, it claims it has no installation config, and it's not meant to be enabled or disabled by systemctl or something like that. I can start it just fine, but I cannot disable it.
Offline
I can't figure out how to disable asusd, as when I do sudo systemctl disable asusd.service, it claims it has no installation config, and it's not meant to be enabled or disabled by systemctl or something like that. I can start it just fine, but I cannot disable it.
So what I did is disabled supergfxctl, and stopped asusd, but then I restarted, which meant that I'd have to stop asusd again, and so when I stopped asusd, my laptop seemed to go to sleep on battery power underneath multi-user mode. Maybe that was the culprit, but I'd still like your reply.
This next part is unrelated to sleeping, but it is an issue I'm having with my laptop, so I thought I would just include it here.
Another thing I've been having as well is that my laptop will not restart and/or shutdown entirely like every other time. From some research (/oldroot couldn't be unmounted), it seems like it's an NVIDIA problem, which would somewhat make sense as this laptop does have NVIDIA graphics along with the AMD APU/iGPU, I tried to see if I could fix it (one solution said to download the proprietary nvidia drivers, which i did at one point, but the problem still persisted, so I went back to the open source drivers.), but I couldn't. I just wanted to put this here for people to be aware of another problem I'm having, but this one currently isn't a priority, and I may just end up creating a new forum thread about this problem.
Offline
I stopped asusd, my laptop seemed to go to sleep on battery power underneath multi-user mode.
The next step would be to try the behavior on KDE.
This next part is unrelated to sleeping
In general please keep it to one topic per thread to make the thread more useful for future readers w/ similar issues.
This might be https://bbs.archlinux.org/viewtopic.php … 2#p2162662 and I currently suspect that the cause of that is the nvidia_uvm module
But neither nvidia nor nouveau get loaded in the journal you previously posted (likely because of supergfxd) so if this is not it, you'd need to post some data on the issue (journal of previous boot, photo of stalled shutdown messages) and please open a new thread for that.
Offline
The next step would be to try the behavior on KDE.
Does not sleep on KDE.
Offline
grep -ri IgnoreInhibited /etc/systemd/logind.conf /etc/systemd/logind.conf.d/*.conf /run/systemd/logind.conf.d/*.conf /usr/lib/systemd/logind.conf.d/*.conf
(Plasma might disable that to be able to apply its on config. Powerdevil is configured to suspend on LID events)?
Is this actually plasma sepcific?
Does it work w/ an openbox or icewm session?
Offline
hmm
grep -ri IgnoreInhibited /etc/systemd/logind.conf /etc/systemd/logind.conf.d/*.conf /run/systemd/logind.conf.d/*.conf /usr/lib/systemd/logind.conf.d/*.conf
/etc/systemd/logind.conf:#PowerKeyIgnoreInhibited=no
/etc/systemd/logind.conf:#SuspendKeyIgnoreInhibited=no
/etc/systemd/logind.conf:#HibernateKeyIgnoreInhibited=no
/etc/systemd/logind.conf:#LidSwitchIgnoreInhibited=yes
/etc/systemd/logind.conf:#RebootKeyIgnoreInhibited=no
grep: /etc/systemd/logind.conf.d/*.conf: No such file or directory
grep: /run/systemd/logind.conf.d/*.conf: No such file or directory
grep: /usr/lib/systemd/logind.conf.d/*.conf: No such file or directory
(Plasma might disable that to be able to apply its on config. Powerdevil is configured to suspend on LID events)?
Yeah, always has, always will. (Powerdevil)
Is this actually plasma sepcific?
No clue
Does it work w/ an openbox or icewm session?
A what session? I've never heard of these before.
Edit: both of those (openbox and icewm) are for X11, Plasma now uses Wayland starting with version 6. Edit2: I did a web search on them, but that doesn't mean I've heard of them until now.
Last edited by ORIOLESFan02 (2024-04-08 00:17:02)
Offline
It doesn't seem like it's going to sleep on KDE when connected to power.
Oh yeah, for some reason, it now goes to sleep when connected to power on KDE.
Asusd is enabled and started, but supergfxd is still disabled.
Offline
Plasma *defaults* to wayland but still has an X11 session available - you might actually want to try that as well.
You can also run weston or sway, we just want to know whether you can suspend on battery by closing the lid while there's a GUI session that's not plasma.
You can also just try from the DM (SDDM, I guess)
Offline
You can also just try from the DM (SDDM, I guess)
Yeah I tried that yesterday (didn't get the chance to reply, my apologies), and it didn't sleep. So I'm not sure what to do at this point.
I'd also like to say that I re-enabled supergfxd because my computer was running extremely hot on Battery/DC power, so I had to enable it in order for it to stop getting that hot.
Offline
Did you test SDDM w/ or w/ supergfxd running?
Offline