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