Is your feature request related to a problem? Please describe.

On my machine, the hardware exposes charge_now on the first boot, and after waking up from suspend, only energy_now is exposed. This makes polybar start watching charge_now, and it then fails to attach its inotify watch when this file has disappeared.

Why does polybar need this feature?

This problem happens in the Thinkpad x220 and some other related models, and is very difficult to workaround without patching either the kernel or polybar. Patching polybar is accessible to me, working around this problem in the kernel is harder. The x220 is still a relatively popular laptop, and it would be nice if polybar could be used on it out-of-the-box.

Describe the solution you'd like

When the inotify watch fails to reattach, we could "reset" the battery module and make it scan for sysfs files again. This wouldn't need any config option, except maybe to limit the amount of resets.

Describe alternatives you've considered

• patching the kernel and workaround the bug there (harder to patch, and if the source problem is in the battery module and not in its driver, it might not even be accepted).
• entirely disabling the battery module, and using a script to show the battery status (not very practical)
• restarting polybar each time I wake the laptop from suspend (this is the current solution I'm using)

Additional context

• I would totally understand if it's deemed not useful for polybar to handle such battery controllers. Restarting polybar is not a too bad workaround. This is why I submitted this as a feature request and not as a bug.
• However, this "kind" of issue could happen in any module, so :
• I'm submitting this issue so that it can be considered whether to have some "reset" logic for some modules. This would make sense for modules that have an "initialization" sequence, so that this initialization sequence can be triggered again.