[RESPONDED] Help with reliable detection of stable external power source

I’m running a 12th Gen Intel FW 13 with Linux Mint 21.1 Cinnamon and kernel 6.1.0-1022-oem. The kernel is probably not a factor.

Whenever the FW is drawing power through one of its USB-C ports, the battery cycles between charge and discharge. NOTE: I’ve only used the stock FW power supply so the behaviour might be different with other power sources.

Whatever the Mint and/or Cinnamon devs are doing to detect whether the FW is on battery or AC power is unreliable. It seems that whenever the battery is discharging, whether connected to an external power source or not, the power management sub-system selects the “on battery” policy set for system state management.

I have (and want) quite aggressive on-battery policies. Consequently the system often puts itself to sleep while in use and connected to a stable external power supply.

I’d like to hack the state detection mechanism used by the power manager so that it can accurately and repeatedly detect when a stable external power supply is connected irrespective of whether the battery is charging or discharging.

Any clues as to where I should be looking are welcome.

I recall reading a post or posts related to this before but my search-fu isn’t able to unearth them. If you can direct me to other relevant threads, that too will be welcomed.

Dino

That sounds like the problem I’m having with my 13th gen intel. By any chance have you got the battery chagre limit enabled in the bios? If you do try setting it to 100 percent and see if it stops.

I’m currently debugging my issue with support so might be worth sending them an email.

Hi @truffaldino,

Excellent detail, really appreciate that as it helps me tremendously. Does it resemble what is described below?

This is also 12th gen.

Something I’d like to do so I can try to reproduce and if I can, get this to the engineering team.

  • Does battery cycles between charge and discharge appear on a Live ISO of Mint and of Ubuntu 22.04? Not asking you to reinstall anything at this point, I suspect this is something else.

  • What percentage of charge are you at when this happens? 99% or something lower like 80s, etc?

  • Does this happen with different expansion bays as well?

  • In the same expansion bay as it was first discovered, have you tried another USB-C expansion card for charging?

  • What we want to do is to be able to determine if this is an OS, hardware/expansion card/power brick/etc.

Hello and thanks for your contribution. I have no charge limit set in the firmware (i.e. the battery should recharge to 100%).

I don’t think it’s appropriate for me to engage with FW support. I have chosen to run an unsupported configuration. While this is annoying, it’s far from a show stopper and is most likely to hinge on two valid but subtly different interpretations of a poorly-documented standard or convention.

Dino

Thanks for those questions @Matt_Hartley. Will do my homework and update this post when I have answers.

Dino

1 Like

I’d be surprised if this is very distribution-dependent, since the fundamental information on this would come from the kernel. I have an 11th gen and there with an 80% charge limit configured I see the system toggle between charging and not charging when the battery is at its limit (even though the led remains white, so the embedded controller apparently mainly looks at whether the battery charge is at/near its set limit. It doesn’t affect power profiles, though. If you’re worried about whether the system “forgets” that there’s even a power supply connected, perhaps check the presence of /sys/class/power_supply/ACAD or something similar and/or /sys/class/power_supply/ACAD/online.

If your system is making profile decisions based solely on the value of /sys/class/power_supply/BAT1/status equalling charging or not, then that should probably be fixed, but I don’t think that the currently common linux tools do this.

Just a reminder as we need to 100% determine this is not happening as described:

  • Does battery cycles between charge and discharge appear on a Live ISO of Mint and of Ubuntu 22.04? Not asking you to reinstall anything at this point, I suspect this is something else.
  • What percentage of charge are you at when this happens? 99% or something lower like 80s, etc?
  • Does this happen with different expansion bays as well?
  • In the same expansion bay as it was first discovered, have you tried another USB-C expansion card for charging?
  • What we want to do is to be able to determine if this is an OS, hardware/expansion card/power brick/etc.

Hey Matt, I need to manage your expectations. I’ll need several hours of testing spread over multiple days to answer your questions. Since I can’t do my job while running a Live ISO, I expect it might take a week or too before I can complete the observations you want.

I’m grateful for your help but as I said at the get-go, the issue is annoying but far from a show stopper.

Dino

No expectations here - take your time, just keeping the communication open as others comment come up and push back my previous comment. :slight_smile:

1 Like

Months have passed during which time I have observed the subtle differences between the Ubuntu 22.04 and Mint Cinnamon 21.1 DE power manager behaviour past the point of being healthy. I’ve created a script to log that behaviour. Happy to share in the unlikely event that anyone is remotely interested.

My conclusion is that there is a mechanism that I’ve yet to discover that informs both upowerd and the DE’s power manager (e.g. csd-power under Cinnamon) about the state of the external supply and of the battery. That mechanism behaves differently on the two systems (running on the same 12th Gen Framework 13).

From my investigation I have determined that:

  • Cinnamon’s power manager makes decisions that lead to such things as screen power off and system suspension based solely on whether the battery is charging or discharging. It doesn’t seem to care whether there is a stable external supply available.
  • Under Cinnamon, upowerd reports the Framework battery as frequently switching between discharging and fully-charged. The length of time in each of these states is variable and can be quite short. Critically it can remain in the discharging state (while simultaneously ignoring that an external power source is available) for longer than the inactivity suspension trigger.

The Ubuntu behaviour is arguably correct although I do not care to use it.

From a philosophical standpoint, this has proven to be an excellent example of how far linux as desktop has come and why so many people believe it’s still not ready for prime time.

Dino

1 Like

The final word: fixed!

I’ve built a new csd-power plugin based on the most-recent sources. The function csd-power-manager.c:system_on_battery() has been refactored to eliminate unwanted behaviour.

It now works precisely as I expect: it does not switch power manager profiles to “on battery power” whenever the BMS choses to discharge the battery while it is connected to a stable external power source.

Hit me up if you want a patch (remember those?). If you’d rather have the whole file, I probably need to give you the complete tarball so that I comply with the GPL.

Dino

1 Like