[SOLVED] Even lower screen brightness?

Even if it is a hardware problem it would be great to have a native software solution from Framework. The lowest brightness on the laptop is higher than my monitor at 50% brightness. I avoid using the laptop past 19:00 because of that.

Marking something as solved without a solution is quite upsetting.

4 Likes

I tested this again, and while sending a PWM signal of 0 to the GPU does not completely turn off the display, it is still considerably less bright than by default.

You can test this with the following patch

diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
index ad9aca790dd7..42f1f476ec67 100644
--- a/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
+++ b/drivers/gpu/drm/amd/display/dc/link/protocols/link_edp_panel_control.c
@@ -521,12 +521,18 @@ bool edp_set_backlight_level(const struct dc_link *link,
                uint32_t backlight_pwm_u16_16,
                uint32_t frame_ramp)
 {
+       static bool force_real_zero;
        struct dc  *dc = link->ctx->dc;
 
        DC_LOGGER_INIT(link->ctx->logger);
        DC_LOG_BACKLIGHT("New Backlight level: %d (0x%X)\n",
                        backlight_pwm_u16_16, backlight_pwm_u16_16);
 
+       if (force_real_zero && backlight_pwm_u16_16 < 5000)
+               backlight_pwm_u16_16 = 0;
+       force_real_zero = !force_real_zero;
+
+
        if (dc_is_embedded_signal(link->connector_signal)) {
                struct pipe_ctx *pipe_ctx = get_pipe_from_link(link);

And then repeatedly do echo 0 > /sys/class/backlight/amdgpu_bl1/brightness and observe the different brightness levels.

For a “permanent” “fix” use this:

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 7099ff9cf8c5..6e463e5860e5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -383,6 +383,9 @@ static int amdgpu_atif_query_backlight_caps(struct amdgpu_atif *atif)
                        characteristics.min_input_signal;
        atif->backlight_caps.max_input_signal =
                        characteristics.max_input_signal;
+
+       /* Framework Firmware returns "12" by default. */
+       atif->backlight_caps.min_input_signal = 0;
 out:
        kfree(info);
        return err;

This is just some constant in the Firmware which should be easily changable for Framework.
(I don’t see a way to easily override this as a user)

Only tested on a matte panel.

8 Likes

Can confirm that using that kernel driver patch to force override the minimum value provided by the firmware makes it much better. With that, it’s now much more inline with expectations.

Left: framework 16
Right: thinkpad e595

with patch:

without patch:

6 Likes

I would like to experiment with this patch. Could you or @Thomas_Weissschuh point me in the direction of how to compile (?) the modified amdgpu driver and configure my system to use it? What are the keywords I should search for?

I am running Fedora 39.

@gaben

This should work: Building a Custom Kernel :: Fedora Docs

But further than that I have no clue about Fedora.

1 Like

I sent a quirk to the kernel: [PATCH] drm/amd: force min_input_signal to 0 on Framework AMD 13/16 - Thomas Weißschuh
Let’s see if it can be made to work out of the box.

7 Likes

Shouldn’t this just be enabled for the default matte panel? And not for the glossy panel and the new, recently launched panel?

Aside from that, I suppose a Framework firmware patch would be the best long-term solution?

1 Like

Depends on what it does on those panels.
Somebody would need to test it.

Yes.

I did measurements for fw13 old glossy panel and fw16 panel. On each graph there are 2 curves – unpatched (higher) and patched (lower) version. Axis X – value set in /sys/.../amdgpu_bl0/brightness, axis Y – brightness measured by a sensor in some relative units.

Fw13 original glossy (~2022)

Fw16

With the patch above, for both panels min brightness goes 5.5x down.

As I understand it, framework folks aren’t going to patch firmware for 16" model, since current value is already minimal per panel’s datasheet. It works nicely outside of spec, though.

7 Likes

Just writing to add a +1 on the request to lower the minimal brightness for the ADM FW13 matte panel (not the new high-resolution one). I use my laptop for work, and the screen brightness at minimal setting is too bright to be used in a dark conference room - it’s distracting to everyone around me. Confirmed with brightnessctrl that it is actually at the minimum:
Current brightness: 1 (0%)

Does anyone know if the new 2.8K panel goes lower on a 7840U FW13 ? Might be a reason for me to upgrade, even if I don’t need the higher resolution or higher refresh rates at all. Or is minimum brightness even higher, given the higher max brightness of that screen ?

Has there been any news on this? Compiling the kernel on Fedora for each update is a pain…

1 Like

I just sent out a new patchset, any testing is welcome.
https://lore.kernel.org/lkml/20240731-amdgpu-min-backlight-quirk-v3-0-46d40bb21a62@weissschuh.net/T/#t

9 Likes

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

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

Nope.

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

  1. by installing brightnessctl and setting it to sudo brightnessctl -n s 0.2%
  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 :eyes: are happy now.

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

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

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.

1 Like

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%):

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

1 Like