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.
