[Solved] - Screen goes very dim when reaching 100% Brightness

Community Support
,
1

When going to 100% brightness, my Framework 16 laptop screen becomes dim. It goes back to very bright at 95%.

I’m running:

  • nixos 26.05
  • Laptop 16 AMD 7040 series
  • kde

I did make a firmware update at the same time (shouldn’t have, yes, I know), but I rebooted in an old nixos generation and couldn’t reproduce the problem, so I assume it is not a firmware issue, but a kernel one. Last working revision is 26.05.20260719.fd14620 (linux-6.18.39). It got broken in 26.05.20260807.ee48b14 (linux-6.18.43).

Thanks for the help

2

I got this on my other (non-Framework) laptop as well, often after waking up from sleep. Likely a Linux or KDE version problem

3

Oh important info! Which OS/version are you using? Is it a recent problem? Do you experience it every time, or only from time to time? After a cold boot?

4

Hardware: AMD 5900HX NVIDIA RTX 3070 Max-Q
Software: EndeavourOS Linux 7.1.6, Plasma 6.7.4, Wayland.

It happens more often than I previously thought. I witnessed the problem a few days before it first happened on a Framework

5

Can confirm that I too have been seeing this on my FW16 running Fedora Silverblue 44.

Video of the brightness bug:

6

Update for me:
FW16 AMD 7840HS. No dGPU.
Brightness bug:
Linux mainline kernel 7.1.5 OK.
Linux mainline kernel 7.1.6, 7.1.7, 7.1.8 Bad.
Linux firmware is latest from git, for all kernel version tests, so I don’t think it is amd gpu firmware related or mesa version related.
I am using 7.1.8 because it fixes some other green noise artifacts.
So, something in here is causing the brightness bug:
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.1.6

Looking at:
/sys/devices/pci0000:00/0000:00:08.1/0000:c1:00.0/drm/card0/card0-eDP-1/amdgpu_bl0

brightness: 62291 is bright. 65535 is dim
actual_brightness: 63584 is bright. 0 is dim

So, it seems that “actual_brightness” matches what the user sees happening.
the “brightness” matches what the user sees, except at the 65535 setting.
So, there is some sort of bug mapping brightness → actual_brightness.

Linux kernel documentation:
What: /sys/class/backlight/<backlight>/brightness
Date: April 2005
KernelVersion: 2.6.12
Contact: Richard Purdie rpurdie@rpsys.net
Description:
Control the brightness for this . Values
are between 0 and max_brightness. This file will also
show the brightness level stored in the driver, which
may not be the actual brightness (see actual_brightness).
Users: HAL

What: /sys/class/backlight/<backlight>/actual_brightness
Date: March 2006
KernelVersion: 2.6.17
Contact: Richard Purdie rpurdie@rpsys.net
Description:
Show the actual brightness by querying the hardware. Due
to implementation differences in hardware this may not
match the value in ‘brightness’. For example some hardware
may treat blanking differently or have custom power saving
features. Userspace should generally use the values in
‘brightness’ to make decisions.
Users: HAL

7

skimming the changelog, I have this strong candidate:

commit 490ceacd2162de919a142bcb4eff363bb493b1de
Author: Mario Limonciello <mario.limonciello@amd.com>
Date:   Mon Jun 29 15:27:00 2026 -0500

    drm/amd/display: Fix backlight max_brightness to match exported range
    
    commit f1b5d8f9cc54ae8a2567ac126867ae488e1bf625 upstream.
    
    [Why]
    FWTS autobrightness fails on eDP panels because actual_brightness can
    read higher than the advertised max_brightness (e.g. 63576 vs 62451).
    
    The conversion helpers expose the firmware PWM range to userspace as
    [0..max].  But max_brightness is advertised as (max - min), which is
    smaller.  So reading the level can return a value above max_brightness.
    
    This regressed in commit 4b61b8a39051 ("drm/amd/display: Add debugging
    message for brightness caps"), which changed max_brightness to
    (max - min) and undid commit 8dbd72cb7900 ("drm/amd/display: Export full
    brightness range to userspace").
    
    [How]
    Advertise max_brightness as max, and scale the initial AC/DC brightness
    against max too.  Update the KUnit expectations to match.
    
    Fixes: 4b61b8a39051 ("drm/amd/display: Add debugging message for brightness caps")
    Reviewed-by: Alex Hung <alex.hung@amd.com>
    Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
    Signed-off-by: George Zhang <george.zhang@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    (cherry picked from commit bd9e2b5b0473c75abc0f4134dfe79ecbfb16610d)
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I’m going to test with this commit reverted and we’ll see.

8

That may contribute to it, but at a guess I would expect the bug to be somewhere here:

in file: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c

static void amdgpu_dm_backlight_set_level(struct amdgpu_display_manager *dm,
                                         int bl_idx,
                                         u32 user_brightness)

At a glance, it all looks a little too complex for something as simple as brightness control.
I can see that is it easy to make mistakes where in some places in the code “brightness” means the hardware setting, and in other places “brightness” means the setting the users can set. Giving two very different things the same variable name is a recipe for confusion.

9

Temporary fix / work around found for the 100% brightness problem.

Add this to the grub kernel command line:
amdgpu.dcdebugmask=0x40000

It essentially disables this function:

drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c:
static void convert_custom_brightness(const struct amdgpu_dm_backlight_caps *caps,
                                      unsigned int min, unsigned int max,
                                      uint32_t *user_brightness)
{
        u32 brightness = scale_input_to_fw(min, max, *user_brightness);
        u8 lower_signal, upper_signal, upper_lum, lower_lum, lum;
        int left, right;

        if (amdgpu_dc_debug_mask & DC_DISABLE_CUSTOM_BRIGHTNESS_CURVE)
                return;

Note: DC_DISABLE_CUSTOM_BRIGHTNESS_CURVE == 0x40000

10

I confirm that reverting this commit fixes the issue for me.

11

I think it is a kernel regression rather than a hardware problem, especially since 6.18.39 works and 6.18.43 shows the issue. I would sugget boot the working NixOS generation for now and compare the display/brightness changes between those kernel versions.

12

Confirmed: adding amdgpu.dcdebugmask=0x40000 to the kernel command line fixes the issue for me. After rebuilding and rebooting, 100% brightness is bright again instead of
making the panel go dark. I’m on a Framework 16 AMD 7040 running NixOS 26.11 with kernel 6.18.43 and the amdgpu_bl1 backlight device. Before the workaround, the panel
became very dim at 99%, 99.9%, and 100%; 95% remained bright. This appears consistent with the AMDGPU custom-brightness-curve regression. Thanks for identifying the
workaround!

13

I’ve opened a bug on the kernel bugtracker : https://bugzilla.kernel.org/show_bug.cgi?id=221879

And I’ve marked the kernel grub argument as the solution, because it’s really easiest than recompiling the whole kernel :laughing:.

14

Actually, the correct bugtracker is not bugzilla.kernel.org. The correct issue is: Making sure you're not a bot!. It’s already fixed, so we should get the fix soon!