Screen Dimming After 30 Seconds on Ubuntu 24.04 – Debugging and Fix
System: Lenovo Legion Pro 5-16 / Ryzen 9 8945HX / Ubuntu 24.04 Noble / GNOME 46
Symptom: Built-in display dims automatically after exactly 30 seconds of keyboard/mouse inactivity, even with all power-saving settings disabled.
Disclaimer
The text below was partially prepared by AI/LLM (Claude Sonnet), which also helped with the debugging process.
TL;DR
On Ubuntu 24.04 with GNOME 46, the screen dims after 30 seconds of inactivity despite all power-saving settings being disabled. The cause is a bug in gnome-settings-daemon power plugin (gsd-power 46.0) – it ignores idle-dim=false at startup and dims the display anyway. The fix is two commands:
bash
gsettings set org.gnome.settings-daemon.plugins.power idle-dim false gsettings set org.gnome.settings-daemon.plugins.power idle-brightness 100
Setting idle-brightness to 100 makes the dimming call a no-op – gsd-power still fires but dims to 100%, which changes nothing. Brightness keys continue to work normally.
The Symptom
After installing Ubuntu 24.04 on a Lenovo Legion Pro with an AMD iGPU, the built-in display starts dimming after exactly 30 seconds of inactivity. The screen does not turn off – it just reduces brightness noticeably. External monitors connected via USB-C are unaffected. The behavior persists whether on battery or AC power.
The obvious first suspect is GNOME’s screen blank or screensaver settings, but the Settings UI shows everything is already configured correctly.
Ruling Out the Obvious Suspects
X11 / DPMS
bash
xset q | grep -A3 "Screen Saver\|DPMS"
All DPMS timeouts return zero. Not the cause.
GNOME Idle and Screensaver
bash
gsettings get org.gnome.desktop.session idle-delay gsettings get org.gnome.settings-daemon.plugins.power idle-dim gsettings get org.gnome.desktop.screensaver idle-activation-enabled
idle-delay is 900 seconds (15 min), idle-dim is false, screensaver is disabled. None of these match the 30-second trigger.
AMD ABM (Adaptive Backlight Management)
bash
cat /sys/module/amdgpu/parameters/abmlevel
Returns -1, meaning the parameter is not set at boot. ABM could theoretically cause dimming, so it is worth disabling as a precaution by adding amdgpu.abmlevel=0 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and running sudo update-grub. After reboot, the parameter correctly returns 0 – but the dimming persists. Not the cause.
Catching the Culprit
Confirming it is a Backlight Value Change
bash
watch -n 1 'cat /sys/class/backlight/amdgpu_bl2/brightness'
The value drops from approximately 39000 to 20000 at exactly 30 seconds of inactivity. This is an OS-level backlight write, not a panel-level hardware event.
Tracing Writes to the Brightness File
bash
sudo apt install auditd sudo auditctl -w /sys/class/backlight/amdgpu_bl2/brightness -p w -k backlight_write # wait 30 seconds idle sudo ausearch -k backlight_write -i | grep "comm=\|exe="
The audit log identifies the writer:
comm=(sd-bright) exe=/usr/lib/systemd/systemd-logind
systemd-logind is writing to the brightness file via its internal sd-bright thread.
But Wait – Is logind Acting Alone?
Checking logind’s own config:
bash
systemd-analyze cat-config systemd/logind.conf | grep -i idle
Setting IdleAction=ignore and IdleActionSec=infinity in /etc/systemd/logind.conf.d/nobrightness.conf has no effect. The sd-bright thread in logind operates independently of IdleAction – it is a hardcoded brightness management feature introduced in systemd 254+.
Finding the Real Trigger via DBus
Since logind is the writer but may be responding to an external signal, monitor DBus:
bash
sudo dbus-monitor --system "interface='org.freedesktop.login1.Session'" | grep -i bright
This reveals:
method call ... path=/org/freedesktop/login1/session/auto interface=org.freedesktop.login1.Session member=SetBrightness sender=:1.105
Someone is calling SetBrightness on logind via DBus. Identifying the sender:
bash
dbus-send --system --print-reply --dest=org.freedesktop.DBus \ /org/freedesktop/DBus \ org.freedesktop.DBus.GetConnectionUnixProcessID string::1.105 # returns PID, then: ps aux | grep <PID>
The process is /usr/libexec/gsd-power – the GNOME Settings Daemon power plugin.
The Bug
gsd-power version 46.0 on Ubuntu 24.04 has a bug: it ignores the idle-dim=false gsettings value at startup and proceeds to dim the display after 30 seconds regardless. The setting is read correctly – gsettings get confirms it is false – but the running process does not honor it.
Interestingly, killing gsd-power with pkill gsd-power causes GNOME to restart it automatically, and the restarted instance correctly respects idle-dim=false. This confirms the bug is in the initialization path, not in the runtime logic.
Failed Fix Attempts
Several approaches were tried and failed:
- Restarting gsd-power via a systemd user service – worked for dimming, but broke brightness key handling after restart
- Toggling idle-dim via gsettings in the service – gsd-power ignores the toggle because the idle timer is already registered
systemd-inhibit --what=idle– gsd-power calls SetBrightness directly via DBus, bypassing inhibitor locks- Making the brightness sysfs file read-only – confirmed the bug but is not a usable solution
The Fix
The simplest working solution: let gsd-power call SetBrightness, but make the call a no-op by setting the dim target to 100%:
bash
gsettings set org.gnome.settings-daemon.plugins.power idle-dim false gsettings set org.gnome.settings-daemon.plugins.power idle-brightness 100
idle-brightness controls what percentage gsd-power dims to on idle. Setting it to 100 means it “dims” to full brightness – effectively doing nothing. Brightness keys continue to work normally since gsd-power is not being killed or blocked.
This survives reboots without any additional configuration.
Cleanup
After reaching the fix, several diagnostic tools and config changes can be removed:
bash
# Remove audit watch sudo auditctl -W /sys/class/backlight/amdgpu_bl2/brightness -p w -k backlight_write # Remove logind override (had no effect anyway) sudo rm -f /etc/systemd/logind.conf.d/nobrightness.conf sudo systemctl restart systemd-logind # Remove diagnostic tools sudo apt remove inotify-tools auditd -y
The amdgpu.abmlevel=0 grub parameter is harmless to keep or revert – it was a reasonable thing to try but was not the cause.
Summary
| What we thought | What it actually was |
|---|---|
| GNOME screensaver / DPMS | Not involved |
| AMD ABM / Panel Self Refresh | Not involved |
| systemd-logind acting autonomously | Acting on behalf of gsd-power |
| gsettings idle-dim=false sufficient | Bug in gsd-power 46.0 ignores it at startup |
Root cause: gnome-settings-daemon power plugin 46.0 on Ubuntu 24.04 Noble ignores idle-dim=false during initialization and dims the screen after 30 seconds regardless of user settings.
Fix: Set idle-brightness to 100 so the dimming call becomes a no-op.