Implementing charging threshold control in GNOME

[cyberphantom52 (Inam Ul Haq)]

Recently a mockup was posted for the power section in GNOME Settings here. The mockup has an option to limit the charging to a certail level to prolong battery health. While discussing the technical details on GNOME Settings matrix. We realised that the behaviour is going to be inconsistent across different machines based on the following points:

• All OEMs don’t provide a way to set a charge threshold in the first place and even those who do keep the feature reserved for the “premium” line of products making it inconsistent even when considering a single OEM.

• The implementation varies across different OEMs, there’s no universal way to set a charging threshold. The implemtation comes from out of tree modules and varies from manufacturer to manufacturer.

• The threshold is not always configurable, like Lenovo allows enabling/disabling threshold but it’s locked around 80% and not changable, while as ASUS allows setting any threshold.

The information about charging thresholds for different devices that we have collected so far can be seen here

A possible alternate approach could be manually exposing ACPI methods for each vendor manually instead of using the interface that the modules provide.

[garnacho (Carlos Garnacho)]

Hi,

From a quick grep to the kernel code, it seems that most platform drivers implementing battery charge control do agree on:

• /sys/class/power_supply/<supply_name>/charge_control_start_threshold
• /sys/class/power_supply/<supply_name>/charge_control_end_threshold

to expose the feature. I would advise to check for those and ignore outliers (e.g. ideapad, from your list) and non-conforming out-of-tree drivers.

This somewhat sounds to me like UPower territory.

@cyberphantom52

We realised that the behaviour is going to be inconsistent across different machines based on the following points:

• All OEMs don’t provide a way to set a charge threshold in the first place and even those who do keep the feature reserved for the “premium” line of products making it inconsistent even when considering a single OEM.

There is also old hardware to cater for. I think all features need to be tested independently (e.g. a stop threshold does not imply the hw also handles a start threshold).

@cyberphantom52

A possible alternate approach could be manually exposing ACPI methods for each vendor manually instead of using the interface that the modules provide.

Please don’t do that :). In the worst case that we eventually needed to handle vendor specifics to achieve large adoption, going lower level is only going to multiply the cases to handle by adding models/revisions to the mix.

Cheers,
Carlos