But attaching i3status to it gives results of "BAT 69.56% 962:00", "974:00".
It is a big battery and it is discharging at just 1.94W, but hundreds of hours is, well.
A quick grep-around shows that i3status parses POWER_SUPPLY_TIME_TO_EMPTY_NOW as batt_info->seconds_remaining = abs(atoi(walk + 1)) * 60;.
drivers/power/supply/sbs-battery.c in linux 6.6.11 shows
static void sbs_unit_adjustment(struct i2c_client *client,
enum power_supply_property psp, union power_supply_propval *val)
{
#define BASE_UNIT_CONVERSION 1000
#define BATTERY_MODE_CAP_MULT_WATT (10 * BASE_UNIT_CONVERSION)
#define TIME_UNIT_CONVERSION 60
#define TEMP_KELVIN_TO_CELSIUS 2731
// ...
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW:
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG:
case POWER_SUPPLY_PROP_TIME_TO_FULL_AVG:
/* sbs provides time to empty and time to full in minutes.
* Convert to seconds
*/
val->intval *= TIME_UNIT_CONVERSION;
break;
and being off factor of 60 would put it at around 15.7h, which I'd be willing to buy (this is a Lenovo 300e Chromebook 2nd Gen MTK; I also have a Lenovo 300e Chromebook 2nd Gen, which is a similar Intel platform, and it gets around that when it hits <2W).
Additional survey of the non-staging results I got for grep -rI TIME_TO_EMPTY_NOW shows:
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: {
int percent = twl4030_madc_bat_voltscale(bat,
twl4030_madc_bat_get_voltage(bat));
/* in mAh */
int chg = (percent * (bat->pdata->capacity/1000))/100;
/* assume discharge with 400 mA (ca. 1.5W) */
val->intval = (3600l * chg) / 400;
break;
drivers/power/supply/twl4030_madc_battery.c lines 110-162/272 byte 4435/7515 59% (press RETURN)
(idk)
static int rn5t618_battery_tte(struct rn5t618_power_info *info,
union power_supply_propval *val)
{
u16 res;
int ret;
ret = rn5t618_battery_read_doublereg(info, RN5T618_TT_EMPTY_H, &res);
if (ret)
return ret;
if (res == 65535)
return -ENODATA;
val->intval = res * 60;
return 0;
}
drivers/power/supply/rn5t618_power.c lines 226-278/828 byte 6289/19922 32% (press RETURN)
(EMPTY_H * 60 => minutes)
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW:
ret = regmap_read(map, MAX17042_TTE, &data);
if (ret < 0)
return ret;
val->intval = data * 5625 / 1000;
break;
drivers/power/supply/max17042_battery.c lines 380-432/1225 byte 10904/33247 33% (press RETURN)
I have a Google Hana device with a battery which is
compatible = "sbs,sbs-battery"
. This yields a sysfs entry as/sys/class/power_supply/sbs-6-000b
:But attaching i3status to it gives results of "BAT 69.56% 962:00", "974:00". It is a big battery and it is discharging at just 1.94W, but hundreds of hours is, well.
A quick grep-around shows that i3status parses
POWER_SUPPLY_TIME_TO_EMPTY_NOW
asbatt_info->seconds_remaining = abs(atoi(walk + 1)) * 60;
.drivers/power/supply/sbs-battery.c
in linux 6.6.11 showsand being off factor of 60 would put it at around 15.7h, which I'd be willing to buy (this is a Lenovo 300e Chromebook 2nd Gen MTK; I also have a Lenovo 300e Chromebook 2nd Gen, which is a similar Intel platform, and it gets around that when it hits <2W).
Additional survey of the non-staging results I got for
grep -rI TIME_TO_EMPTY_NOW
shows:(idk)
(EMPTY_H * 60 => minutes)
(no clue)
(seconds)
(
time_to_empty
is unannotated – no clue)(no clue)
(labelled as minutes, divides by 60 so can only be minutes really)
which is an even split (with ~100% of x86 platforms using the APM driver and ~100% of ARM platforms using the SBS driver 🙈).
So i3status's scaling produces obviously-incorrect results by a factor of 60.