[Solved?] AMD CPU/GPU backlight brightness issues since updates

brucew · 2025-07-06 23:21:51

Since doing updates earlier today, my Framework 13 laptop (AMD 7840U/integrated Radeon 780M) sets the backlight of the internal display extremely low--to the point of diffculty reading the screen--during the text-mode portion of bootup at some point after asking for the disk encryption password, only when booting the standard linux-linux 6.15.5 and linux-zen 6.15.5 kernels. Linux-LTS 6.12.36 is unaffected. My Intel/Intel laptop is also unaffected.

The problem persists right into KDE Plasma. Within Plasma System Settings, no amount of fiddling with backlight settings under Power Management makes any difference at all. Backlight of 100 yields the same as zero.

I consulted the wiki, https://wiki.archlinux.org/title/Backlight and tried remedies under 1.1.1 Kernel command-line options, 1.1.2 Udev rule (which is processed before the screen dims), and systemd.restore_state=0 listed in 3 Save and restore functionality. None were effective.

I thought of trying the remedy at "6.9 Backlight is always at full brightness after a reboot with amdgpu driver", but this is the exact opposite of my problem. Which now makes me think, I remember seeing the vulcan driver was updated this morning. Another possibility? But why would it affect only two of the three kernels I have installed?

There are four errors listed in the journal, but they're unlikely to apply since they reference the ucsi_acpi USBC000:00 which is supplying power, but not used as display. Same errors are logged under the LTS kernel which displays just fine, and the same four are still logged when booted under battery power.

I don't know how to proceed or what else to look for. Any help would be appreciated.

NEWINFO: While typing this all inn, the laptop dimmed from the power settings in KDE. A keystroke to wake it up and JOY! Full brightness, even after re-logging it. It did not persists after a reboot.

Last edited by brucew (2025-07-07 21:37:43)

ArchUser2025 · 2025-07-07 06:08:31

I have a similar Issue after updating the kernel. The following helped me.

% cat /sys/class/backlight/amdgpu_bl*/max_brightness # (255 before linux 6.15.5)
62194
% echo 50000 > /sys/class/backlight/amdgpu_bl2/brightness # (200 before linux 6.15.5)

In your case, 'amdgpu_bl1' may be used instead of 'amdgpu_bl2'.

Last edited by ArchUser2025 (2025-07-07 21:10:46)

seth · 2025-07-07 06:56:15

https://bbs.archlinux.org/viewtopic.php … 4#p2248154

brucew · 2025-07-07 18:33:55

Thank you both for your help.

@ArchUser2025 The file

/sys/class/backlight/amdgpu_bl1/brightness

does seem to be the issue. Sometimes it appears as a link, sometimes as a file. When it is a file, it is read-only, even to root, but I can make it writable, then replace the number there (usually 3276 but sometimes 100) with 65535, the number in

/sys/class/backlight/amdgpu_bl1/max_brightness

. Trouble is, it doesn't reliably stay at 65535.

I can't yet nail down what changes it with any repeatability. Sometimes it's fine, other times it changes. Different combinations of kernel, power (AC/battery), and last settings seem to change it in no pattern that's discernable to me, although I'm sure there must be one. After it changes, I change it back, then repeat the process that caused the last change, but no change this time. I'm missing something somewhere. Meanwhile I keep the udev rule and

systemd.restore_state=0

in place even though they don't appear to help.

Although there is a pattern I can discern: The only way to reliably return to full brightness is to switch to battery power, set KDE to automatically dim after X minutes, wait for it to timeout, then strike a key. Always works. Stays at 65535 right up until it doesn't. Rinse. Repeat.

@seth That entire discussion is way over my head. Your links to kernel.org seem to be to pull requests from earlier this year, but I don't understand what they mean or how they apply. Way over my head. Near as I can tell, the poster decided to stick with 6.12 and wait for 6.15.6. Except for the last post where they added

amdgpu.dcdebugmask=0x40000

to an unnamed location in grub. Perhaps you know what they mean, can help suss out how they arrived at that, and how I can apply it to my situation?

In the meanwhile, I know how to fix it temporarily for a seemingly arbitrary period. Fortunately, the laptop is not my primary machine.

seth · 2025-07-07 19:31:28

Idk whether it's the problem you're facing but apparently AMD changed the brightness curve to be more "natural" or whatever and that https://wiki.archlinux.org/title/Kernel_parameters returns to the previous behavior (at least for now)

ArchUser2025 · 2025-07-07 20:44:08

Hmm... This becomes a real problem when we use different kernels.
That is, when I adjust the brightness by booting with linux 6.15.5, it gets lost when booting with linux-lts 6.12.36 and vice versa.
Unfortunately, booting with the kernel parameter 'amdgpu.dcdebugmask=0x40000' does not return the previous behavior, in my case.

brucew wrote:

Meanwhile I keep the udev rule and
systemd.restore_state=0
in place even though they don't appear to help.

I think you need to delete them, adjust the brightness and reboot to check.

Last edited by ArchUser2025 (2025-07-07 20:48:22)

seth · 2025-07-07 20:48:59

6.15.4 isn't affected?

ArchUser2025 · 2025-07-07 21:08:07

Yes, I just checked again. 6.15.4 is not affected.

seth · 2025-07-07 21:19:52

That's a different problem then, the other patch got introduced w/ 6.15 and indeed, https://github.com/gregkh/linux/commits … pu/drm/amd - specifically https://github.com/gregkh/linux/commit/ … 2b2416fc22
Does "brightnessctl 50%" still work correctly?

brucew · 2025-07-07 21:36:44

problem you're facing but apparently AMD changed the brightness curve to be more "natural" or whatever

I gathered that. Second time they've gotten me with one of those. The first was the change in idle speed from lowest possible clock in 6.12 to lowest nonlinear frequency in 6.13.

when I adjust the brightness by booting with linux 6.15.5, it gets lost when booting with linux-lts 6.12.36 and vice versa

You know, ordinarily I use linux-zen as my kernel. I have the others installed only for troubleshooting purposes. I started switching only when this matter showed up. Perhaps the fix is to get it right under linux-zen 6.15.5, then don't mess with the others. (Until the next need to troubleshoot comes along.)

I think you need to delete them, adjust the brightness and reboot to check.

Did it. Survived a reboot on AC. On DC, it dims when "Triggering uevents", then returns to full brightness after it clears the screen again after I've entered my encryption password. That's repeatable under DC, and usable in a pinch. Back on AC, no such dimming when triggering uevents.

Yes, I just checked again. 6.15.4 is not affected.

Thanks for checking that.

I think I'm good for now. I'll simply resume using linux-zen 6.15.5 by default, and squint before typing in the decryption password on DC.

No sure whether to mark this as solved since it's a workaround. No, more like a one-shot after you fix it the first time.

Again, thank you both for your help.

ArchUser2025 · 2025-07-07 21:38:38

@seth

linux 6.15.5 :

$ brightnessctl set 50%
Updated device 'amdgpu_bl2':
Device 'amdgpu_bl2' of class 'backlight':
	Current brightness: 31097 (50%)
	Max brightness: 62194

Yes, it works.

Last edited by ArchUser2025 (2025-07-07 21:43:07)

seth · 2025-07-07 21:50:42

@ArchUser2025 so the problem is the KDE widget thingy likely throwing around absolute values?

I'll simply resume using linux-zen 6.15.5 by default, and squint before typing in the decryption password on DC.

The lts kernel should be unaffected, https://github.com/gregkh/linux/commits … amd/amdgpu

ArchUser2025 · 2025-07-07 22:00:20

@seth
I don't use KDE. I use Sway and LabWC. My problem:

when I adjust the brightness by booting with linux 6.15.5, it gets lost when booting with linux-lts 6.12.36 and vice versa.

It looks like I'll just have to wait for the next linux-lts release.

seth · 2025-07-07 22:03:35

Thought because of the OP - https://wiki.archlinux.org/title/Backli … ctionality

systemd.restore_state=0

ArchUser2025 · 2025-07-08 20:18:37

^ In this case, the maximum brightness is always set when booting. Well, a good option too.

seth · 2025-07-08 20:21:03

You could add a service that runs brightnessctl w/ some predefined percentage or re/stores one via it instead.

ArchUser2025 · 2025-07-08 20:28:49

Yes, thank you for your help, seth.

Sandroid · 2025-07-09 19:47:42

I'm running into a very similar (I think related) issue. With linux 6.15.5, the brightness of my laptop (AMD 8840HS) screen is at 0 (or at least low enough that I can't see any output) during bootup while luks is asking for the decryption password. The screen gets brighter later on in the boot process. Adding the amdgpu.dcdebugmask=0x40000 kernel parameter doesn't help. I've also tried with the mainline kernel (6.16rc5). The screen is brighter there and I can at least read the text on it, but it is still very dark.

seth · 2025-07-10 14:10:20

See this thread, the two AMD changes to the backlight are actually unrelated (except for the entire "don't break the userspace that used to be a thing and happens here so users can change the backlight in 16k instead of 256 steps, because I'm sure most notebook panels have totally not less than 16 discrete backlight levels…)

Try "brightnessctl 50%", resp. add "systemd.restore_state=0" to the https://wiki.archlinux.org/title/Kernel_parameters

Sandroid · 2025-07-10 18:36:53

Thanks seth, that seems to help

Horghski · 2025-07-15 22:26:03

I did an update today after not doing it for a few weeks and my Framework 13 AMD laptop now boots in low brightness if it's on battery. If I boot with it plugged in, it seems to boot with proper brightness. When booted on battery, I can use brightnessctl to set it to 100% and that works, but setting systemd.restore_state=0 as a kernel parameter doesn't seem to do anything. Did I miss a step? Is this really the new "by design" behavior? And if so, why?

I'm using KDE Plasma, not sure if that has anything to do with it as the laptop boots in low brightness before even getting to SDDM.

Last edited by Horghski (2025-07-15 22:39:04)

seth · 2025-07-15 22:46:43

but setting systemd.restore_state=0 as a kernel parameter doesn't seem to do anything

cat /proc/cmdline

Do you have any of the other services installed?
https://wiki.archlinux.org/title/Backli … _utilities

Also check the impact of "amdgpu.dcdebugmask=0x40000" since there've been two changes recently

Is this really the new "by design" behavior? And if so, why?

Seems so and probably because someone at AMD got bored?

Horghski · 2025-07-15 23:19:18

seth wrote:

cat /proc/cmdline

initrd=\initramfs-linux.img root=UUID=2d773776-7eec-4837-8712-bbf22d4660fc rw systemd.restore_state=0

seth wrote:

Do you have any of the other services installed?
https://wiki.archlinux.org/title/Backli … _utilities

I do not, no, I installed brightnessctl just before posting in this thread to see if it would do what you guys suggested.

seth wrote:

Also check the impact of "amdgpu.dcdebugmask=0x40000" since there've been two changes recently

Ok, let me try that and I'll report back.

Horghski · 2025-07-15 23:22:16

I tried the amdgpu parameter, but booting on battery still boots very dim

initrd=\initramfs-linux.img root=UUID=2d773776-7eec-4837-8712-bbf22d4660fc rw systemd.restore_state=0 amdgpu.dcdebugmask=0x40000

seth · 2025-07-16 06:14:32

Does it also happen if you only boot the rescue.target (2nd link below)?
Typically systemd should™ restore the previous backlight level and unless you're crossing kernel versions (between before and after amd got funny) the absolute value should™ not matter, so rather remove systemd.restore_state=0 if that's not your situation.

If nothing else helps

seth wrote:

You could add a service that runs brightnessctl w/ some predefined percentage or re/stores one via it instead.

Arch Linux

#1 2025-07-06 23:21:51

[Solved?] AMD CPU/GPU backlight brightness issues since updates

#2 2025-07-07 06:08:31

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#3 2025-07-07 06:56:15

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#4 2025-07-07 18:33:55

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#5 2025-07-07 19:31:28

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#6 2025-07-07 20:44:08

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#7 2025-07-07 20:48:59

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#8 2025-07-07 21:08:07

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#9 2025-07-07 21:19:52

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#10 2025-07-07 21:36:44

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#11 2025-07-07 21:38:38

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#12 2025-07-07 21:50:42

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#13 2025-07-07 22:00:20

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#14 2025-07-07 22:03:35

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#15 2025-07-08 20:18:37

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#16 2025-07-08 20:21:03

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#17 2025-07-08 20:28:49

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#18 2025-07-09 19:47:42

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#19 2025-07-10 14:10:20

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#20 2025-07-10 18:36:53

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#21 2025-07-15 22:26:03

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#22 2025-07-15 22:46:43

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#23 2025-07-15 23:19:18

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#24 2025-07-15 23:22:16

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

#25 2025-07-16 06:14:32

Re: [Solved?] AMD CPU/GPU backlight brightness issues since updates

Board footer