Couldn't reply because I ran out of responses yesterday, but here is what I wrote:
Yes, I understand that.
It seems to be focusing on power and then when it can't find anything it defaults to the lowest performance level to be cautious.
On computers that don't have a detectable power supply, I would think a good failsafe would be monitoring cpu temperatures and going from there. Basically, if temperature reaches high levels, then auto-cpufreq should underclock. In all other circumstances, if no psu is detected, the cpu should be on max performance mode.
I don't know how much the Garuda team is involved in the development of auto-cpufreq, but it could be interesting to see what could be done.
Thanks for the help, and keep me posted if something to fix the bug is sorted out!
It really feels rewarding to work on a technical issue with the community.
I've been using linux for almost an entire year now, but I've never really branched out and asked for help.
I contacted Adnan Hodzic on Twitter.
He had a look at your commit and has an issue with it on laptops.
I not much of a programmer, but I guess the else statement is too broad and it believe the laptop is charging whether it is plugged in or not.
Adnan Hodzic suggests running a command that determined the chassis type and then changing the setting from there.
As far as I know, that just means you need a variable for chassis type and then go
if laptop
get ac_state
if desktop
ac_state=true
Excuse my rudimentary example, just trying to get the idea across. I don't know how easy it is to run a shell command and then pull the variable it spits out into python.
Thanks again for helping out with this!
I'd figure I'd inform you here, because I bet you are more active checking here than on github
I might have gotten a little too ambitious and decided to write the code myself.
Although I have practically no coding skills, I think it turned out decent.
Check out my pull request and let me know what you think:
I had some difficulty testing it as a daemon, but it managed to compile.
I think it should work, but it's hard to tell until people who actually know how to test do so.
Never thought I would actually delve right in and try to solve it myself!! It's kind of fun, especially if my code is good enough to go on to help several other people.
Looks like my pull request got merged, now the package on the Chaotic-AUR needs to be recompiled with the change.
Adnan also says he will be making a new release (1.5.4) tomorrow or within a few days, but I think since it is a git-based package, it could be re-compiled without waiting for that.
Linux Kernel 5.9 vs 5.10 was a red herring, it wasn't related.
The real issue is that auto-cpufreq was not detecting a power supply on desktops and putting the cpu on "power saving" mode, which reduces clock speed.
I submitted a pull request to fix the issue on the auto-cpufreq github and it was merged.
The issue should be fixed on the Chaotic-AUR package within a matter of hours.
If you really need to fix the issue and you can't wait a few hours, the temporary solution is to run this command:
Those who disabled auto-cpufreq should be able to re-enable it after the package is updated, it is part of the suite of tools the Garuda team uses to enhance performance.
It doesn't theoretically, but in my experience I needed a reboot in order to see the full effects of disabling the daemon.
Shouldn't matter anyways, the issue is finally fixed!
It's pretty bad when a issue like this effects so many desktop users.
Since the past few days has been spent telling many people with issues to disable/mask auto-cpufreq, it might be good to make some sort of announcement letting people know that it is fixed and they can re-enable it.
Although, I think auto-cpufreq might re-enable after update anyways (I think I saw the update process doing that under the dragonized package, so maybe not for everyone). If it re-enables automatically upon update on every version of Garuda, then there may be no need, as people will update and not notice an issue