https://bugs.kde.org/show_bug.cgi?id=350676
--- Comment #5 from Igor Poboiko <igor.pobo...@gmail.com> --- I did some investigation on this problem by adding few debug lines, and I nailed it. What is happening here is following: 1. User presses DecreaseBrightness button first time. - UPower backend starts an QPropertyAnimation (PowerDevilUPowerBackend::setBrightness) - Animation runs several setBrightness calls - Each call produces an XRandR event saying that brightness is changed; but since animation is still running, PowerDevilUPowerBackend::slotScreenBrightnessChanged just ignores it. NB: it does not update m_cachedBrightnessMap!!! 2. Uses presses DecreaseBrightness button second time - UPower backend gets PowerDevilUPowerBackend::brightnessKeyPressed slot called - since current brightness (which is correct and new value) differs from one cached (cache was not updated; it points to old value), it just updates cache and ignores the call! 3. In case of brightness increase, animation stops BEFORE sending last valueChanged() signal. Therefore it passes the PowerDevilUPowerBackend::slotScreenBrightnessChanged check (animation is no longer running) and updates the cache. --- It seems like QPropertyAnimation is somehow buggy. It emits valueChanged signal even without animation actually running, just when startValue and endValue are set. I believe it shouldn't happen; in our case this leads to following behaviour: powerdevil: set screen brightness value: 422 --- set start value 469 --- setting value 422 --- set end value 422 --- setting value 469 --- start Here I added a debug print right after each line in PowerDevilUPowerBackend::setBrightness; while "setting value" message is being print in animationValueChanged. This actually might lead to screen brightness flickering, which might be another bug. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
