[Powerdevil] [Bug 350676] Need to press key twice to decrease brightness

[Igor Poboiko]

https://bugs.kde.org/show_bug.cgi?id=350676

--- Comment #5 from Igor Poboiko <igor.poboiko at 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.