I experience the same thing on AMD 7640U, the minimum brightness of 0, confirmed with cat /sys/class/backlight/amdgpu_bl1/brightness, is far too bright.
Unscientifically, with my display at a color temperature of 3,600 K, 0 brightness feels about as bright as my phone at 25% brightness at default colour temperature.
Given that this is amdgpu, it might be possible to tweak in the driver somewhere.
I am using BIOS 3.03.
Same on Fedora 39 AMD 7640U, the extension Soft Brightness helps but it’s only a software tint, the actual backlight is still pretty bright.
+1 still an issue here on my 7840U. I’d like to turn off my internal screen while continuing to use the laptop with an external screen, without closing the lid (so I can use the keyboard) – seems impossible?
Tried brightnessctl, light, etc but none of the tools drop to 0 backlight, there’s always some backlight no matter what. With dpms, the screen wakes up as soon as there’s any interaction so that makes it impossible to use the laptop with an external monitor.
Every other laptop I’ve had (thinkpad, macbook, dell, etc.) all go to no-backlight when brightness is 0, but Framework 13 AMD does not.
@Matt_Hartley Sounds like it’s an issue with the firmware on the AMD series? Any chance it’s slated to get fixed in a future release?
This ticket in its current form has effectively been tagged as wontfix/worksforme.
I think in order to get Framework to address it, someone with a tool to measure brightness needs to create an objective acceptance criteria like: screen turns off at 0% brightness and screen is at xxx nits at 4% brightness.
Without an objective criteria the discussion just becomes “I want it dimmer” vs. “it looks dim to me”
At least under Linux, turning the backlight off or not at “0%” might also depend on the chosen desktop environment. While Plasma 5 turns off the backlight at “0%” with my 12th Gen Intel, the new Plasma 6 deliberately keeps it on (“no one expects it to turn off” - hmmm).
“0% brightness” with Plasma 5 (function keys, not sure of brightness slider):
$ cat /sys/class/backlight/intel_backlight/actual_brightness
0
→ backlight completely off
“0% brightness” with Plasma 6 (brightness slider or function keys):
$ cat /sys/class/backlight/intel_backlight/actual_brightness
1
→ backlight at minimum(?)
Going dimmer than is available right now? Not that I am aware of.
Every laptop I’ve used before the Framework allows me to turn off the screen via brightness to 0 (MacBooks, Thinkpad, Dell, etc).
Personally it doesn’t matter how dim it can go right now, I just want it to be entirely off. I think that’s fairly objective?
Using dpms to turn off the screen is not equivalent because then we can’t use input devices without activating the screen again.
Turning off the backlight at 0 brightness altogether. Would it be possible to please add this issue for tracking internally?
My understanding is that this issue is worse on the AMD models. People seem to have found ways to turn down the backlight to off on the Intel models, but as far as I can tell it’s impossible on the AMD models?
Can confirm with 11th gen Plasma 5.27 function keys will turn the backlight completely off at “0%” while using the brightness slider set to 0% actually sets the minimum brightness possible, as you indicated a value of 1
It seems intel boards are able to use the aforementioned tools to control the backlight but AMD boards are unable.
I’m not sure this is the right place for this since I’m running Windows 11 on the FW16. If someone knows where this idea belongs, please let me know,
I’ve found that lowering the brightness in the AMD Adrenaline software helps a little with the screen brightness. Unfortunately it doesn’t directly lower the backlight, but it does a better job than some 3rd party software I’ve tried.
The setting is under Gaming > Display, switch Custom Color to ON, then lower the brightness slider.
@shazow in sway you can turn the display off with swaymsg "output * power off. Other Wayland compositors should have similar functionality and XOrg has the same functionality with xrandr --output <panel name here> --off (you should be able to see a list of panels with just xrandr). You’ll just have to write a bash script etc that wraps how you change brightness. To turn them back on, just swap off to on.
On the Framework 16 using Arch Linux (also verified on Manjaro), the brightness does not go anywhere near dim enough for use in low-light environments (and is substantially brighter than my thinkpad e595). I wrote the following script to semi-workaround this.
This supports shifting either the brightness or the color temperature of the display by the specified value using redshift. Displays a re-usable notification with a progress bar to indicate the current level (tested using libnotify version 0.8.3).
This also works around the inability to detect the current brightness/color by saving the last set value and making the next change based on that.
Example usage (particularly useful if bound to hotkeys):
displayshift.sh light -25 #decreases brightness by 0.25
displayshift.sh light 10 #increases brightness by 0.1
displayshift.sh temp -525 #decreases color temperature by 525
displayshift.sh temp 200 #increases color temperature by 200
displayshift.sh:
#!/bin/bash
#usage: displayshift.sh [light|temp] [0-9]+
#light range: 1-100
#color range: 1000-25000
#--settings--
#notification icons (defaults are in papirus-icon-theme)
icolight="notification-display-brightness-medium"
icotemp="colortone"
icotemp_default="emblem-default" #shown when color temperature is exactly 6500 (default)
#cache location / files
cachefol="$HOME/.cache/displayshift"
cachelight="$cachefol/backlight.dat"
cachetemp="$cachefol/colortemp.dat"
cachenotid="$cachefol/notify.dat"
#--functions--
to_int(){ [[ "$1" =~ ^[\-]?[0-9]+$ ]] && echo "$1" || echo 0; }
msg_err(){ notify-send -i dialog-error "displayshift" "$@" ; }
msg_light(){ notify-send -i $icolight -h int:value:$newlight -r "$notid" -p " " ; }
msg_temp(){
tempico="$icotemp"; [[ "$newtemp" = "6500" ]] && tempico="$icotemp_default"
notify-send -i $tempico -h int:value:$((newtemp*4/1000)) -r "$notid" -p " "
}
#--main--
[[ -d "$cachefol" ]] || mkdir "$cachefol" || (msg_err "err: failed to create cache folder"; exit)
#read params
case "$1" in
light) chnglight="$2"; chngtemp=0 ;;
temp) chnglight=0; chngtemp="$2" ;;
*) msg_err "err: invalid parameter"; exit ;;
esac
chnglight="$(to_int "$chnglight")"
chngtemp="$(to_int "$chngtemp")"
#read cache data
if [[ -f "$cachenotid" ]]; then
notid="$(cat "$cachenotid")"
else notid=0; fi
notid="$(to_int "$notid")"
if [[ -f "$cachelight" ]]; then
curlight="$(cat "$cachelight")"
[[ "${curlight:0:1}" = "0" ]] && curlight="${curlight:1}"
else curlight=100; fi
curlight="$(to_int "$curlight")"
if [[ -f "$cachetemp" ]]; then
curtemp="$(cat "$cachetemp")"
else curtemp=6500; fi
curtemp="$(to_int "$curtemp")"
#calculate new, ensure within valid range
newlight="$((curlight+chnglight))"
[[ "$newlight" -lt 1 ]] && newlight=1
[[ "$newlight" -gt 100 ]] && newlight=100
[[ "$newlight" -lt 100 ]] && newlight="0$newlight"
[[ "$curlight" -lt 100 ]] && curlight="0$curlight"
newtemp="$((curtemp+chngtemp))"
[[ "$newtemp" -lt 1000 ]] && newtemp=1000
[[ "$newtemp" -gt 25000 ]] && newtemp=25000
#make changes (if needed)
if { [[ "$1" = "light" ]] && [[ ! "$newlight" = "$curlight" ]]; } || \
{ [[ "$1" = "temp" ]] && [[ ! "$newtemp" = "$curtemp" ]]; }; then
if redshift -P -O $newtemp -b ${newlight:0:1}.${newlight:1:1}:${newlight:0:1}.${newlight:1:1}; then
case $1 in
light) echo "$newlight">"$cachelight" ;;
temp) echo "$newtemp">"$cachetemp" ;;
esac
else msg_red "err: failed to run redshift with specified value"; exit; fi
fi
#final notification
case $1 in
light) msg_light>"$cachenotid" ;;
temp) msg_temp>"$cachenotid" ;;
esac
How is this marked [RESOLVED] when there’s no resolution here? I’m also on an Framework 13 AMD and the lowest brightness level is way too bright.
Have you tried Plasma? Turning to 1 in the default slider completely disables the backlight, if that’s still too bright you can fiddle the nightmode; which in effect is doing what redshift / others have suggested which changes the colour temperatures.
This should be a limitation of your desktop environment/window manager.
Btw, hi Andrey 
I can certainly disable the screen altogether, regardless of desktop environment, but that’s not the same thing as turning the backlight to zero.
Admittedly I am on x11 and not wayland, not sure if there’s a workaround in wayland that works better (perhaps Plasma is doing some magic there?).
In either case, relying on dpms and temperature shifting to approximate functionality is still just workarounds for what appears to be a bug/limitation of the AMD frameworks’ firmware (a limitation that is not present on the intel version, or any other laptop I’ve used).
Perhaps it’s worth opening a fresh thread?
P.S. Hey fellow Python http alum!
This was specifically for this sentence:
On my sway (wayland) setup if I do the following:
swaymsg 'output eDP-1 dpms off'; sleep 10; swaymsg 'output eDP-1 dpms on'
Then I can wildly use input devices during those 10 seconds and the screen stays black.
From a kernel perspective the semantics of brightness = 0 are not well-defined.
Different drivers implement different behaviors.
There is ongoing work to get a new backlight API, with a well-defined 0 value.
But that definition is “just enough to be readable”, for “off” use dpms.
FWIW I forced the kernel to override the limits received from ACPI and set the PWM to a hard 0.
But that still didn’t turn off the screen completely.
So it may be in the GPU firmware.
That’s fair. I won’t make an argument that the driver does not technically comply within the boundaries of the the kernel specifications.
I am making the argument that from a Framework customer perspective, particularly people in this thread (and from a consistency perspective of the Intel version of the device, and the vast majority of other consumer laptops like Thinkpads and Macbooks): Framework should consider changing this behaviour on their AMD devices.
The backlight turning off works both on fedora39 and 40 using those respective DE brightness sliders when set to 0 on the AMD FW13. I don’t think this has anything to do with Framework it’s whatever userspace you’re using and/or configuration that’s been changed from the initial state. I don’t know I haven’t used Xorg in years, but I would suggest testing on a fedora40 live distro in and seeing if you have the same issue. You’re the first user i’ve seen who hasn’t been able to get the backlight turned off i’ve come across on the forums.
Regarding the lowest brightness (while still being on), I agree this shouldn’t be marked as “resolved”. There is a workaround that helps (redshift or other tools to darken the displayed image), but not enough IMHO.
It really does not go low enough for use in low-light environments. It is still uncomfortable/harsh to look at in the darkest of environments even when using redshift. Other laptop screens can dim the backlight considerably lower than the AMD-powered framework 16.
Case in point:
Left: framework 16
Right: thinkpad e595
Both screens are showing the same completely white image at their lowest brightness (brightnessctl s 0%) (without the use of redshift or similar software).
I should mention: in the picture, the thinkpad has no screen protector, while the framework has this “blue light blocking” one
I too agree that the lowest brightness is much too high. Using night light makes it somewhat bearable, though it remains a workaround.
According to this post, the matte panel simply has a much higher rated minimum brightness than the glossy one (20 nits vs 4 nits, respectively). Matt promised to provide some more info on the subject in that same thread, but hasn’t come back to it yet.
