Created attachment 165643 [details] Video of brightness slider not reacting I made a recording. The applet is not reacting linerarly to input, and the brightness is often not following, sometimes even getting darker rather than brighter when up. Operating System: Fedora Linux 40 KDE Plasma Version: 5.92.0 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.8.0-0.rc0.20240112git70d201a40823.5.fc40.x86_64 (64-bit) Graphics Platform: offscreen Processors: 8 × AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx Memory: 5.7 GiB of RAM Graphics Processor: AMD Radeon Vega 8 Graphics
Can't reproduce on wayland, git master
Can confirm (on a Desktop): Operating System: Arch Linux KDE Plasma Version: 6.0.80 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.1 Kernel Version: 6.7.4-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 32 × AMD Ryzen 9 7950X 16-Core Processor Memory: 30,6 GiB of RAM Graphics Processor: AMD Radeon RX 7900 XTX The slider is very sluggish and sometimes does not update or updates random values. Additionally after the screen turns off it gets darker (latest test from 55% to 16% after the screen turned off and on again). I didn't even have this option a few weeks ( or months) before, could also be a downstream bug.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/342
*** Bug 484254 has been marked as a duplicate of this bug. ***
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 470106 M +38 -13 daemon/controllers/backlightbrightness.cpp M +3 -0 daemon/controllers/backlightbrightness.h https://invent.kde.org/plasma/powerdevil/-/commit/033825d2217ec3c91af5af1fc0a6fbb66f91fdbd
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 470106 (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