Bug 2511730 - Internal display backlight/brightness broken after kernel update on Fedora 44
Summary: Internal display backlight/brightness broken after kernel update on Fedora 44
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 44
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-08-05 19:46 UTC by Evgeni Borisov
Modified: 2026-08-06 16:41 UTC (History)
17 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
Extract from the previous boot, when the issue occur. (120.69 KB, text/plain)
2026-08-05 19:46 UTC, Evgeni Borisov
no flags Details

Description Evgeni Borisov 2026-08-05 19:46:56 UTC
Created attachment 2153709 [details]
Extract from the previous boot, when the issue occur.

1. After a recent kernel update on Fedora 44, the internal laptop display becomes very dim / brightness is stuck at a low level. Booting into the previous kernel version restores normal brightness and behavior, confirming this is a kernel-level regression rather than a hardware or desktop-environment issue.


2. What is the Version-Release number of the kernel:
Working kernel: 7.1.5-201.fc44.x86_64
Broken kernel: 7.1.6-201.fc44.x86_64

3. Did it work previously in Fedora? Yes


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:Always, on every boot with the affected kernel version.


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:


6. Are you running any modules that not shipped with directly Fedora's kernel?:No


7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

Comment 1 egeorget 2026-08-06 07:18:16 UTC
I have a similar issue lately, with brightness getting very low at 99% and 100%, but getting back at a ok level at 98% and lower. Could you try setting your backlight level at 95%, just to be sure our issue are the same or not ?

Comment 3 Evgeni Borisov 2026-08-06 14:44:58 UTC
(In reply to egeorget from comment #1)
> I have a similar issue lately, with brightness getting very low at 99% and
> 100%, but getting back at a ok level at 98% and lower. Could you try setting
> your backlight level at 95%, just to be sure our issue are the same or not ?

I can make a test in 1-2 hours. Then will provide the results.
Sorry for the delay.

Comment 4 Evgeni Borisov 2026-08-06 15:43:21 UTC
(In reply to Evgeni Borisov from comment #3)
> (In reply to egeorget from comment #1)
> > I have a similar issue lately, with brightness getting very low at 99% and
> > 100%, but getting back at a ok level at 98% and lower. Could you try setting
> > your backlight level at 95%, just to be sure our issue are the same or not ?
> 
> I can make a test in 1-2 hours. Then will provide the results.
> Sorry for the delay.

After using 
#Brightnrssctl set 95%
The brightnesss restored as normal.

Getting back to 98% and higher the brighness became very low - almost nothing is visible.

Comment 5 Evgeni Borisov 2026-08-06 16:41:15 UTC
I did a binary search directly via sysfs to find the exact threshold where the panel goes dark, bypassing brightnessctl/userspace entirely:
# max_brightness = 65535

echo <value> | sudo tee /sys/class/backlight/amdgpu_bl1/brightness
cat /sys/class/backlight/amdgpu_bl1/actual_brightness
Results:

brightness written	actual_brightness	screen
63569 (97%)	65535	OK
63691	65535	OK
63752	65535	OK
63783	65535	OK
63790	65535	OK
63794	65535	OK
63796	65535	OK
63797	65535	OK
63798	0	DARK
63814	0	DARK
64060	0	DARK
64550	0	DARK
65534	0	DARK
65535 (100%)	0	DARK

The exact threshold is between 63797 (last working value) and 63798 (first failing value). Note this is not a round percentage (63797/65535 ≈ 97.36%) nor an obvious power-of-two boundary, so it may correspond to some internal panel/DPCD scaling table or register width rather than a simple percentage cutoff.

Notably, actual_brightness reads back as exactly 0 for every failing value (not a partial/dim value), suggesting the driver or panel firmware is rejecting/misinterpreting values above this threshold entirely, rather than a gradual scaling error.


Note You need to log in before you can comment on or make changes to this bug.