I figure the remaining jumps are due to brightnessChanged() getting emitted as result of the incoming brightness change D-Bus call. The underlying issue still remains as of this patch, it's just much faster i.e. less obvious. Hypothesis:
- Applet changes brightness via slider or scroll event, updates internal brightness value
- Applet calls brightness setter via D-Bus (
org.kde.Solid.PowerManagement.Actions.BrightnessControl.setBrightness) - PowerDevil starts getting on the job
- Another scroll event comes in, applet updates internal brightness value again
- PowerDevil gets a reply from KAuth, emits
brightnessChanged()signal - Applet receives
brightnessChanged(), which resets it back to an earlier state
I think this would be true even after Fushan's patch, because brightnessChanged() isn't tied to the setBrightness D-Bus call.
We could consider setting the brightness value immediately in setBrightness() and reverting it if the KAuth invocation fails. DDCutilDisplay is already doing this, and there may not be many downsides apart from being an even bigger lie than the current one.
Alternatively, we could consider adding a new variant of setBrightness() that identifies "context" in the same way that digitaltrails/ddcutil-service recently introduced. If we have that, the applet could just ignore any brightness changes that originate from its own calls, no matter the timing or delay.