https://bugs.kde.org/show_bug.cgi?id=495544
Bug ID: 495544
Summary: Disable PowerDevil/KWin brightness integration until
regressions are fixed
Classification: Plasma
Product: kwin
Version: git master
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: output configuration
Assignee: kwin-bugs-n...@kde.org
Reporter: jpe...@petsovits.com
CC: xaver.h...@gmail.com
Target Milestone: ---
SUMMARY
Brightness controls through KWin hurt more than they help right now, and there
isn't a path forward for fixing all of the issues in the 6.2 time frame due to
feature and string freeze requirements:
1. Bug 494408 is partially fixed by a patch like
https://invent.kde.org/plasma/kwin/-/merge_requests/6667 (Initially adopt
current brightness of external brightness device). However, this requires KWin
and PowerDevil to depend on an updated plasma-wayland-protocols, once
https://invent.kde.org/libraries/plasma-wayland-protocols/-/merge_requests/86
is merged. Although this has not seen any discussion so far, either.
2. As Xaver points out in kwin!6667 linked above,
> when the user [after having 100% default brightness assigned] changes the
> brightness of the screen
> with the OSD, that change gets overwritten after hotplug events, giving the
> appearance that the
> brightness gets "reset" - as it's not obvious they have to set it in Plasma
> instead now
https://discuss.kde.org/t/powerdevil-is-re-setting-my-display-brightness-after-the-display-wakes-up/23079/9
notes that we can only apply heuristics to determine whether KWin should adopt
or ignore external brightness changes. In 6.2 we do not have the necessary
information to even apply these heuristics. (One of the mentioned factors for
the heuristic depends on a proper dimming API, i.e.
https://invent.kde.org/plasma/powerdevil/-/issues/38, which again requires
breaking feature freeze.)
Even if we did have all these heuristics implemented, they would not always
lead to the correct decision.
3. Because KWin now owns and uses brightness controls for all screens, external
brightness services and applets are now useless if they don't go through the
new PowerDevil D-Bus brightness API. This affects software such as
https://github.com/digitaltrails/vdu_controls and
https://github.com/denilsonsa/midi-pipewire-volume, in addition to common
terminal-based use of ddcutil either directly or via scripts.
4. There is no off switch, so right now we're asking users to set
POWERDEVIL_NO_DDCUTIL=1 if stuff doesn't work out. The longer we don't fix
user's workflows, the more users will keep this environment variable in place
indefinitely.
https://discuss.kde.org/t/powerdevil-is-re-setting-my-display-brightness-after-the-display-wakes-up/23079/11
mentions that unexpected brightness changes are a blow to professional
calibrated setups. It's a little ironic that KWin, which now has so many great
color management features, can also be responsible for breaking these setups by
insisting to handle monitor brightness.
OBSERVED RESULT
We broke important use cases without providing timely fixes or a "Disable
brightness controls for this display" checkbox to users.
EXPECTED RESULT
If we can't fix widespread issues in a timely manner, we should disable KWin
integration by default for the time being.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 6.2.80 (around 6.2.2)
KDE Frameworks Version: 6.8
Qt Version: 6.8
Graphics platform: Wayland
Let's revert PowerDevil/KWin to only affect HDR screens until we can get these
issues figured out (presumably in 6.3).
Let's bring it back only once we have a toggle in the KScreen KCM that allows
disabling brightness controls per display.
--
You are receiving this mail because:
You are watching all bug changes.
