OpenRiot v7.9.53 — The Machine Counts Minutes, Not Percent
“The battery said 20%. You had 45 minutes. The battery said 10%. You had three minutes. The percentage was lying to you — it always was. A percentage is a guess scaled to a battery that degrades. A minute is a measurement. We switched from the guess to the measurement. While we were in there, we taught the compositor to stop redrawing the entire screen sixty times a second. The machine is quieter. The battery tells the truth. The Turing Police would call one a ‘power management heuristic’ and the other a ‘rendering optimization.’ We call them both fixing things that were wrong.” — The OpenRiot Crew, v7.9.53
Release Overview
The battery tracker stops lying about how much time you have left. Alerts fire at 20, 15, 10, and 5 minutes remaining — actual clock time, not a percentage that means nothing when your battery is two years old. The compositor learns to use damage tracking and VSync, cutting pointless frame redraws.
Total changes: battery alerts go time-based, picom CPU fixes.
🔋 Battery: Minutes, Not Percent
The old alerts fired at 20% and 10%. A percentage is a ratio of current charge to design capacity. Design capacity degrades. A battery at 20% might have 45 minutes left when it’s new, or 3 minutes left when it’s old. The percentage was telling you the same number in both cases. It was lying.
The new alerts fire at:
Minutes Remaining Alert
20 "Less than 20 minutes remaining!"
15 "Less than 15 minutes remaining!"
10 "Less than 10 minutes remaining!"
5 "Less than 5 minutes remaining!" (critical)
Real clock time, measured by apm -m. The machine knows exactly
how many minutes are left. It was just asking the wrong question.
Lucas spotted this. Four numbers — 20, 15, 10, 5 — and the machine starts telling the truth. The fix was impossibly simple. Impossibly So.
Alerts reset when you plug in or when remaining time climbs back above 20 minutes. No duplicate notifications. No spam. Just the truth, spoken at the right moments.
--battery-test now takes <minutes> instead of <percent>:
openriot --battery-test 12
The Turing Police would use a linear degradation model and call
it “predictive analytics.” We used apm -m and called it reading
the sensor.
🖥️ Picom: Damage Tracking and VSync
The compositor was redrawing the entire screen every frame. Every
frame. use-damage = false meant “repaint everything, always.”
On a 1920x1080 display, that’s two million pixels per frame, sixty
times a second, for a terminal window that changed one character.
Two lines changed:
use-damage = true # Only redraw changed regions
vsync = true # Sync to display refresh rate
The compositor now only repaints what actually changed. VSync prevents it from rendering frames faster than the display can show. The result is less CPU, less GPU, less heat, and no visible difference in quality.
The Turing Police would call this “damage region optimization.” We call it not redrawing the entire screen when nothing moved.
🧾 Files Changed
| File | Change |
|---|---|
source/battery/battery.go |
Battery alerts switch from percentage |
| (20%, 10%) to time-based (20min, 15min, | |
10min, 5min). Get() now captures |
|
minutes from getFullStatus(). |
|
TestNotify() accepts minutes param. |
|
source/commands/commands.go |
--battery-test accepts <minutes> |
instead of <percent>. Usage updated. |
|
config/picom.conf |
use-damage = true (was false), |
vsync = true (was false) |
|
install/openriot |
Compiled binary |
🗣️ Final Words
“The battery was telling you a ratio and calling it time. The compositor was painting every pixel and calling it a frame. The machine knew the minutes. The machine knew the damage. It was just asking the wrong questions. We asked better ones. Lucas handed us four numbers and the battery started telling the truth. The fix was impossibly simple. Impossibly So. The Turing Police would say ‘two minor configuration changes.’ We say the battery stopped lying and the compositor stopped screaming into the void.” — The OpenRiot Crew, v7.9.53