## System details

- Omarchy: 4.0.0-1 (upgraded from 3.8.x on 2026-08-23)
- Laptop: Lenovo LOQ 15AHP10
- CPU/iGPU: AMD Ryzen 7 250 with Radeon 780M
- dGPU: NVIDIA GeForce RTX 5060 Max-Q / Mobile
- NVIDIA driver: nvidia-open-dkms 610.57.04-1
- Kernel: linux-lts 6.18.45-1-lts
- Hyprland: 0.56.2-1
- Aquamarine: 0.14.0-2
- Quickshell: quickshell-git 0.3.0.r20.g28771c7-2
- Mesa: 26.1.8-1
- Battery: 60 Wh design, 60.71 Wh current full capacity, 10 cycles
- Displays: internal 1920x1080@60 on AMD iGPU, backlight 0%; external 1920x1080@60 over the laptop's NVIDIA-connected HDMI port

## What happened

Battery consumption increased sharply immediately after upgrading from Omarchy 3.8.x to Quattro 4.0, without changing the normal external-monitor setup.

Historical discharge sessions before the upgrade averaged:

- 2026-08-16: 8.8 W
- 2026-08-17: 9.8 W
- 2026-08-19: 9.4 W
- 2026-08-22: 9.6 W

The first post-upgrade session averaged 17.7 W and discharged from 100% to 10% in 2h58m. Subsequent light-use measurements have generally been 15-20 W.

A controlled five-minute light-use interval on Quattro consumed 1.74 Wh (60.27 -> 58.53 Wh), or 20.9 W average. `power-saver` was active throughout.

The NVIDIA GPU necessarily remains active because the external HDMI connector is physically routed to it. It draws about 5.6-6.0 W at 0% utilization and can rise to 9-12 W during light compositor activity. However, the same HDMI/external-monitor arrangement was used before Quattro, when total system consumption was around 9-10 W.

## Expected behavior

Power consumption with the same monitor topology and light workload should remain close to the pre-upgrade 9-10 W range, or at least should not nearly double after an upgrade.

## Checks and controlled tests

1. Confirmed battery health is good (full capacity slightly above design capacity).
2. Confirmed Omarchy selects `power-saver` after AC is disconnected.
3. Disabled a stale pre-Quattro root udev rule that could incorrectly force `balanced`; the high draw persisted with `power-saver` confirmed.
4. Removed unused 1Password integration and processes; no meaningful improvement.
5. Reduced the internal panel from 144 Hz to 60 Hz; its backlight is already 0%, and this did not explain the regression.
6. Briefly rolled back the complete matching NVIDIA package set from 610.57.04 to the cached pre-upgrade 610.43.03 version and rebooted. Consumption remained around 20 W and Hyprland CPU use increased, so all NVIDIA packages were restored to 610.57.04.
7. Stopped Quickshell while leaving Hyprland and the normal applications running. A 3.5-minute interval still averaged about 19.0 W, far above the old 9-10 W baseline. Quickshell was then restarted.
8. At idle, only Hyprland holds `/dev/nvidia0`; Chrome is not required to keep the NVIDIA GPU active.

## Upgrade boundary

Two bootable Snapper snapshots exist around the upgrade:

- Snapshot 1612: Omarchy 3.8.2 before the broad package upgrade
- Snapshot 1613: Omarchy 3.8.5 after the broad package upgrade but immediately before Quattro 4.0 was installed

They have not been booted for this test because `/home` is a separate writable subvolume and booting an old root against current Quattro user configuration could modify or invalidate the comparison.

Relevant changes at the boundary include Hyprland 0.55.4 -> 0.56.2, Aquamarine 0.12.1 -> 0.14.0, Waybar/Mako/Walker -> Quickshell, Mesa 26.1.4 -> 26.1.8, kernel/firmware updates, and iwd -> NetworkManager/wpa_supplicant.

There has also been occasional Bluetooth-headset audio stutter since the upgrade, which may or may not be related to the PipeWire/network-stack changes.

## Possibly related

- #7268: Quattro/NVIDIA shell rendering-loop behavior
- #1776: hybrid-GPU power management

Could there be a regression in the Quattro Hyprland/Aquamarine multi-GPU rendering path, output scheduling, or new power-management integration when an external display is attached to the NVIDIA GPU?

The full output of `omarchy-debug --no-sudo --print` was generated locally but not uploaded because it contains unrelated network and device identifiers. The relevant non-identifying system facts are included above.