Waybar: Battery Pergentage Not Updating (sysfs doesn't update when battery percentage changes)

Created on 4 Sep 2018  路  12Comments  路  Source: Alexays/Waybar

The battery percentage doesn't update because inotify doesn't work on all sysfs-es.
I think polybar has polling until there is a inotify event.

I can try write a pull request at the weekend.

bug

Most helpful comment

For now i disabled that the timer will stop on first inotify event since there is some bugs :?

All 12 comments

Yeah, look when you have time, otherwise I'll look :)

Done in 9fae5efc069d19cb7437b84f7e638f785048a9e5

Thanks @Alexays!
I'm glad one of us found the time :)

Network signal strength also doesn't update, similar fix?

@Ranguvar Thanks for reminding me this, it's normal, there is no event for the signal strength, so i'll probably do an interval

Also - I just sat my laptop down, charged it from 92% to 99%, and waybar didn't update.
Let me know if I can help test in any way.

Yup battery updates are very irregular on my X230. No immediate reaction to plugging in charger either.

I've checked this on my machine. (Fedora 29, XPS 13 9370)

Plugging in the charger causes an update on the sysfs, which triggers this code:

https://github.com/Alexays/Waybar/blob/9fae5efc069d19cb7437b84f7e638f785048a9e5/src/modules/battery.cpp#L55-L63

which stops the timer. My machine then doesn't update the sysfs again until the charger is unplugged and plugged in.

I've made a hack which checks if "force-battery-timer" is marked as true in the config, if this is true then the timer is not stopped. This means that the battery icon is updated when sysfs updates occur and when the interval is reached.

I think a proper solution to this may need some discussion :)

The proper solution is to use udev, but it's not that simple as inotify :?

i3-status manages this by listening for updates / parsing '/sys/class/power_supply/BAT1/uevent' with a configuration option if you want multiple batteries. would that be a viable solution here?
EDIT: apparently reading that file causes an update to the battery widget, no idea why.
EDIT EDIT: just read the code for the battery module and I know understand the issue and why catting it fixes it, you are already watching that file. RTFC i guess..

I don't think we should rely on udev.

This is what ArchWiki has to say to this:

Note: Not all batteries report discharge events. Test by running udevadm monitor --property while on battery and see if any events are reported. You should wait at least 1% drop. If no events are reported and /sys/class/power_supply/BAT0/alarm' is non-zero then the battery will likely trigger an event whenBAT0/energy_now` drops below the alarm value, and the udev rule will work as long as the percentage math works out. Some laptops have an option for this disabled in BIOS by default.

I have also tested udev on my thinkpad and it doesn't trigger on discharge.

Maybe we could use the timer if specified, and if not use udev/inotify

For now i disabled that the timer will stop on first inotify event since there is some bugs :?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cinghiopinghio picture cinghiopinghio  路  4Comments

piu130 picture piu130  路  4Comments

0xdec picture 0xdec  路  4Comments

GeoDerp picture GeoDerp  路  5Comments

ddorstijn picture ddorstijn  路  5Comments