Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
Power panel shows ~-1100W discharge: firmware reports battery current as 16-bit two's complement, sysfs rate overrides UPower
Reported by forcey · filed Sep 24, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Intel Core Ultra X7 358H, Intel Arc B390 (Panther Lake), MSI Prestige 16 AI+ C3MTG (BIOS E2622IMS.11A), kernel 7.2.5-3-omarchy, Omarchy 4.0.4-1
What's wrong?
When the laptop runs on battery, the power panel shows a discharge rate of about -1130 W. The real draw is about 8 W.
Cause: the firmware reports the battery current as a 16-bit two's-complement value, and the kernel reads it as unsigned:
/sys/class/power_supply/BAT1/current_now: -65041000 (µA)
/sys/class/power_supply/BAT1/voltage_now: 17343000 (µV)65536 − 65041 = 495, so the actual discharge current is about -495 mA (0.495 A × 17.34 V ≈ 8.6 W). The kernel's ACPI battery driver has a workaround for buggy DSDTs that report negative 16-bit rates. When that workaround fires, it logs (dis)charge rate invalid. That message never appears in this boot's log, so the workaround isn't firing on this machine. There's no power_now file.
UPower handles it fine:
energy-rate: 7.48699 W
time to empty: 10.0 hoursomarchy-battery-status deliberately replaces UPower's energy-rate with sysfs current_now × voltage_now (to avoid UPower's lag), so the broken firmware value goes straight into the panel.
This is the same class of problem as #12735 and #6895: sysfs overrides a good UPower rate.
Suggested fix: sanity-check the sysfs-derived rate and fall back to UPower's energy-rate when the value is implausible. For example: |rate| greater than ~200 W, or more than a few times UPower's rate. btop shows the same bogus value, so the root bug is in the firmware/kernel. The panel can still guard against it cheaply.
Workaround: clone omarchy.power and point it at a copy of omarchy-battery-status with the sysfs override block removed.
View raw text
### System details Intel Core Ultra X7 358H, Intel Arc B390 (Panther Lake), MSI Prestige 16 AI+ C3MTG (BIOS E2622IMS.11A), kernel 7.2.5-3-omarchy, Omarchy 4.0.4-1 ### What's wrong? When the laptop runs on battery, the power panel shows a discharge rate of about **-1130 W**. The real draw is about 8 W. **Cause:** the firmware reports the battery current as a 16-bit two's-complement value, and the kernel reads it as unsigned: ``` /sys/class/power_supply/BAT1/current_now: -65041000 (µA) /sys/class/power_supply/BAT1/voltage_now: 17343000 (µV) ``` 65536 − 65041 = 495, so the actual discharge current is about -495 mA (0.495 A × 17.34 V ≈ 8.6 W). The kernel's ACPI battery driver has a workaround for buggy DSDTs that report negative 16-bit rates. When that workaround fires, it logs `(dis)charge rate invalid`. That message never appears in this boot's log, so the workaround isn't firing on this machine. There's no `power_now` file. UPower handles it fine: ``` energy-rate: 7.48699 W time to empty: 10.0 hours ``` `omarchy-battery-status` deliberately replaces UPower's `energy-rate` with sysfs `current_now × voltage_now` (to avoid UPower's lag), so the broken firmware value goes straight into the panel. This is the same class of problem as #12735 and #6895: sysfs overrides a good UPower rate. **Suggested fix:** sanity-check the sysfs-derived rate and fall back to UPower's `energy-rate` when the value is implausible. For example: |rate| greater than ~200 W, or more than a few times UPower's rate. btop shows the same bogus value, so the root bug is in the firmware/kernel. The panel can still guard against it cheaply. **Workaround:** clone `omarchy.power` and point it at a copy of `omarchy-battery-status` with the sysfs override block removed.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 19:38 UTC