Powerdevil should already automatically switch to the configured screen brightness for the AC profile if one is set.

Does it not do this? - Then this is a bug.

Or would you like to not configure a default screen brightness for on AC but have it switch back to wherever it was last time before you unplugged?

We could think about this, but imo it is good to have a way of opting out of brightness being automatically changed when plugging/unplugging, and this is what having the "change screen brightness" slider being optional provides.

(In reply to Natalie Clarius from comment #1)
> Or would you like to not configure a default screen brightness for on AC but
> have it switch back to wherever it was last time before you unplugged?

Yes, this is exactly the feature I would like !

I've given my two cents on some specifics for this feature in the additional info section, but it was clear in my mind that this should of course be activated with a user setting. Maybe if the user did not set a predefined brightness level for the plan they're switching to, or using an explicit checkbox ? Either way, this would add one more property to switch in and out of "low battery" mode.

The factor logic you described in the details sounds intresting but imo it is too restrictive to enforce a capped maximum brightness whenever on low battery; I might prefer to decide for myself that I'd like to keep running on max brightness as long it still has some juice left and plug in when I have to.

Another checkbox to restore previous brightness instead of a fixed one would be a possibility but further complicated the already lengthy power settings. I'll keep it open as a wishlist item.

(In reply to devillelethibault from comment #2)
> (In reply to Natalie Clarius from comment #1)
> > Or would you like to not configure a default screen brightness for on AC but
> > have it switch back to wherever it was last time before you unplugged?
> 
> Yes, this is exactly the feature I would like !

Thank you. This has been bugging me forever and was perhaps my main motivation for reworking the Power Management settings page in Plasma 6.0. It's still unsolved at this point and I appreciate others speaking up on the same issue.

> The factor logic you described in the details sounds intresting but imo it is too restrictive to enforce a capped maximum brightness whenever on low battery; I might prefer to decide for myself that I'd like to keep running on max brightness as long it still has some juice left and plug in when I have to.

Agreed. Alternative suggestion: PowerDevil in brightnesscontrol.cpp already has logic to prevent a profile transition to "lower power" from increasing brightness. We could easily add the opposite and prevent it from reducing brightness when AC is plugged in again.

> Another checkbox to restore previous brightness instead of a fixed one would be a possibility but further complicated the already lengthy power settings.

How about we view it as an opportunity to reduce the settings that a user gets to see by default? If there is *only* a checkbox to manually set brightness across profiles, and the three sliders are hidden away on a separate sub-page (you know the one: https://invent.kde.org/plasma/powerdevil/-/issues/10#note_775764) then we don't need an extra line and it can be cleaner both in terms of looks as well as less confusing default behavior.

But what I also really like about this setup is that there is *always* a configured brightness value. No more "switching to Battery has a brightness change configured, but switching back to AC is a no-op". The current state can always be reconstructed from configuration. That will be a major win.

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

Plasma 6.2 broke brightness controls in the power management setting. No matter the AC/battery state, the brightness never changes. The situation hasn't improved with the update to frameworks 6.7 either.

Affected system details:
Operating System: openSUSE Tumbleweed 20241012
KDE Plasma Version: 6.2.0
KDE Frameworks Version: 6.7.0
Qt Version: 6.7.3
Kernel Version: 6.11.2-1-default (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Manufacturer: LENOVO
System Version: ThinkPad X1 Carbon 4th

(In reply to MK from comment #6)
> Plasma 6.2 broke brightness controls in the power management setting. No
> matter the AC/battery state, the brightness never changes. The situation
> hasn't improved with the update to frameworks 6.7 either.

Can confirm on Operating System: KDE neon Testing Edition, with KDE Plasma Version: 6.2.2, KDE Frameworks Version: 6.8.0, Qt Version: 6.8.0

None of the three screen settings: brightness, dim time, turn off time - do anything, in either power mode.

Maybe this should be reported as a new bug?

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

(In reply to Oded Arbel from comment #7)
> None of the three screen settings: brightness, dim time, turn off time - do
> anything, in either power mode.
> 
> Maybe this should be reported as a new bug?

Absent further information, I'd classify that as Bug 482713. This bug is strictly for displays where brightness controls generally work, but going back from Low Battery to AC Power doesn't do anything. Let's not expand the scope to anything else.

(In reply to thibaulltt from comment #0)
> The behaviour I desire is close to what I remember macOS doing in the early
> 2010's (unsure if they still do it). It works this way : when the laptop
> enters a "Low Battery" mode, the maximum brightness level the panel can
> reach is lowered, but the user *still* has a 0%-100% range on their software
> brightness slider. Setting a new brightness while in low battery mode
> amounts to setting the panel to (user_setting * factor) where `factor` is a
> limit to how bright the screen can be in low battery mode (usually somewhere
> near 20%). Once the laptop goes out of "Low Battery" mode, the `factor` is
> set to 1 and the "full" range of the panel's brightness can be achieved.

This sounds very similar to how dimming (on idle) is implemented for Plasma 6.3. We could now easily implement this by defining an additional dimming limiter that kicks in while on Low Battery.

The only thing that's missing for this to work well is that the dimming limiter should probably only apply to the internal display, leaving any external monitors untouched (unlike regular dimming). In general that's a capability I've wanted to add anyway, for the use case of "dim every display except the one currently showing my game/video/fullscreen app". Mostly it needs a workable API and a bunch of bookkeeping, fairly doable though.

Bug 497847 which I've just marked as duplicate suggests for "expected behavior":

> When you connect to power, whatever power saving actions were taken when the
> battery level went below the threshold, should be reverted. Including screen
> brightness.

This is more in line with Natalie's comment #3, implying that you're still free to change the brightness in any way while on Low Battery. (And the it gets restored again afterwards.)

How about a middle ground? We dim the screen to 30% (or whichever configured percentage) when entering Low Battery, and subsequent brightness key changes don't affect the display's baseline brightness but rather *the dimming factor*. So while on Low Battery, if you change your brightness, you'd go from 0% to [currently configured actual brightness].

PowerDevil could even expose the temporary dimming factor as a "virtual brightness slider" in addition to the regular one. If you pop up the brightness applet, you'd see both dimming and regular brightness as separate sliders. On the backend, we'd repurpose the brightness key handler to only affect the low-battery dimming factor and not any other displays.

This is a little different than the other kind of "brightness limiter" I was considering earlier, which would limit brightness to the lesser of [configured brightness] and [configured "change" percentage]. At 100% configured brightness they would be the same, but at less than 100% configured brightness, a relative dimming factor would result in a lower effective brightness, whereas the current (default) absolute 30% brightness setting on Low Battery is always 30% of max brightness. In the grand scheme of things I think that reducing brightness to an absolute percentage this may still be a better implementation, but it would need more infrastructure including support from KWin and a corresponding Wayland protocol (similar to the current dimming protocol, but a little different).

Let me know if you have any further thoughts.

(In reply to Jakob Petsovits from comment #9)
> (In reply to Oded Arbel from comment #7)
> > None of the three screen settings: brightness, dim time, turn off time - do
> > anything, in either power mode.
> > 
> > Maybe this should be reported as a new bug?
> 
> Absent further information, I'd classify that as Bug 482713.

The issue I was describing above was about the "Power Management" KCM, not the interactive brightness controls in the panel widget / keyboard binding. This is definitely not bug 482713. I'll open a new ticket about this.


(In reply to Jakob Petsovits from comment #10)
> How about a middle ground? We dim the screen to 30% (or whichever configured
> percentage) when entering Low Battery, and subsequent brightness key changes
> don't affect the display's baseline brightness but rather *the dimming
> factor*. So while on Low Battery, if you change your brightness, you'd go
> from 0% to [currently configured actual brightness].

I think that's really not a good UX - for one thing, it defeats (a supposed) UI that says "when on low battery limit brightness to [30%]" - if the the brightness was set to 75%, then you get into low battery, it is clamped to 30% of that (0.225%) and you can then increase brightness back to a factor of 1 over the original brightness - 75%, its much higher than 30%. I may have misunderstood what you meant by the above quoted comment, but on the face of it that seems problematic.

> I may have misunderstood what you meant by the above quoted comment, but on the face of it that seems problematic.

I'm also not great at words, or lucid clear thoughts even. Perhaps it's better to focus on what the experience *should* be, and sell one of the developers (perhaps me) on the design. Both behaviors and associated settings labels are up for grabs :)

Also see https://invent.kde.org/plasma/kwin/-/merge_requests/5876 where I just linked to this bug.

My current thinking is that it's important for us to get three aspects right:

1. Migration. Users currently have a percentage of the maximum brightness set in their powerdevil profile config, often only for the Low Battery profile because that's the default. Whichever behavior we pick, it should either work with the existing config or allow an upgrade path that doesn't break expectations.

2. Behavior of brightness keys, applet icon scrolling and applet pop-up controls. When the user adjusts brightness for a brightness-reduced display, will they adjust a temporary setting that will be restored once switching back to (e.g.) AC Power, or will they adjust the baseline brightness setting. What kind of behavior can be intuitive to the user while also resolving this issue. How can the user "break out" of the temporary setting once the profile has been activated.

3. Purpose. This is a permanent settings value, applied to a system with dynamically adjustable baseline brightness. If the user is going to dynamically reduce their display brightness at night, should the 30% setting result in a maximum display power consumption (i.e. 30% or less of absolute brightness) or a relative power savings (i.e. 30% of configured brightness, which might be much darker)?

Let's answer these questions first and think about implementation later. I can leave my own opinions for a future comment.

Here is my proposal at a unified UX at controlling screen brightness:

Starting points:
- it is important to give users control
- the controls should be simple and appear to behave the same way in different scenarios
- users should have some way to configure reducing brightness on battery/low battery to save battery life

Implications:
- there should never be a hard cap on screen brightness, because if the users find the screen contents too dim, they should *always* be able to brighten it so be able to see things
- brightness sliders/brightness keys should always directly adjust screen brightness (in the same way), and the displayed values should always just be underlying screen brightness

Proposed UX:
- Learn a (ambient brightness, screen content) based baseline brightness. Let's call this the brightness function, since it is a function of (ambient brightness, screen content)
  This is learned based on user manual brightness adjustments, we can have more discussion on the representation/learning algorithm later.
- When on (low) battery, if configured, duplicate the baseline brightness function, and make a 1-time adjustment to cap brightness at X. Further user adjustments are learned in to this new function, and does not affect the baseline brightness function.
- When exiting (low) battery (e.g., plugged in), merge the new brightness function with the old one by taking the maximum. So only user adjustments that make the screen brighter than better are kept.

Exposed settings:
when on (low) battery, reduce brightness to xxx

I can think more about multi-monitors and expand on that if people like the general direction of this proposal (e.g., giving users full control, and learn their preferences under the hood)...

Forgot to mention that this is an example of learning user brightness preferences that I liked a lot while on macOs: https://github.com/anishathalye/lumen

Yifan (@fanzhuyifan), Xaver (@zamundaaa) and myself had a little discussion about this on Matrix. Xaver is pushing for a mechanism with low complexity, he would like to go simpler than Comment #14 and will likely agree with Comment #11 where Oded points out the complexity of my earlier suggestion.

Here's a quick rundown of a conceptually simple model, taking inspiration from the original bug description as well as Xaver's suggestions.

UI:
- Replace Power Management's per-power-state "Change screen brightness" with a similar slider that controls dimming for internal screens, rather than absolute brightness.
- Add an extra row to the applet to indicate when this setting is active. We could design this as indicator text that tells you that the screen is dimmed according to power management settings, or we could duplicate the slider from System Settings.
- Ideally the brightness change OSD (e.g. on brightness key) would also note when a display is dimmed.

Behavior:
- Effective brightness for internal screens will be (configured brightness * configured dimming ratio per power state).
- Brightness keys always change configured brightness, as they currently do.
- If the user wants to change their brightness value after getting dimmed on e.g. Low Battery, they should change the dimming ratio setting. Using only brightness keys would not be able to reach 100%.

Migration:
- For a power state with no brightness change is configured, use 100% as dimming ratio.
- For a power state with brightness configured to change to a given percentage of max brightness, set the new dimming ratio config value to (configured brightness for this power state / current brightness of internal screen at migration time), maxing out at 100%. This should result in a roughly comparable and useful enough value in many scenarios. Where the migration doesn't work out perfectly,  displays would always stay closer to the baseline brightness, never too dark.

Purpose:
- Power savings relative to the configured baseline brightness. Baseline brightness may also reflect ambient light sensors, so this setting and ambient light adjustments can be combined in a straightforward way.

I think the main problem of this approach would be discoverability of the dimming ratio setting. Many users would be inclined to use their brightness keys instead for raising brightness back up once Low or Critical Battery kicks in. Then once they plug the laptop back in, it gets too bright and they have to adjust it back down. The more we can nudge the user in the direction of the brightness applet for awareness of this dimming feature, the less this should be an issue.

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