I had another thought re. how best to throttle. One of my concerns with using this change in its current state is that single-shot brightness writes will be unnecessarily delayed. E.g. there's no reason that a brightness write from changing power state profile settings should be delayed - we know it happens only once and without user input.
So I've been thinking, what if we add a second argument to setBrightness() that distinguishes between one-shot, final, likely programmatic changes (like profile settings assigning a different brightness) vs. continuous, likely interactive changes (like brightness slider until mouse button release, or multiple key shortcuts until the OSD disappears)? Naming tbd, my current best attempt is:
enumclassSetBrightnessHint{Final=0,Continuous,};voidsetBrightness(intvalue,SetBrightnessHinthint=SetBrightnessHint::Final);If piped through to our D-Bus API, this can solve issues with both ddcutil and backlight brightness setters:
Final: used by profile changes, optionally applet slider mouse button release, optionally brightness OSD disappearance- ddcutil behavior: immediately write brightness value
- backlight behavior: animate to brightness value
Continuous: used by applet slider changes, brightness key press- ddcutil behavior: delay brightness write (for EEPROM longevity)
- backlight behavior: immediately write brightness value without animation (for immediate feedback)
What do you think? I could change !324 to include this hint in the immediate API that ScreenBrightnessController uses, and we can pipe it through to higher-level users including the D-Bus API / brightness applet in follow-up commits.