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