Bug 483490

Yes, this is intentional, to prevent people from accidentally making the contents of their screen invisible.

To turn off your screen (and in a way that will save more battery than just turning down brightness), you can use a keyboard shortcut which you can set up in system settings.

Reducing the screen brightness is not primarily intended to save battery. It's primarily intended to adjust the backlight (light output) of the monitor (to adjust it to the ambient light environment).

And turning down the brightness of an _external_ monitor (which this bug report is about) would not save battery in the first place.

The contents of the screen also do not become invisible when reducing the brightness of an external monitor to 0%. Instead, setting it to 0% sets the backlight to the minimum, without turning it off completely. Which is useful for dark environments.

The new 1% minimum value is artificially limiting the screen brightness adjustment range and (artificially) prevents setting the monitor brightness to the lowest value.

Which means this change is introducing a regression (compared to KDE Plasma 5.27.x) and therefore should be rolled back.

Right, for an external monitor saving battery is not an argument.

Unfortunately we have no way of knowing for any given screen whether 0% brightness means, as in your case, minimally dim but not off completely, or, as on my screen and many others, completely black. Different devices just handles those values differently which is outside our control. So to be sure we won't let anyone shoot themselves in the foot and inadvertently turn off their screen with our slider, we have to choose the lowest common denominator, which is 1%. I'm sorry if that means a regression for you, but we are currently not planning to change this back.

1% might indeed be the sane default minimum value in this case. That said:

Some other software solutions solve this by allowing users to adjust the minimum and maximum value of the screen brightness slider, example:

https://github.com/xanderfrangos/twinkle-tray/issues/484

Can a setting be added to KDE Plasma (to System Settings -> Display & Monitor or Energy Saving or similar) to allow users to adjust the minimum and maximum value of the screen brightness slider (perhaps with a note saying that 0% can result in the backlight turning off completely on some monitors)?

That way KDE Plasma users could retain full control over the screen brightness and would still be able to set it to 0% where desired (while 1% could remain the default minimum value).

Otherwise KDE Plasma users would need to use alternative third party software solutions such as https://github.com/davidhi7/ddcci-plasmoid for example (which currently is not working on KDE Plasma 6.0.x due to: https://github.com/davidhi7/ddcci-plasmoid/issues/73 ). Which would be undesirable, as KDE Plasma's built-in screen brightness slider otherwise works rather well (except for the new 1% minimum value issue).

Another thing to consider:

Essentially all laptop keyboards (and many external keyboards) have hotkeys for increasing and decreasing the screen brightness. And most external monitors have hardware buttons and OSDs to adjust the brightness. Which means, even if setting the slider to 0% would result in the backlight to turn off completely, there would still be an alternative way to increase the brightness to a value above 0% again in most cases.

NV, please, don't play the back-n-forth game of changing resolution/status of the bug report. It may annoy developers and cause them to close (lock down) and ignore the bug report completely. Thanks.

> Can a setting be added to KDE Plasma

It can. That would be a new feature request / wishlist. Whether or not someone would work on it or the final work would be acceptable is another story. Note that remembering monitors by their EDID is not reliable with some models and docking stations either.

> Essentially all laptop keyboards (and many external keyboards) have hotkeys for increasing and decreasing the screen brightness

Yes, this is intentionally allowed. If user managed to turn the brightness down to 0% using a keyboard, they surely can figure out how to bright it back up. Unlike a mouse-controlled slider which they won't be able to see. Again, this has gone through many iterations and considerations, and is RESOLVED INTENTIONAL.

Alternative: https://bugs.kde.org/show_bug.cgi?id=484033

In progress with https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4117

*** Bug 485437 has been marked as a duplicate of this bug. ***

Git commit 6ca6308ccd2f3266f20f84af6658fa97547e12ee by Jakob Petsovits.
Committed on 18/07/2024 at 07:13.
Pushed by jpetso into branch 'master'.

wayland: Use brightness range 1..max for internal displays

This avoids regressing compared to PowerDevil in 6.1 which also
protected against setting internal display brightness to 0.
Related: bug 430439

M  +2    -1    src/wayland/externalbrightness_v1.cpp

https://invent.kde.org/plasma/kwin/-/commit/6ca6308ccd2f3266f20f84af6658fa97547e12ee

(In reply to Natalie Clarius from comment #1)
> Yes, this is intentional, to prevent people from accidentally making the
> contents of their screen invisible.

I found this behavior useful in Plasma 5.27, but I assumed that it turned off the screen (instead of just disabling the backlight). I opened a dedicated issue for "0% = turn off screen": https://bugs.kde.org/show_bug.cgi?id=494316

Maybe for the use case (which is the reason I don't like the new restriction either) of turning off the screen when you want to keep stuff running in the background, but in a way that users can immediately get it back on, we could find a way to make a button (like the mute button in the audio applet) to turn off the screen, but have it immediately turn back on any user activity, such as using the mouse. This is what happens when you press Esc on the lockscreen, so it should be possible somehow. I'll look into it some time.

This is apparently what also the "Turn off screen" shortcut would do if it were not broken on X11 (https://bugs.kde.org/show_bug.cgi?id=423035).