Laptop batteries don’t last forever. Heat, charge cycles and charging speed all take their toll. Yet for years a quiet component in the Linux desktop stack quietly pushed some systems toward faster degradation without users realizing it.
That changed with UPower 1.91.3. Released just days ago, the update corrects a behavior that caused the daemon to switch battery charging to “fast” mode whenever a user disabled a charge-threshold setting. The result? Unnecessary thermal stress on cells that shortens overall lifespan. Short. Simple. And now fixed.
UPower serves as the central abstraction layer for power devices across Linux desktops. It enumerates batteries, AC adapters and other sources. It listens for events. It supplies history and statistics to tools like GNOME Settings, KDE Power Management and countless scripts. Any application can query the org.freedesktop.UPower service over the system message bus. The project once carried the name DeviceKit-power. It stepped in after HAL fell out of favor. Its code, originally shaped by Richard Hughes between 2007 and 2010, still underpins much of how modern distributions report and manage battery health. https://upower.freedesktop.org/
Two months before the new release a bug report landed on the project’s GitLab instance. It described how disabling the battery charging threshold on certain laptops caused UPower to alter the default charge type from “standard” to “fast.” Users expected the system to revert to normal behavior. Instead it accelerated charging, generating excess heat. Fast charging is known to degrade the battery over time due to excess heat generated causing thermal stress leading to damaged battery cells over time and degraded performance. The report highlighted a real risk for anyone who experiments with thresholds to extend battery life. https://www.phoronix.com/news/UPower-1.91.3
Developer Armin Wolf stepped in. His merge request adjusted the device-battery handling logic so the daemon now prefers “standard” charging when the threshold feature is turned off. The patch landed cleanly. It forms the centerpiece of version 1.91.3. A handful of additional bug fixes accompany it, though none carry the same weight for everyday users worried about battery longevity. The release notes appear on the project’s GitLab page. https://gitlab.freedesktop.org/upower/upower/-/releases/v1.91.3
This isn’t the first time UPower adjustments have touched battery behavior. Earlier versions addressed excessive disk writes, high CPU usage during monitoring and incorrect guesses about whether a battery should act as a power supply. In 2024 the related Power Profiles Daemon gained automatic battery-state awareness, letting it scale CPU performance differently on AC versus battery power. Each tweak reflects the same underlying truth: power management on Linux remains a collection of interlocking pieces that must behave predictably across hardware from Framework laptops to ThinkPads to System76 machines.
Framework laptop owners saw this firsthand earlier this year. A prior UPower update caused battery status to report incorrectly, making discharging appear as disconnection. The issue affected Arch Linux and Fedora users alike. It was resolved in version 1.90.9. The community discussions on the Framework forum and Reddit threads revealed how sensitive these daemons have become as vendors expose more charging controls through ACPI and kernel drivers. One user noted the problem disappeared after rolling back to an earlier package. Another confirmed the fix restored proper behavior on Fedora 41. Such reports underscore why a seemingly small logic change in 1.91.3 matters. https://community.frame.work/t/upower-issues-with-framework-laptops/67217
Charging thresholds themselves have grown more common. Modern laptops from Dell, Lenovo and Framework let users cap maximum charge at 80 percent or lower to reduce calendar aging. UPower reads these limits from udev properties and hwdb entries. The default in many distributions sets a 75-80 percent window. Yet the daemon only applies those limits when the EnableChargeThreshold D-Bus method is called. If that feature is later disabled, the system should not silently switch to fast charging. Until 1.91.3 it sometimes did. The fix restores expected behavior. Users who never touch thresholds remain unaffected. Those who do gain peace of mind. https://unix.stackexchange.com/questions/803869/upower-how-to-enforce-charging-start-end-thresholds
Distributions will roll out the update soon. Arch Linux already carries 1.91.2 and will likely follow with 1.91.3 quickly. Debian, Fedora and Ubuntu derivatives maintain their own packages, often with slight delays. System administrators and desktop users alike should watch for it. A single line in the release announcement belies the years of accumulated technical debt it resolves. Battery chemistry hasn’t changed. Heat still damages lithium-ion cells. But the software that controls how that heat is generated just became a bit smarter.
And the broader picture? Linux power management continues to mature. Tools like upower command-line client let users inspect devices directly. Power Profiles Daemon adjusts governor settings automatically. Kernel drivers expose more granular controls than ever. Yet the stack remains complex. One daemon’s assumption about default charge rates can undermine hardware designed for longevity. The 1.91.3 release shows the community responding. It also highlights how much still depends on attentive maintainers like Armin Wolf who notice regressions two months after they appear.
Users can test the change themselves once installed. Run upower -e to list devices, then upower -i on the battery object. Watch the charge type property before and after toggling thresholds through desktop settings. The difference should now align with expectations. No more surprise fast-charge mode. No more unintended acceleration toward earlier replacement. For an industry that prizes efficiency and sustainability, this counts as progress. Quiet progress. But real.
Recent coverage echoes the same themes. Phoronix first broke the story on July 3, 2026, framing the fix around battery health. Other sites picked it up within hours, repeating the core warning about fast charging’s thermal cost. No major new features arrived in this point release. The focus stayed narrow and practical. That restraint may explain why the change feels significant. It corrects a misstep rather than adding bells and whistles. In open-source maintenance, such corrections often deliver the highest return.
WebProNews is an iEntry Publication