Plasma/6.1 cherry-pick for MR !342.
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 forBacklightBrightness (i.e. laptop displays) would feel very laggyand 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 hasreported a result. At that point, check if a different brightnesslevel was requested in the meantime, and start another job only then.
BacklightHelper can deal fine with interrupting a running animationand starting a new one from the current brightness level. Hence,there is no need to wait until the end of the brightness animationto 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 ignoreevents when the animation timer is running, but also in betweensetBrightness() and the KAuth result handler where the timeris started.
Secondly, the condition involving m_brightnessAnimationThresholdis changed to something sensible. It makes no sense to simplycheck the current brightness against a constant number (100) todetermine whether the brightness change should be animated.What I think this meant to do is to ensure that there are enoughbrightness steps available to animate. So following this commit,we will now animate when the difference between the current andthe requested brightness is 100 or more integer steps.
Taken together, laptop brightness slider UX now seems decent.
(cherry picked from commit 033825d2)