https://bugs.kde.org/show_bug.cgi?id=467797
Jakob Petsovits <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|WAITINGFORINFO |UPSTREAM Status|NEEDSINFO |RESOLVED --- Comment #8 from Jakob Petsovits <[email protected]> --- Also cannot reproduce on my ThinkPad X1 Carbon Gen 7. I'll go back to my initial assumption: > To be honest, this sounds more like a system issue or perhaps an issue with > the PowerDevil charge threshold helper. So let's try to figure out what's happening. I'm noticing something weird in your sysfs output: > But if I do "ls charge_* && cat charge_*" in "/sys/class/power_supply/BAT0/" > immediately after what you see in the attached video I get: > > .rw-r--r-- 4,1k root 21 Aug 17:36 charge_behaviour > .rw-r--r-- 4,1k root 21 Aug 17:30 charge_control_end_threshold > .rw-r--r-- 4,1k root 21 Aug 17:30 charge_control_start_threshold > .rw-r--r-- 4,1k root 21 Aug 17:36 charge_start_threshold > .rw-r--r-- 4,1k root 21 Aug 17:36 charge_stop_threshold > [auto] inhibit-charge force-discharge > 70 > 70 > 20 > 20 If the order of printed files (with `cat`) is the same order as the one that `ls` gives you, then this is seriously broken. If I set 70/20 on my laptop, it looks like this: > $ ls -l charge_* && cat charge_* -rw-r--r-- 1 root root 4096 Oct 16 13:27 charge_behaviour -rw-r--r-- 1 root root 4096 Oct 16 13:36 charge_control_end_threshold -rw-r--r-- 1 root root 4096 Oct 16 13:36 charge_control_start_threshold -rw-r--r-- 1 root root 4096 Oct 16 13:27 charge_start_threshold -rw-r--r-- 1 root root 4096 Oct 16 13:27 charge_stop_threshold [auto] inhibit-charge force-discharge 70 20 20 70 ``` Notice how in your example, `charge_stop_threshold` at the very bottom holds a value of 20 when it should be 70, and more importantly, `charge_control_start_threshold` holds a value of 70 when it should be 20. The kernel introduced `charge_control_end_threshold` as newer name for the old `charge_stop_threshold`, as well as charge_control_start_threshold` as newer name for the old `charge_start_threshold`. Each pair should always return the same value, but in your case, it doesn't. So to me, this suggests that the kernel has a bug for your specific hardware that causes the firmware settings to get exposes by the wrong sysfs file. I figure that all of the other UI confusion is caused by the same underlying root cause. Please report this bug to the Linux kernel. You can also verify this purely on the command line without involvement by Plasma (I figure that's their preferred method for reproductions) by writing the value manually, e.g.: > echo 70 | sudo tee charge_control_end_threshold > echo 20 | sudo tee charge_control_start_threshold This is what Plasma's charge threshold helper is doing internally, so it should accurately capture the behavior of the Power Management settings page. Except for the fact that PowerDevil and the applet won't know about the change until they restart. Feel free to reopen this bug if somehow it turns out not to be a kernel bug after all. -- You are receiving this mail because: You are watching all bug changes.
