DESCRIPTION The system tray brightness widget no longer updates to correct values if screen brightness is updated via keyboard shortcuts. Relatedly, if there are two displays connected with different brightness settings made via the widget, then the keyboard shortcut maintains that difference when increasing or decreasing brightness, eg. set display A to 50% and display B to 100% via the widget now means there's a constant 50% difference between display A and B when using the shortcuts. Previously, increasing or decreasing both displays to 100% or 0% would eliminate this. Restarting plasmashell temporarily fixes both issues until an adjustment is made again. STEPS TO REPRODUCE 1. Set brightness to 70% via widget 2. Use the Power Management system service keyboard shortcut Increase Screen Brightness to increase brightness to 100% OBSERVED RESULT The brightness & colour control widget screen brightness is reported as 70%, but the tooltip of hovering over the system tray icon reports 100%. EXPECTED RESULT The widget should report adjustments made to brightness made via keyboard shortcuts. SOFTWARE/OS VERSIONS Operating System (available in the Info Center app, or by running `kinfo` in a terminal window): KDE Plasma Version: 6.7.3 KDE Frameworks Version: 6.28.0 Qt Version: 6.11.1
Can confirm, this happens when using the "Control hardware brightness with DDC/CI" setting in display settings. Operating System: KDE Linux 2026-07-19 KDE Plasma Version: 6.7.80 KDE Frameworks Version: 6.29.0 Qt Version: 6.11.1 Kernel Version: 7.1.3-arch2-2 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 16 GiB of RAM (15.5 GiB usable) Graphics Processor: AMD Radeon RX 6600
*** Bug 523948 has been marked as a duplicate of this bug. ***
*** Bug 524026 has been marked as a duplicate of this bug. ***
It's worth mentioning that I experienced this bug right after upgrading plasma 6.7.2 to 6.7.3. Hopefully, that helps someone to narrow down the commit(s) which led to this regression.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/667
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/673
*** Bug 524915 has been marked as a duplicate of this bug. ***
*** Bug 524335 has been marked as a duplicate of this bug. ***
Git commit 57f1904599655bb77de7e5089a5894d5930bbaf1 by Christoph Wolk. Committed on 16/09/2026 at 10:37. Pushed by cwo into branch 'master'. applets/brightness: fix Slider binding issues 94a03a3c04787388026a02ff40afd2b77fc9d0f6 introduced a workaround for devices that send intermediate updates on brightness changes that interfere with interactively dragging the slider: it binds the value only while the control is not pressed. But this causes two issues: - Keyboard interaction also makes the control pressed, which stops the Binding and causes it to restore the pre-binding value, 0, before applying the change. So e.g. Arrow Left will always reset the slider to 0, rather than one step down, the first time each Plasma run. - Setting the value delegate's property manually breaks the binding we set from outside, so further changes from elsewhere (such as global shortcuts) will no longer be reflected in the slider, it will stay at whatever value it was set to in the widget. (Except for keyboard brightness, which has some extra logic to constantly reestablish the binding) To fix this, we make the binding between the delegate more explicit, setting it to the current value when pressed and a binding while not. We also change how we communicate changes to the outside; rather than having a binding that breaks and has to be established constantly, we keep the delegate's value property always bound and communicate user input by passing the value as an argument to the signal that causes the change to happen anyway. This solves both issues and reduces code complexity as things are better encapsulated (albeit at the cost of having a bit of imperative state handling in the Slider) M +12 -13 applets/brightness/BrightnessItem.qml M +2 -10 applets/brightness/PopupDialog.qml https://invent.kde.org/plasma/powerdevil/-/commit/57f1904599655bb77de7e5089a5894d5930bbaf1
*** Bug 525519 has been marked as a duplicate of this bug. ***
Git commit 97d9a96bc7a9e8fb21ca4c8d8ea672311f463167 by Christoph Wolk. Committed on 17/09/2026 at 12:02. Pushed by cwo into branch 'Plasma/6.7'. applets/brightness: fix Slider binding issues 94a03a3c04787388026a02ff40afd2b77fc9d0f6 introduced a workaround for devices that send intermediate updates on brightness changes that interfere with interactively dragging the slider: it binds the value only while the control is not pressed. But this causes two issues: - Keyboard interaction also makes the control pressed, which stops the Binding and causes it to restore the pre-binding value, 0, before applying the change. So e.g. Arrow Left will always reset the slider to 0, rather than one step down, the first time each Plasma run. - Setting the value delegate's property manually breaks the binding we set from outside, so further changes from elsewhere (such as global shortcuts) will no longer be reflected in the slider, it will stay at whatever value it was set to in the widget. (Except for keyboard brightness, which has some extra logic to constantly reestablish the binding) To fix this, we make the binding between the delegate more explicit, setting it to the current value when pressed and a binding while not. We also change how we communicate changes to the outside; rather than having a binding that breaks and has to be established constantly, we keep the delegate's value property always bound and communicate user input by passing the value as an argument to the signal that causes the change to happen anyway. This solves both issues and reduces code complexity as things are better encapsulated (albeit at the cost of having a bit of imperative state handling in the Slider) Manual cherry-pick from 57f190459 M +12 -13 applets/brightness/BrightnessItem.qml M +2 -10 applets/brightness/PopupDialog.qml https://invent.kde.org/plasma/powerdevil/-/commit/97d9a96bc7a9e8fb21ca4c8d8ea672311f463167
Git commit d37bb0f15116425248ecdc74095585a613962e7f by Christoph Wolk. Committed on 21/09/2026 at 07:34. Pushed by cwo into branch 'Plasma/6.8'. applets/brightness: fix Slider binding issues 94a03a3c04787388026a02ff40afd2b77fc9d0f6 introduced a workaround for devices that send intermediate updates on brightness changes that interfere with interactively dragging the slider: it binds the value only while the control is not pressed. But this causes two issues: - Keyboard interaction also makes the control pressed, which stops the Binding and causes it to restore the pre-binding value, 0, before applying the change. So e.g. Arrow Left will always reset the slider to 0, rather than one step down, the first time each Plasma run. - Setting the value delegate's property manually breaks the binding we set from outside, so further changes from elsewhere (such as global shortcuts) will no longer be reflected in the slider, it will stay at whatever value it was set to in the widget. (Except for keyboard brightness, which has some extra logic to constantly reestablish the binding) To fix this, we make the binding between the delegate more explicit, setting it to the current value when pressed and a binding while not. We also change how we communicate changes to the outside; rather than having a binding that breaks and has to be established constantly, we keep the delegate's value property always bound and communicate user input by passing the value as an argument to the signal that causes the change to happen anyway. This solves both issues and reduces code complexity as things are better encapsulated (albeit at the cost of having a bit of imperative state handling in the Slider) (cherry picked from commit 57f1904599655bb77de7e5089a5894d5930bbaf1) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +12 -13 applets/brightness/BrightnessItem.qml M +2 -10 applets/brightness/PopupDialog.qml https://invent.kde.org/plasma/powerdevil/-/commit/d37bb0f15116425248ecdc74095585a613962e7f
Git commit 18c2a83a6bc460ec79016e1bffc281b58b3d599a by Christoph Wolk. Committed on 06/10/2026 at 13:31. Pushed by cwo into branch 'Plasma/6.6'. applets/brightness: fix Slider binding issues 94a03a3c04787388026a02ff40afd2b77fc9d0f6 introduced a workaround for devices that send intermediate updates on brightness changes that interfere with interactively dragging the slider: it binds the value only while the control is not pressed. But this causes two issues: - Keyboard interaction also makes the control pressed, which stops the Binding and causes it to restore the pre-binding value, 0, before applying the change. So e.g. Arrow Left will always reset the slider to 0, rather than one step down, the first time each Plasma run. - Setting the value delegate's property manually breaks the binding we set from outside, so further changes from elsewhere (such as global shortcuts) will no longer be reflected in the slider, it will stay at whatever value it was set to in the widget. (Except for keyboard brightness, which has some extra logic to constantly reestablish the binding) To fix this, we make the binding between the delegate more explicit, setting it to the current value when pressed and a binding while not. We also change how we communicate changes to the outside; rather than having a binding that breaks and has to be established constantly, we keep the delegate's value property always bound and communicate user input by passing the value as an argument to the signal that causes the change to happen anyway. This solves both issues and reduces code complexity as things are better encapsulated (albeit at the cost of having a bit of imperative state handling in the Slider) Manual cherry-pick from 57f190459 (cherry picked from commit 97d9a96bc7a9e8fb21ca4c8d8ea672311f463167) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +12 -13 applets/brightness/BrightnessItem.qml M +2 -10 applets/brightness/PopupDialog.qml https://invent.kde.org/plasma/powerdevil/-/commit/18c2a83a6bc460ec79016e1bffc281b58b3d599a
Sry for asking this question. I'm new to all this bug-reporting-stuff. May i kindly ask in which/what KDE-Version this Bug-Fix will be introduced? Right now, i'm on "Desktop Environment: KDE Plasma 6.7.5"
(In reply to simonschmidt from comment #14) > Sry for asking this question. I'm new to all this bug-reporting-stuff. > May i kindly ask in which/what KDE-Version this Bug-Fix will be introduced? > > Right now, i'm on "Desktop Environment: KDE Plasma 6.7.5" My bad, i think i wrote in the wrong Bug-Thread, it's not even the Bug i'm interested in. It was my failure. Please delte this and my previeous comment. (am so ashamed :) ),