Hi - I can't reproduce this on my own device, but to try to figure out what "level" of your system this is happening at - if you temporarily disable Powerdevil with `systemctl stop --user plasma-powerdevil.service` in a terminal window and then try to reproduce the issue, does it still happen?

If the issue continues after that step, then KDE code isn't involved here, and it's actually your device's firmware that's doing this under the hood.

If the issue stops when Powerdevil stops, then something in how it is interacting with your system is the cause and would likely need more investigation.

(Either way, after testing, you can re-enable Powerdevil again with `systemctl start --user plasma-powerdevil.service`)

(In reply to John Kizer from comment #1)
> Hi - I can't reproduce this on my own device, but to try to figure out what
> "level" of your system this is happening at - if you temporarily disable
> Powerdevil with `systemctl stop --user plasma-powerdevil.service` in a
> terminal window and then try to reproduce the issue, does it still happen?

Hmm, I don't have `plasma-powerdevil.service`, despite using KDE and having the KDE GUI to manage the power saving settings. I have `power-profiles-daemon.service` though, is it a separate project unrelated to KDE? If so, then I'm sorry, I'm new with Arch and KDE and I'm still confused about everything :) How does it relate to the GUI power saving GUI then?

Anyways, disabling `power-profiles-daemon.service` doesn't fix the issue.

In the meantime, I noticed one reliable trigger for this: closing the lid and then opening it again moves the setting to power saving, despite not having any action set in the power profile settings to happen on lid-close event. That's not the only trigger, sometimes it happens without closing the lid.

> If the issue continues after that step, then KDE code isn't involved here,
> and it's actually your device's firmware that's doing this under the hood.

Any idea/hints where to look next? There's nothing printed into dmesg or `power-profiles-daemon.service` service logs after such a switch.

I'm not an expert by any means, but I believe on Arch you need both the powerdevil package installed, and the plasma-powerdevil.service user service enabled and started, for Plasma to be able to successfully manage power consumption profiles. If you want to manage via KDE, then both should be setup (perhaps one of those recent updates somehow messed up the plasma-powerdevil service on your device?)

For context, power-profiles-daemon is an upstream project, and is the underlying service that manages the profiles and their application - take a look at https://wiki.archlinux.org/title/CPU_frequency_scaling#power-profiles-daemon and https://wiki.archlinux.org/title/KDE#Power_management for more info related to Arch.

Without powerdevil running, you should be able to narrow it down by testing out power-profiles-daemon directly with the command `powerprofilesctl set performance`. If running that, closing/reopening the lid, then checking again with the command `powerprofilesctl` shows the issue still happening, then it's some interaction between your device's firmware and power-profiles-daemon upstream.  Can you try that and see if the issue still reproduces?

(In reply to John Kizer from comment #3)
> I'm not an expert by any means, but I believe on Arch you need both the
> powerdevil package installed, and the plasma-powerdevil.service user service
> enabled and started, for Plasma to be able to successfully manage power
> consumption profiles. If you want to manage via KDE, then both should be
> setup (perhaps one of those recent updates somehow messed up the
> plasma-powerdevil service on your device?)

Ah, actually, I have `plasma-powerdevil.service`, I was running from root and didn't expect that the service won't be visible there at all, even with list-units.
The logs contain some errors:

```
Nov 28 00:26:10 laptop org_kde_powerdevil[1652]: org.kde.powerdevil: [DDCutilDetector]: Failed to initialize callback
Nov 28 00:26:11 laptop systemd[1253]: Started Powerdevil.
Nov 28 02:25:08 laptop org_kde_powerdevil[1652]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery conservation mode is not supported"
Nov 28 02:25:08 laptop org_kde_powerdevil[1652]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery conservation mode is not supported"
Dec 01 23:15:14 laptop org_kde_powerdevil[1652]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery conservation mode is not supported"
```

Doesn't seem related to the profile change, but I guess it explains why since recently my "stop charging at" settings got reset to 100%.

> For context, power-profiles-daemon is an upstream project, and is the
> underlying service that manages the profiles and their application - take a
> look at
> https://wiki.archlinux.org/title/CPU_frequency_scaling#power-profiles-daemon
> and https://wiki.archlinux.org/title/KDE#Power_management for more info
> related to Arch.

Thanks for the links!

> Without powerdevil running, you should be able to narrow it down by testing
> out power-profiles-daemon directly with the command `powerprofilesctl set
> performance`. If running that, closing/reopening the lid, then checking
> again with the command `powerprofilesctl` shows the issue still happening,
> then it's some interaction between your device's firmware and
> power-profiles-daemon upstream.  Can you try that and see if the issue still
> reproduces?

Yup, the issue still reproduces after doing that. I didn't know that the firmware could change the profile preset I chose in the OS, I thought this is a feature of the OS, not the firmware? Is this actually an ACPI feature? If so, then I guess I need to contact Lenovo support...

(In reply to redford from comment #4)
> Yup, the issue still reproduces after doing that. I didn't know that the
> firmware could change the profile preset I chose in the OS, I thought this
> is a feature of the OS, not the firmware? Is this actually an ACPI feature?
> If so, then I guess I need to contact Lenovo support...

Ah - yep, the catch there is the number of layers, starting from hardware, through firmware and down to userspace software, that all have to work in sync (the rest of that Arch Wiki article on CPU frequency scaling has a lot of good links and info if you want to dig really deeply on it!). The visible interface you see in a desktop environment like KDE (or Windows, for that matter) is the very surface layer, but if that surface layer tries to pass along a command that isn't functioning properly at a lower layer, it just won't work.

(In an analogous way, our family purchased a laptop once - ironically, also Lenovo - on which the pre-configured Windows installation couldn't put the laptop to sleep. We came to find out that the Windows equivalent of power-profiles-daemon was calling for the firmware to use a sleep state that it didn't outright reject, but couldn't successfully set, so the machine just hard-froze - we had to do some work in the Windows Terminal to force it to only attempt certain sleep states)

In this case, it might be helpful to check around with your device's model number to see if there are any generally known power-state issues with the device. You could also try booting from a live USB for another distribution, like Ubuntu or Fedora, to see if they exhibit the same behavior - if not, then it may be something that is funky in how your specific Arch setup has come together, or in how power-profiles-daemon is interacting with it. Fedora 41 (which comes in a very well-maintained KDE Spin), for example, uses tuned instead of power-profiles-daemon, which might produce different results.

Best of luck!

(In reply to John Kizer from comment #5)
> Ah - yep, the catch there is the number of layers, starting from hardware,
> through firmware and down to userspace software, that all have to work in
> sync (the rest of that Arch Wiki article on CPU frequency scaling has a lot
> of good links and info if you want to dig really deeply on it!). The visible
> interface you see in a desktop environment like KDE (or Windows, for that
> matter) is the very surface layer, but if that surface layer tries to pass
> along a command that isn't functioning properly at a lower layer, it just
> won't work.

I see, thanks! I submitted a report to Lenovo, I suspect it's related to the last BIOS/EC update.

> (In an analogous way, our family purchased a laptop once - ironically, also
> Lenovo - on which the pre-configured Windows installation couldn't put the
> laptop to sleep. We came to find out that the Windows equivalent of
> power-profiles-daemon was calling for the firmware to use a sleep state that
> it didn't outright reject, but couldn't successfully set, so the machine
> just hard-froze - we had to do some work in the Windows Terminal to force it
> to only attempt certain sleep states)

Heh, I once went through an ACPI issue on an old ThinkPad x230 running Xen, turned out to be a bug in Xen: https://old-list-archives.xen.org/archives/html/xen-changelog/2019-09/msg00301.html. The BIOS there is disabling NX by default, Xen forced it back on during boot, but forgot to do the same when waking from suspend and thus segfaulting when trying to use it.
I hope this time I won't end up debugging Linux and ACPI tables, but we'll see :)

> In this case, it might be helpful to check around with your device's model
> number to see if there are any generally known power-state issues with the
> device. You could also try booting from a live USB for another distribution,
> like Ubuntu or Fedora, to see if they exhibit the same behavior - if not,
> then it may be something that is funky in how your specific Arch setup has
> come together, or in how power-profiles-daemon is interacting with it.
> Fedora 41 (which comes in a very well-maintained KDE Spin), for example,
> uses tuned instead of power-profiles-daemon, which might produce different
> results.
> 
> Best of luck!

Thanks! I'll see what Lenovo says and probably debug this a bit myself. Will let you know if there's anything related to Powerdevil here.

One thing which would be useful though, would be to indicate in the GUI that the battery conservation settings change failed - I see "org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery conservation mode is not supported"" in the service logs, but the GUI showed that everything succeeded and it was quite confusing to me.

(In reply to redford from comment #6)
> One thing which would be useful though, would be to indicate in the GUI that
> the battery conservation settings change failed - I see "org.kde.powerdevil:
> org.kde.powerdevil.chargethresholdhelper.getconservationmode failed "Battery
> conservation mode is not supported"" in the service logs, but the GUI showed
> that everything succeeded and it was quite confusing to me.

Ah, so the interface is indicating that it's active, but it's in fact not so? That's definitely a good discrete bug report if you could file that please!

For reference, I did see there was a lot of maneuvering required to get that overall feature in place here - https://invent.kde.org/plasma/powerdevil/-/merge_requests/248 - so it's still relatively new and your experience might help get things in a better spot for everyone!

Thanks,

(In reply to John Kizer from comment #7)
> Ah, so the interface is indicating that it's active, but it's in fact not
> so? That's definitely a good discrete bug report if you could file that
> please!
> 
> For reference, I did see there was a lot of maneuvering required to get that
> overall feature in place here -
> https://invent.kde.org/plasma/powerdevil/-/merge_requests/248 - so it's
> still relatively new and your experience might help get things in a better
> spot for everyone!
> 
> Thanks,

Yeah, this whole applet seems completely broken and unusable if I'm to be honest ;)

I just submitted all the bugs in it I remembered:
https://bugs.kde.org/show_bug.cgi?id=497080
https://bugs.kde.org/show_bug.cgi?id=497084
https://bugs.kde.org/show_bug.cgi?id=497085
https://bugs.kde.org/show_bug.cgi?id=497086

Will be happy to help with debugging these!