https://bugs.kde.org/show_bug.cgi?id=484663
--- Comment #10 from Jakob Petsovits <jpe...@petsovits.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
