Laptop screen and connected 4K (DP) monitor Problem: "Battery and Brightness" in systemtray shows a different brightness-percentage than set on laptop screen. Modifying the brightness-slider then 'suddenly jumps' to a way too dark setting I need to use the hardware-keys (Fn-*) to set the brightness up again to a usable state. Still, the brightness-slider is not in sync with the OSD (OSD ~65%, brightness-slider ~45%) This was working properly already but seems to be a regression? Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.3-100.fc37.x86_64 (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7820HQ CPU @ 2.90GHz Memory: 31,1 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 630 Manufacturer: LENOVO System Version: ThinkPad T470p
I also noticed that moving slider fast can get it out of sync or revert (sync) to an intermediate state. So I trust your bug report even without screenshots (: Probably backend needs some job buffering and proper ordering. I've done something like that in my personal DDC/CI brightness control app, so I should take a look at it in Plasma powerdevil too.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3178
New merge request @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/342. It fixes the brightness slider lagginess and makes the slider jump way less, still possible but negligible in practice. I have deeply pondered what this means for the slider going out of sync with the OSD. Quick testing now seems fine in terms of showing the right OSD values after quickly dragging the brightness slider. It may just all be a question of "how much time do you give powerdevil to apply the new brightness slider value before pressing the brightness key". In which case, the answer is "it needs a lot less time to apply the new brightness than it did before (but there is still a little delay theoretically)".
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4294
Git commit 2f7649edc535c68e1906c2dd3b14152e0ed9f0b9 by Xaver Hugl. Committed on 08/05/2024 at 21:41. Pushed by zamundaaa into branch 'master'. applets/brightness: fix max brightness change notification The wrong signal name was used, which meant the maximum brightness value of the slider and the actual maximum powerdevil uses could get out of sync M +1 -1 applets/brightness/plugin/screenbrightnesscontrol.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/2f7649edc535c68e1906c2dd3b14152e0ed9f0b9
Git commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd by Jakob Petsovits. Committed on 22/06/2024 at 11:46. Pushed by jpetso into branch 'master'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 481003 M +38 -13 daemon/controllers/backlightbrightness.cpp M +3 -0 daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/033825d2217ec3c91af5af1fc0a6fbb66f91fdbd
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/383
Git commit 1017585fe5ef2263e02e6dc6f5227de15fb3ba5d by Jakob Petsovits. Committed on 22/06/2024 at 12:16. Pushed by jpetso into branch 'Plasma/6.1'. daemon: Limit KAuth backlighthelper calls to only one at a time KAuth invocations are slower than users can move a slider. So we get many brightness change requests, and KAuth can't keep up. As a result, high-frequency brightness change requests for BacklightBrightness (i.e. laptop displays) would feel very laggy and get worse over time if not given a break to catch up. This commit fixes the lagginess. Conceptually it's easy: Don't start a new KAuth helper job until the current one has reported a result. At that point, check if a different brightness level was requested in the meantime, and start another job only then. BacklightHelper can deal fine with interrupting a running animation and starting a new one from the current brightness level. Hence, there is no need to wait until the end of the brightness animation to start a new KAuth job - this would only increase latency. Starting the new job right after receiving a result is perfectly fine. In the same go, we make two related improvements. Firstly, the udev-powered brightness observer will not only ignore events when the animation timer is running, but also in between setBrightness() and the KAuth result handler where the timer is started. Secondly, the condition involving m_brightnessAnimationThreshold is changed to something sensible. It makes no sense to simply check the current brightness against a constant number (100) to determine whether the brightness change should be animated. What I think this meant to do is to ensure that there are enough brightness steps available to animate. So following this commit, we will now animate when the difference between the current and the requested brightness is 100 or more integer steps. Taken together, laptop brightness slider UX now seems decent. Related: bug 481003 (cherry picked from commit 033825d2217ec3c91af5af1fc0a6fbb66f91fdbd) M +38 -13 daemon/controllers/backlightbrightness.cpp M +3 -0 daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/1017585fe5ef2263e02e6dc6f5227de15fb3ba5d
There were a few fixes, both in the 6.0 cycle for the brightness applet and now in 6.1.1 for the background service. I haven't reproduced the original issue, but I've been trying to get the slider out of sync with sudden changes and haven't been able to break it. I believe the issue as reported is now fixed, so I'll mark it RESOLVED FIXED. If you still experience any sudden jumps or out-of-sync values getting displayed, feel free to reopen this.