[SOLVED] Even lower screen brightness?

GreyXor · July 31, 2024, 9:30pm

Thanks very much, any answers from framework team to integrate this into firmware ?

Nelo390 · August 15, 2024, 6:07pm

This worked for me! Does this patch reduce the maximum brightness? I don’t think it does, but I might as well make sure.

Thomas_Weissschuh · August 15, 2024, 6:27pm

Nope.

Silence1sG0lden · August 16, 2024, 8:33pm

I don’t know which Linux you’re using, but I have found two work-arounds:

by installing brightnessctl and setting it to sudo brightnessctl -n s 0.2%
Alternatively, for Linux Mint, there’s an applet called “Brightness and gamma applet” by Cardsurf (though it’s marked as potentially crashing my Cinnamon… So far it hasn’t.)

My are happy now.

gaben · August 17, 2024, 8:58am

This does not work on my machine, Fedora 39, AMD 7640U, matte display.

Silence1sG0lden · August 18, 2024, 9:46pm

I know nothing about Fedora, but this seems to be it: brightnessctl - Fedora Packages
No?

Thomas_Weissschuh · August 18, 2024, 10:14pm

Brightnessctl is using the standard sysctl APIs.
It may be that your default userspace application applies a lower threshold which you can bypass with brightnessctl.

But the kernel patch can go even lower.
There is no (remotely sane) way for any userspace
to do the same on its own.

shazow · September 13, 2024, 11:16pm

In case this is useful for others, I wrote a little wrapper script which turns off the screen altogether when you go below 0% brightness (and turns it back on when you go above 0%):

github.com

shazow/nixfiles/blob/main/home/bin/brightness

#!/usr/bin/env sh
# Wrapper around `light` except turns off screen past 0

: "${OUTPUT_DEVICE:="auto"}" # or "eDP-1"
: "${AMOUNT:="10"}"

if [ "$OUTPUT_DEVICE" = "auto" ]; then
    OUTPUT_DEVICE="$(swaymsg -t get_outputs | jq .[0].name)"
fi

if [ "$2" ]; then
    # Override env AMOUNT because it's annoying to pass env vars into sway bindings
    AMOUNT="$2"
fi

readonly old="$(light -G)"

case $1 in
    up)
        if [ "$old" = "0.00" ]; then

This file has been truncated. show original

It’s fairly sway-specific but shouldn’t be too hard to generalize.

adioe3 · October 8, 2024, 1:39pm

@Thomas_Weissschuh do you have a public git repo somewhere? Scraping the patches offa the email is a little annoying and I don’t feel like setting up mutt just yet

Thomas_Weissschuh · October 8, 2024, 1:59pm

Nope

Go to [PATCH v6 0/4] drm: Minimum backlight overrides and implementation for amdgpu - Thomas Weißschuh download the mbox.gz, gunzip it and feed the result to git am.

Mario_Limonciello · October 8, 2024, 5:39pm

FYI You can also use b4 shazam URL with the lore url.

Daniel_Poelzleithner · October 11, 2024, 9:54am

The monitor display brightness in low light conditions is just terrible. 1 star.
The human eye works algorithmically with 20 minutes full adjustment time.

It is an absolute pain to use a framework 16 in low light conditions

GreyXor · October 12, 2024, 9:11am

Framework team has not yet given any news about this firmware update. In the meantime, under Linux at least, you can compile the patch that allows the screen to be dimmed.

Thomas_Weissschuh · October 12, 2024, 9:23am

For the Framework 16 that patch will need a new entry in the quirk table.

Leonard · November 21, 2024, 4:16pm

Unfortunately, the new 3.06 BIOS for AMD Framework doesn’t include a firmware fix for the minimum brightness.

On the other hand, it looks like the Linux patch is scheduled for kernel 6.14, is that correct?

Thomas_Weissschuh · November 21, 2024, 5:00pm

Indeed. Please note that this is only for the 13 inch displays.

For 16 inch somebody would need to test it and send a patch.
Please note that Framework have mentioned that the datasheet of the 16 inch display does not support 0 PWM, so maybe there will be pushback.

Doridian · November 29, 2024, 11:28pm

I just for the sake of experiment patched the kernel on my FW16 to force the min_input_signal to 0 and indeed my screen now gets noticeably darker. So I would call it a success on that end, the screen seems to take it!

Of course that doesn’t mean anything about if the screen SHOULD be driven at that PWM, but it does work at least!

Once 6.14 fully rolls around, that patch will become way more surgical I suppose, or maybe I’ll submit it upstream even.

Would love to hear what others think as well.

For anyone who wants to try it on Arch, here’s a modified inux-zen package that patches ther kernel automatically: GitHub - Doridian/linux-zen-dori

GreyXor · November 29, 2024, 11:46pm

Compiling this on my AMD 13 2.8k right now.
EDIT: Working very good! That’s so nice to have very low brightness

Atemu · November 30, 2024, 12:23am

Uh, huh, so, I didn’t realise this patch was intended for the FW13 and have been running with the patch for over half a year without any real issue.

The biggest “issue” I noticed is that the lowest three backlight levels result in the same actual screen brightness (not sure it’s the same for FW13s?) but that’s not really a big deal.

James_Jarrett · December 4, 2024, 3:38am

I’m on a Framework 16 with your earlier-version patch kind of… hand-edited into place until I can learn how to wrangle kernels and patches in Gentoo properly, but… my god. I’ve never been this happy about a monitor with colors this screwed up. My retinas will survive to fight another day. You’ve literally saved me from blindness.

(I can see why it’s out of spec though. It’s like somebody beat the gammas with a wrench until they stopped moving.)

edit: roughly a couple weeks later, I don’t know what I was complaining about. The dimness remains glorious. The colors are fine, other than being dim. I kind of remember seeing a green tint in grayish highlights, but I can’t reproduce it. Might’ve just been some temporary bias in my vision from the environment or something. I mean, maybe a little bit…