I3status-rust: Battery indicicator claims very bold times

[wucke13]

Once my battery is almost charged up, a quite huge number appears:

I'm not sure this is correct. I guess it seems to be the integer part of (2^(64)-1)/60. So probably something overflows/get's stuck in u64 max.

This is on i3status-rs 0.14.0

[ammgws]

@Thra11 seems related to #665?

[Thra11]

Can you try to determine which method it's using to determine the time to full? Which of the following exist in /sys/class/power_supply/<your battery identifier>?
time_to_empty
time_to_full
energy_full
charge_full
energy_now
charge_now
power_now
current_now

[Thra11]

It is possible that the charging current backs off as it approaches 100%. Can you confirm that, if left for a while, it does eventually charge up to 100%?

[wucke13]

• /sys/class/power_supply/BAT0:
  
  
  
  • alarm
  
  
  • capacity
  
  
  • capacity_level
  
  
  • charge_start_threshold
  
  
  • charge_stop_threshold
  
  
  • cycle_count
  
  
  • device -> ../../../PNP0C0A:00
  
  
  • energy_full
  
  
  • energy_full_design
  
  
  • energy_now
  
  
  • hwmon1
  
  
  • manufacturer
  
  
  • model_name
  
  
  • power
  
  
  • power_now
  
  
  • present
  
  
  • serial_number
  
  
  • status
  
  
  • subsystem -> ../../../../../../../../../class/power_supply
  
  
  • technology
  
  
  • type
  
  
  • uevent
  
  
  • voltage_min_design
  
  
  • voltage_now
  
  
• /sys/class/power_supply/BAT1:
  
  
  
  • alarm
  
  
  • capacity
  
  
  • capacity_level
  
  
  • charge_start_threshold
  
  
  • charge_stop_threshold
  
  
  • cycle_count
  
  
  • device -> ../../../PNP0C0A:01
  
  
  • energy_full
  
  
  • energy_full_design
  
  
  • energy_now
  
  
  • hwmon3
  
  
  • manufacturer
  
  
  • model_name
  
  
  • power
  
  
  • power_now
  
  
  • present
  
  
  • serial_number
  
  
  • status
  
  
  • subsystem -> ../../../../../../../../../class/power_supply
  
  
  • technology
  
  
  • type
  
  
  • uevent
  
  
  • voltage_min_design
  
  
  • voltage_now
  
  

Can you confirm that, if left for a while, it does eventually charge up to 100%?

Yes, indeed.

[Thra11]

So based on what properties are present, it should be taking

full = energy_full
fill = energy_now
usage = power_now

then doing ((full - fill) / usage) * 60.0 (±some unwrapping and casting). Are you able to get it into the bug state and read out the values of energy_full, energy_now and power_now?

[atheriel]

A quick fix for this (which has shown up in the past) would be to check of whether the differences are smaller than some tiny value before attempting any division.

[wucke13]

Funnily I wasn't able to reproduce this in the meantime. I don't know why. I will report back when I get the info, @Thra11 . Shall I close the issue, or let it open?

[ammgws]

Please leave it open

[greshake]

I think that interface is already a mess on the kernel side, we basically have to deal with a lot of quirks already coming from the battery vendors.. I think we should just add some basic sanity checks on the times, and just don't display anything above like a week.

[ammgws]

Unless I have misunderstood then #912 should resolve this for now.